ssh port 22 Connection refused 해결

Refused는 사실 좋은 소식입니다

ssh: connect to host port 22: Connection refused는 실패처럼 보이고, 실패가 맞습니다 — 하지만 도움이 되는 종류입니다. Refused는 내 접속 시도가 서버까지 도달했고 서버가 응답했다는 뜻입니다. “아니오”라고 답했지만, 어쨌든 답했습니다. 네트워크 경로는 작동하고, 호스트는 살아서 닿으며, DNS는 올바른 곳으로 해석됐습니다. 단어 하나로 문제의 한 범주 전체를 지운 셈입니다.

원리는 이렇습니다. 호스트로 ssh를 하면 내 머신이 22번 포트로 TCP SYN을 보냅니다. 거기서 뭔가 듣고 있으면 SYN-ACK를 받고 연결이 진행됩니다. 호스트는 살아 있는데 22번에 아무것도 안 듣고 있으면, 운영체제가 즉시 TCP RST(리셋)를 되쏘고 클라이언트는 “Connection refused”를 보고합니다. 그 RST는 호스트가 현장에서 능동적으로 거절한 것입니다. 오직 호스트 자신에게서만 나올 수 있으니, 패킷이 거기 도달했다는 뜻입니다.

반대로 봤을 수도 있는 다른 에러: Connection timed out. 이건 침묵입니다. SYN을 보냈는데 아무것도 못 받았고 — RST도 응답도 없이 — 클라이언트가 포기할 때까지 기다립니다. 침묵은 거의 항상 방화벽이 패킷을 바닥에 버렸거나, 호스트가 아예 닿지 않는다는 뜻입니다. 사람에겐 같은 로그인 실패이지만, 봐야 할 곳은 정반대입니다.

이 구분 하나가 진단의 전부입니다. Refused → 패킷이 머신에 도달했으니 문제는 SSH 서비스(또는 그게 있는 포트). Timed out → 패킷이 응답을 못 받았으니 문제는 머신 앞단의 방화벽이나 경로. 이걸 거꾸로 짚으면, 그저 안 돌고 있는 데몬을 고치겠다고 방화벽 규칙을 한 시간 동안 다시 쓰게 됩니다.

22번 포트 refused의 3대 원인

1. sshd가 안 돌고 있다. 가장 흔한 원인이자 사람들이 가장 늦게 확인하는 것. 데몬이 죽었거나, 누가 sshd_config를 편집하고 문법 오류를 남겨 재시작에 실패했거나, 부팅 시 시작하도록 켜둔 적이 없거나. 22번에 아무것도 없으면 커널이 모든 접속을 즉시 거부합니다. 서버에서 systemctl status ssh(또는 sshd) 한 줄이면 알 수 있습니다. 시작이 안 되면 sshd -t로 실행 없이 설정을 검증하세요.
2. SSH가 다른 포트에서 듣고 있다. 누가 sshd_config의 Port 22를 Port 2222로 바꿨고 — 흔한 하드닝 단계 — 이제 ssh host(22번 기본)가 아무것도 없는 포트를 두드려 refused를 받습니다. 서비스는 멀쩡합니다. 엉뚱한 문을 두드리고 있을 뿐이죠. ssh -p 2222 host로 접속하거나 서버에서 ss -tlnp | grep sshd로 실제 바인딩을 확인하세요.
3. sshd가 localhost에만 바인딩됐다. ListenAddress 127.0.0.1(또는 그렇게 배포되는 서비스)이면 sshd는 머신 자신에서 온 접속만 받습니다. 서버에서 ssh localhost는 완벽히 되고, 다른 어디서든 refused. 딱 방화벽 문제처럼 보이지만 아닙니다 — 0.0.0.0(모든 인터페이스)이나 올바른 공인 주소에 바인딩하고 sshd를 재시작하는 게 해법입니다.

이름을 붙여둘 네 번째, 사람들을 속이는 것: fail2ban이 내 IP를 차단. 내 주소에서만 refused고 남들은 괜찮다면, 침입 방지 도구가 실패 시도 후 나를 거부하는 규칙을 추가한 것입니다. 서버가 죽은 게 아니라 나를 콕 집어 막아둔 겁니다.

DechoNet으로 진단하기

• 포트 점검 — 서버의 22번(또는 커스텀 SSH 포트)을 밖에서 돌려보세요. 두 세계 중 어디에 있는지 알려주니 가장 유용한 테스트입니다. **닫힘(closed, refused)**이면 호스트는 살아 있고 아무것도 안 듣는 것 — SSH 서비스를 고치세요. **필터링(timeout)**이면 뭔가가 패킷을 버리는 것 — 방화벽을 고치세요. 내 머신이 자신에 대해 답할 수 없는 refused-vs-timeout 질문을 외부 진단이 매듭짓습니다.
• DNS 조회 — SSH를 탓하기 전에 호스트명이 내가 기대하는 IP로 해석되는지 확인하세요. 이름이 옛 서버, 로드밸런서, CDN 엣지를 가리키면 내 sshd가 돌던 적 없는 머신에서 refused를 받는 것입니다. 낡은 A 레코드는 실은 DNS 문제인데 아주 그럴듯한 “SSH 고장”을 만듭니다.

해결 체크리스트

• 어떤 에러인지 확정한다. Refused = 서비스/포트 문제(이 가이드). Timed out = 방화벽/경로 문제(보안 그룹·방화벽 규칙을 대신 보라).
• 무엇보다 먼저 호스트명이 내가 생각하는 서버로 해석되는지 확인한다.
• 서버에서 데몬을 확인한다: systemctl status ssh / sshd. 죽었으면 sshd -t로 설정 오류를 찾고 재시작한다.
• 포트를 확인한다. ss -tlnp | grep sshd가 sshd의 바인딩을 보여준다. 22번이 아니면 -p <포트>로 접속하거나 되돌린다.
• 바인딩 주소를 확인한다. 127.0.0.1이면 localhost 전용 — 0.0.0.0이나 공인 인터페이스에 바인딩하고 재시작한다.
• 내 IP에서만 refused면 fail2ban / 침입 방지 jail을 확인하고 차단을 푼다.
• 변경할 때마다 포트 점검을 밖에서 다시 돌려 22번이 로컬에서만 듣는 게 아니라 실제로 닿는지 확인한다.

언제 에스컬레이션할까

• 포트 점검이 닫힘이 아니라 필터링 / timed out을 보고하면 이 가이드가 아닙니다 — 패킷이 sshd에 닿지 못하고 있습니다. 호스트 방화벽, 클라우드 보안 그룹, 네트워크 ACL을 보세요. 전부 인바운드를 조용히 버리는 게 기본값입니다.
• 콘솔 접근이 없는 관리형 인스턴스인데 sshd가 돌아오지 않으면, 대역 외 접근(클라우드 콘솔, 시리얼/레스큐 콘솔)을 가진 쪽으로 에스컬레이션하세요. SSH에서 잠기면 SSH를 고치는 데는 대개 SSH가 아닌 경로가 필요합니다.