예전에 Ubuntu 서버에서 SSH 접속이 비정상적으로 지연되거나 끊기는 문제를 겪은 적이 있었다.
겉으로는 서버 자원도 정상이고 로그도 깨끗했기 때문에 원인 파악이 쉽지 않았다.
그 당시 분석했던 내용을 다시 정리해 둔다.
비슷한 상황을 겪는 사람들에게 참고가 될 수 있을 것이다.

---

1. 당시 증상

• SSH 로그인 시도 자체가 비정상적으로 오래 걸림
• 때때로 접속 실패
• 기존 로그인 중인 세션은 정상 동작
• CPU/메모리/디스크 모두 정상
• auth.log에도 특이사항 없음

표면적으로는 원인을 찾기 어렵고 진단 범위도 매우 넓은 상태였다.

---

2. 처음 확인된 이상 징후 — bash 프로세스 누적

문제가 있던 서버에서 bash 프로세스 개수를 확인해보았다.

ps -ef | grep bash

정상이라면 사용자 세션 수와 비슷해야 하지만,
당시 서버에는 100개 이상의 bash 프로세스가 남아 있었다.

예시:

deploy   31830  ...  -bash SSH_TTY=/dev/pts/137
deploy   31888  ...  -bash SSH_TTY=/dev/pts/114
deploy   31938  ...  -bash SSH_TTY=/dev/pts/19
deploy   32403  ...  -bash SSH_TTY=/dev/pts/38
deploy   32602  ...  -bash SSH_TTY=/dev/pts/80

특징은 명확했다.

• 모두 자동화/배포 서버에서 SSH로 접속하여 생성된 세션
• 생성된 지 수일~수주 지난 세션
• SSH_TTY가 모두 개별 /dev/pts/* 장치를 점유

즉, SSH 세션 종료가 정상적으로 이뤄지지 않고 bash 프로세스만 남는 상황이 반복된 것이다.

---

3. 문제의 핵심 — /dev/pts 장치 삭제 여부와 실제 커널 점유는 별개

이 상태에서 lsof | grep pts를 확인하면 일부 장치는 이렇게 보인다.

/dev/pts/137 (deleted)

장치 파일이 삭제된 것처럼 보이지만
여기서 가장 중요한 사실은 다음과 같다.

장치 파일이 사라져도 커널 내부에서는 해당 PTY 번호가 여전히 점유된 상태다.
즉, 반환되지 않는다.

PTY는 커널에서 관리되는 제한된 자원이며,
반환되지 않으면 새로운 SSH 접속 시 다음 동작이 발생한다.

• 새로운 PTY 번호를 할당하려고 커널이 대기 → 접속 지연
• 특정 시점 이후에는 PTY 생성 실패 → SSH 세션 생성 실패

이 문제는 특히 sshd의 초기 로그인 과정에서 PTY를 요청할 때 가장 크게 드러난다.

---

4. “100개 정도인데 왜 문제가 되나?”에 대한 기술적 이유

대부분의 리눅스 시스템에서 PTY 최대 개수는 1024~4096 정도로 설정되어 있다.
따라서 숫자만 보면 “100개 정도는 충분히 남았는데?”라고 생각할 수 있다.
(/proc/sys/kernel/pty/max : pty 최대 개수 확인할 수 있는 파일)

하지만 실제 SSH 지연은 순수 개수 부족 때문이 아니라 커널 내부의 PTY 관리 구조 때문에 발생한다.

✔ 이유 1: PTY는 동기적으로 요청되는 자원이다

sshd는 로그인할 때 반드시 PTY 할당을 완료해야 한다.
이 단계에서 커널 내부에서 다음 작업이 발생한다.

• PTY 번호 탐색
• 사용 가능한 항목 확인
• 오랫동안 반납되지 않은 “삭제된 장치” 처리
• 충돌(경합) 해결

hundreds of stale PTY가 남아 있으면 이 탐색 과정이 지연된다.

✔ 이유 2: Stale PTY가 많을수록 커널 내부에서 스캔 비용이 올라간다

• /dev/pts/137 (deleted) 와 같은 항목이 많을수록 커널은 “사용 가능?”을 반복해서 확인해야 한다.
• 이 스캔은 O(N) 구조이며, stale PTY가 많을수록 시간이 증가한다.

결과:

• 남아있는 PTY 번호가 충분해도 할당 과정에서 지연 발생
• SSH 로그인에서 가장 오래 걸리는 “PTY 준비 단계”가 병목이 됨

즉,

개수 부족 때문이 아니라, stale PTY들이 커널 내부 PTY 할당 과정을 지연시키기 때문에 SSH 접속이 느려지는 것이다.

이게 핵심이다.

---

5. 원인 — 자동화 서버에서 의도치 않게 생성한 pty 세션

당시 자동화 서버는 다음과 같은 방식으로 원격 작업을 수행하고 있었다.

ssh -t deploy@server "sh /opt/scripts/deploy.sh"

여기서 문제는 -t 옵션이다.

✔ -t = 대화형 모드 강제 = 무조건 PTY 생성

• sshd는 pty 생성
• bash 실행
• 자동화 스크립트는 비대화형인데도 불필요하게 pty가 붙음
• 오류나 네트워크 끊김 발생 시 bash만 남고 종료 안 됨 → stale PTY 발생

이 패턴이 반복되어 누적된 것이 문제의 실체였다.

---

6. 해결 – bash 프로세스 정리 + SSH 구조 자체 개선

1) 누적된 bash 세션 정리

ps -eo pid,etimes,cmd --sort=etimes | \
    grep bash | awk '$2 > 43200 {print $1}' | xargs -r kill -9

(예: 12시간 이상 유지된 세션 종료)

---

2) 자동화 서버 SSH 구조 개선 — pty 자체를 만들지 않는 방식으로 변경

ssh -T 옵션은 다음을 의미한다.

pseudo-terminal을 만들지 말라

자동화 작업에서는 대화형 터미널이 필요 없기 때문에
PTY를 생성하지 않는 것이 가장 안전하다.

✔ 권장 방식 (non-interactive SSH)

ssh -T deploy@server "systemctl restart app"

✔ 여러 명령 전달 시

ssh -T deploy@server << 'EOF'
cd /opt/app
git pull
./restart.sh
EOF

이 방식은:

• pty 생성 X
• bash 생성 X
• stale PTY 누적 X
• /dev/pts 고갈 문제 원천 차단

운영 환경에서 가장 안정적인 방식이다.

---

3) sshd_config 보완 (보조적 예방책)

ClientAliveInterval 60
ClientAliveCountMax 3
LoginGraceTime 20
MaxSessions 50
MaxStartups 10:30:200

오래된 zombie session을 자동으로 정리하는 데 도움 된다.

---

7. 재발 방지 – 오래된 bash 자동 정리 스크립트

#!/bin/bash
ps -eo pid,etimes,cmd | grep bash | awk '$2 > 43200 {print $1}' | xargs -r kill -9

cron 예시:

0 * * * * /usr/local/sbin/pts_cleanup.sh

---

마무리

정리하면 문제의 본질은 다음과 같다.

자동화 서버가 ssh -t 방식으로 pty를 강제로 생성했고,
정상 종료되지 않은 bash 세션이 누적되면서 stale PTY가 많아졌고,
이로 인해 SSH 로그인 시 커널의 PTY 할당 과정이 지연된 것.

PTY 자원은 단순히 “갯수”만의 문제가 아니라,
“커널 내부에서 어떻게 스캔·할당되는가”가 더 큰 영향을 준다.

비슷한 문제가 있다면:

• bash 프로세스 개수
• stale PTY 여부
• 자동화 스크립트의 SSH 옵션(-t 사용 여부)
• 가능하면 모든 자동화 호출을 non-interactive SSH(-T)로 변경

이 네 가지를 먼저 확인하는 것이 도움이 될 것이다.

🛠 마지막 수정일: 2025.11.17