Windows 11에서 PuTTY·MobaXterm SSH 접속이 실패할 때 — 포트 22·Host Key·인증·방화벽 점검

작성자:
Windows 11에서 PuTTY·MobaXterm SSH 접속이 실패할 때 — 포트 22·Host Key·인증·방화벽 점검
Windows 11에서 PuTTY·MobaXterm SSH 접속이 실패할 때 — 포트 22·Host Key·인증·방화벽 점검

Windows 11에서 PuTTY나 MobaXterm으로 Linux 서버에 SSH 접속을 시도했지만 연결되지 않는 경우가 있습니다.

화면에는 Connection timed out, Connection refused, Access denied, Server refused our key처럼 서로 다른 오류가 나타날 수 있습니다.

이 오류들은 모두 “SSH가 안 된다”는 결과는 같지만 원인은 다릅니다.

예를 들어 Connection timed out이라면 비밀번호를 바꿔도 해결되지 않을 가능성이 높습니다. 아직 SSH 인증 단계까지 도달하지 못했을 수 있기 때문입니다.

반대로 Access denied가 표시된다면 서버와 TCP 연결 자체는 성립했고, 사용자 계정이나 인증 방식을 우선 확인하는 편이 효율적입니다.

따라서 PuTTY나 MobaXterm을 반복해서 재설치하기보다 어느 단계까지 정상적으로 진행됐는지를 먼저 구분해야 합니다.

먼저 확인할 내용

확인 기준 환경

  • OS: Windows 11 25H2
  • SSH Client: PuTTY 또는 MobaXterm
  • 비교 도구: Windows OpenSSH Client
  • 기본 SSH Port: TCP 22
  • 대상 서버: Linux 또는 OpenSSH Server 기준

Windows 11 25H2는 이 글의 확인 기준 OS이며, 아래의 모든 SSH 오류를 동일 환경에서 직접 재현했다는 의미는 아닙니다.

공식 문서 확인일: 2026-08-25

대표 증상

다음과 같은 상황을 대상으로 합니다.

  • PuTTY에서 Connection timed out 발생
  • PuTTY에서 Connection refused 발생
  • MobaXterm SSH Session이 연결되지 않음
  • 비밀번호 입력 후 Access denied 발생
  • Server refused our key 발생
  • No supported authentication methods available 발생
  • 처음 보는 Host Key 경고가 나타남
  • 기존 서버인데 Host Key 변경 경고가 발생함
  • PuTTY에서는 실패하지만 Windows ssh에서는 정상
  • Windows ssh, PuTTY, MobaXterm이 모두 실패함
  • SSH 로그인 직후 연결이 종료됨

결론

SSH 접속 문제는 다음 순서로 확인하는 것이 좋습니다.

Hostname / IP 확인
↓
DNS 확인
↓
TCP 22 연결 확인
↓
SSH 서버 서비스 및 Listen Port 확인
↓
Firewall / 네트워크 경로 확인
↓
Host Key 확인
↓
Password / Public Key 인증 확인
↓
PuTTY·MobaXterm 설정 확인
↓
Windows OpenSSH로 비교
↓
수정 후 동일 조건으로 재검증

핵심은 네트워크 문제와 인증 문제를 섞어서 해결하지 않는 것입니다.

1. 먼저 오류 메시지를 정확하게 구분하기

PuTTY 공식 문서에서도 대표적인 SSH 오류를 서로 다른 원인으로 구분합니다.

오류우선 확인할 영역
Connection timed outIP·Routing·Firewall·서버 상태
Connection refusedPort·SSH 서비스·Firewall Reject
Access denied사용자·Password·인증 정책
Server refused our keyPublic Key·계정·서버 설정·권한
No supported authentication methods availableClient와 Server의 인증 방식 불일치
Host Key 경고서버 식별 정보 변경 여부

따라서 오류 메시지를 그대로 기록하는 것이 좋습니다.

“PuTTY 접속 안 됨”보다:

PuTTY → TCP 22 → Connection timed out

처럼 정리하면 확인해야 할 범위가 크게 줄어듭니다.

2. Hostname과 IP 주소부터 확인

PuTTY 또는 MobaXterm의 SSH Session에서 먼저 다음 값을 확인합니다.

  • Remote Host
  • IP Address
  • Port
  • Username

예를 들어 서버 주소가 다음과 같다고 가정합니다.

server.example.com

SSH 기본 Port는 일반적으로:

22

입니다.

하지만 서버 관리자가 SSH Port를 2222, 22022 등으로 변경했다면 Client에서도 동일한 Port를 사용해야 합니다.

따라서 무조건 TCP 22라고 가정하지 말고 해당 서버가 실제 사용하는 SSH Port를 확인합니다.

3. Hostname을 사용한다면 DNS부터 확인

서버 IP가 아니라 Hostname으로 접속한다면 Windows PowerShell에서 다음 명령을 실행합니다.

Resolve-DnsName server.example.com

정상적으로 IP 주소가 반환되는지 확인합니다.

Microsoft 문서에서 Resolve-DnsName은 지정한 이름에 대해 DNS 조회를 수행하는 명령으로 설명됩니다.

예상한 서버 IP와 다른 주소가 반환된다면 SSH Client 설정을 수정하기 전에 DNS 상태부터 확인해야 합니다.

다음과 같은 경우도 확인합니다.

  • 오래된 DNS Record
  • VPN 연결 여부
  • 사내 DNS와 외부 DNS 결과 차이
  • Hosts 파일
  • Split DNS 환경

DNS 조회 자체가 실패한다면 Password나 Private Key를 수정할 단계가 아닙니다.

4. TCP 22 포트 연결 확인

다음으로 Windows에서 대상 서버의 SSH Port까지 TCP 연결이 가능한지 확인합니다.

기본 Port가 22라면:

Test-NetConnection server.example.com -Port 22

IP로도 확인할 수 있습니다.

Test-NetConnection 192.168.1.100 -Port 22

특히 다음 값을 확인합니다.

TcpTestSucceeded : True

Microsoft의 Test-NetConnection 문서에서도 -Port 옵션은 대상 시스템의 지정 TCP Port에 실제 연결을 시도하는 기능으로 설명됩니다.

True인 경우

최소한 Windows PC에서 대상 주소와 SSH Port까지 TCP 연결은 가능한 상태입니다.

그다음 SSH Protocol과 인증 문제로 범위를 좁힐 수 있습니다.

False인 경우

아직 Password나 Public Key를 확인할 단계가 아닐 가능성이 높습니다.

다음 영역을 우선 확인합니다.

  • 서버가 실행 중인지
  • SSH 서비스가 실행 중인지
  • SSH가 해당 Port에서 Listen 중인지
  • Windows 또는 서버 Firewall
  • 네트워크 Firewall
  • VPN
  • NAT
  • Cloud Security Group
  • Routing

5. Connection timed out이 발생하는 경우

PuTTY에서 다음 오류가 발생할 수 있습니다.

Network error: Connection timed out

PuTTY 공식 문서는 이 오류를 서버로부터 네트워크 응답을 받지 못한 상태로 설명합니다. 서버가 네트워크에서 격리되어 있거나 꺼져 있는 경우 등이 대표적인 원인입니다.

실무적으로는 다음 항목을 함께 확인합니다.

  • Hostname/IP 오입력
  • 서버 전원 또는 VM 상태
  • Routing
  • VPN 연결
  • TCP 22 Drop
  • 방화벽
  • Cloud Security Group
  • NAT/Port Forwarding

우선 다음 결과와 비교합니다.

Test-NetConnection server.example.com -Port 22

TcpTestSucceeded가 False라면 인증 문제보다 네트워크 연결 문제부터 확인합니다.

6. Connection refused가 발생하는 경우

다음 오류는 Timeout과 의미가 다릅니다.

Network error: Connection refused

PuTTY 공식 문서는 이 오류가 연결 요청 자체가 거부된 경우이며, 일반적으로 대상 시스템에서 해당 서비스를 제공하지 않거나 Port가 잘못된 상황 등을 확인하도록 설명합니다. 중간 Firewall이 연결을 적극적으로 거부하는 경우에도 비슷한 결과가 발생할 수 있습니다.

대표적으로 확인할 항목은 다음과 같습니다.

  • SSH 서비스 중지
  • SSH가 다른 Port에서 Listen
  • 잘못된 Port 입력
  • SSH Server 미설치
  • Firewall의 Reject 동작
  • 잘못된 Protocol 선택

예를 들어 SSH가 실제로 TCP 2222에서 동작한다면 PuTTY와 MobaXterm에도 2222를 설정해야 합니다.

7. 서버에서 SSH 서비스가 실행 중인지 확인

서버 관리 권한과 Console 접근이 가능하다면 서버 측 상태도 확인합니다.

Ubuntu / Debian 계열

sudo systemctl status ssh

RHEL / Rocky Linux / AlmaLinux 계열

sudo systemctl status sshd

배포판에 따라 서비스 이름이 다를 수 있습니다.

서비스가 active (running) 상태인지 확인합니다.

서비스가 중지되어 있다고 해서 즉시 재시작하기보다 먼저 왜 중지됐는지 로그를 확인하는 편이 좋습니다.

8. 서버가 실제 SSH Port를 Listen하는지 확인

Linux 서버에서는 다음 명령으로 Listening Socket을 확인할 수 있습니다.

sudo ss -lntp

Port 22만 간단하게 찾으려면:

sudo ss -lntp | grep ':22'

정상적인 SSH Server라면 환경에 따라 0.0.0.0:22, [::]:22 또는 특정 Interface 주소에서 Listen하고 있을 수 있습니다.

서버가 TCP 22를 Listen하지 않는다면 Client에서 Public Key를 바꿔도 연결되지 않습니다.

9. Windows OpenSSH Server라면 서비스와 Port 확인

대상 서버도 Windows라면 관리자 PowerShell에서 OpenSSH Server 서비스를 확인할 수 있습니다.

Get-Service -Name sshd

Microsoft의 최신 Windows OpenSSH Troubleshooting 문서에서도 먼저 sshd 서비스와 TCP 22 Listening 상태를 확인하도록 안내합니다.

Port 상태는 다음과 같이 확인할 수 있습니다.

netstat -an | findstr :22

정상적으로 Listen하고 있다면 환경에 따라 다음과 같은 상태를 볼 수 있습니다.

0.0.0.0:22 ... LISTENING

또는 IPv6 주소의 :22 Listening 상태가 표시될 수 있습니다.

10. Firewall은 Client와 Server 양쪽을 구분하기

TCP 22가 실패한다고 해서 무조건 Windows Defender Firewall만 끄는 것은 권장하지 않습니다.

확인해야 할 방화벽은 여러 위치에 있을 수 있습니다.

Windows Client
↓
로컬 Firewall / Endpoint Security
↓
네트워크 Firewall / VPN / Router
↓
Cloud Security Group 또는 ACL
↓
Server Firewall
↓
SSH Server

따라서 문제 해결을 위해 방화벽 전체를 비활성화하기보다 SSH Port가 실제로 허용되는지 규칙을 확인하는 방식이 좋습니다.

특히 인터넷에 노출된 서버에서는 TCP 22를 모든 주소에 무조건 허용하는 식으로 문제를 해결해서는 안 됩니다.

필요한 관리망이나 허용 IP 범위만 사용하는 정책을 우선 검토합니다.

11. Test-NetConnection은 성공하지만 PuTTY가 실패하는 경우

다음 결과가 정상이라고 가정합니다.

Test-NetConnection server.example.com -Port 22

그리고:

TcpTestSucceeded : True

가 표시되는데 PuTTY는 접속하지 못한다면 기본적인 TCP Port 도달성은 확인된 상태입니다.

이제 다음 영역으로 범위를 좁힙니다.

  • PuTTY SSH Session 설정
  • SSH Host Key
  • Username
  • Password
  • Public Key
  • SSH 인증 방식
  • Proxy
  • 알고리즘 호환성

즉 이 단계에서는 Router나 DNS부터 반복해서 확인하는 것보다 실제 SSH Client 로그를 보는 편이 효율적입니다.

12. 처음 접속하는 서버의 Host Key 확인

SSH 서버는 자신을 식별하기 위해 Host Key를 사용합니다.

PuTTY로 처음 서버에 연결하면 해당 서버의 Host Key가 아직 저장되어 있지 않기 때문에 확인 메시지가 나타날 수 있습니다.

여기서 중요한 것은:

처음 보는 Host Key → 무조건 Accept

가 아닙니다.

PuTTY 공식 문서는 처음 접속한 서버의 Host Key가 올바른지 Client 스스로 확인할 방법이 없기 때문에 다른 신뢰할 수 있는 방법으로 Key를 확인해야 한다고 안내합니다.

가장 좋은 방법은 서버 관리자 또는 관리 Console을 통해 제공된 Host Key Fingerprint와 Client에 표시되는 값을 비교하는 것입니다.

일치한다는 것을 확인한 뒤 신뢰합니다.

13. 기존 서버에서 Host Key 변경 경고가 나타나는 경우

이 경우에는 처음 접속할 때보다 더 주의해야 합니다.

이전에 저장한 Host Key와 현재 서버가 제시하는 Key가 다르다는 의미이기 때문입니다.

정상적인 원인도 있을 수 있습니다.

  • 서버 재설치
  • SSH Server 재구성
  • Host Key 재생성
  • 서버 교체
  • Load Balancer나 DNS 대상 변경

하지만 다음과 같은 문제도 배제할 수 없습니다.

  • 잘못된 서버에 접속
  • DNS 변조 또는 잘못된 DNS
  • IP 변경
  • 중간자 공격 가능성

PuTTY는 기존에 저장된 Host Key와 다른 Key가 제시될 경우 이를 보안 경고로 처리합니다.

따라서 경고가 귀찮다는 이유로 저장된 Host Key를 먼저 삭제해서는 안 됩니다.

먼저 서버 관리자에게 현재 Fingerprint를 확인하고 변경이 정상적인 작업 결과였는지 확인한 후 저장 정보를 갱신합니다.

14. PuTTY Host Key 저장 위치

Windows용 PuTTY는 저장된 Session과 SSH Host Key 정보를 Registry에 보관합니다.

공식 PuTTY FAQ에 따르면 기본 위치는 다음 영역입니다.

HKEY_CURRENT_USER\Software\SimonTatham\PuTTY

Host Key는 그 아래 SshHostKeys에 저장됩니다.

하지만 Host Key 오류가 발생했다고 Registry 값을 먼저 삭제하는 것은 권장하지 않습니다.

순서는 다음과 같습니다.

서버 Fingerprint 확인
↓
Host Key 변경이 정상인지 확인
↓
기존 저장값과 비교
↓
정상적인 변경일 때만 Cache 갱신

이렇게 진행해야 SSH Host Key 검증 기능의 의미를 유지할 수 있습니다.

15. Access denied가 발생하면 인증 단계 확인

PuTTY에서 Access denied 또는 Authentication 관련 오류가 나타난다면 기본적인 SSH 연결은 이미 상당 부분 진행된 상태일 가능성이 높습니다.

PuTTY 공식 문서에서 Access denied는 Client가 시도한 인증 방법을 서버가 모두 거절한 상황으로 설명합니다.

다음 항목을 확인합니다.

  • Username
  • Password
  • 계정 잠금 여부
  • Password 로그인 허용 여부
  • Public Key 필요 여부
  • 관리자/Root 로그인 제한
  • MFA 또는 Keyboard-interactive 인증
  • SSH Server 정책

특히 Username이 틀린 경우 Password가 정확해도 인증되지 않습니다.

16. 비밀번호 인증이 실패하는 경우

Password가 맞다고 생각되는데 인증이 되지 않는다면 다음 조건을 확인합니다.

  • 실제 SSH 계정 이름
  • 대소문자
  • 계정 잠금
  • Password 만료
  • SSH Server에서 PasswordAuthentication 허용 여부
  • Root 로그인 정책
  • PAM 또는 MFA 정책

같은 Password로 Web Console에 로그인된다는 이유만으로 SSH에서도 동일 인증 방식이 허용된다고 단정하면 안 됩니다.

SSH Server 정책에서 Password 인증 자체를 제한할 수 있기 때문입니다.

17. Server refused our key 오류 확인

Public Key 인증 환경에서는 PuTTY에 다음과 같은 오류가 나타날 수 있습니다.

Server refused our key

또는:

Server refused our public key

PuTTY 공식 문서는 이 메시지를 Client가 Public Key를 서버에 제시했지만 서버가 인증에 사용할 Key로 받아들이지 않은 경우로 설명합니다.

이 경우 다음을 확인합니다.

  • 올바른 사용자 계정인지
  • 해당 계정의 authorized_keys에 Public Key가 등록돼 있는지
  • Private Key와 Public Key가 실제 쌍인지
  • Server의 Public Key Authentication이 활성화돼 있는지
  • .ssh 및 authorized_keys 권한
  • 파일 소유자
  • 잘못된 Key 파일 선택

Linux Server에서는 특히 .ssh와 authorized_keys의 소유자 및 권한이 잘못돼 있으면 Public Key 인증이 거부될 수 있습니다.

18. PuTTY Private Key 설정 위치 확인

최신 PuTTY에서는 과거 블로그 글과 메뉴 위치가 다를 수 있습니다.

PuTTY 0.78 이후 Private Key 설정은 다음 경로에 있습니다.

Connection → SSH → Auth → Credentials

여기에서 Private key file for authentication을 지정합니다.

현재 PuTTY 0.84 공식 문서에서도 이 위치를 안내하고 있으며 PuTTY가 직접 사용하는 Private Key는 기본적으로 .PPK 형식을 사용합니다.

따라서 오래된 글에서:

Connection → SSH → Auth에서 바로 Private Key 선택

이라고 설명하는 화면과 현재 UI가 다를 수 있습니다.

19. OpenSSH Private Key를 PuTTY에서 바로 사용하지 못하는 경우

PuTTY에서 Key 파일을 불러왔는데 다음과 같은 오류가 발생할 수 있습니다.

Unable to use key file

또는:

Couldn't load private key

PuTTY 공식 문서는 호환되지 않는 Private Key 형식을 사용하는 것이 대표적인 원인이라고 설명하며, 다른 형식의 Key는 PuTTYgen을 통해 PuTTY 형식으로 가져올 수 있습니다.

따라서 Key 파일이 열리지 않는다고 새로운 SSH Key부터 생성하면 안 됩니다.

먼저:

  • 현재 Private Key 형식
  • 해당 Key의 Public Key
  • Server에 등록된 Public Key
  • PuTTY에서 지원하는 형식

을 확인합니다.

잘못해서 새 Key를 생성하면 기존 서버에 등록된 Public Key와 짝이 달라지기 때문에 인증은 계속 실패합니다.

20. MobaXterm의 SSH Session 설정 확인

MobaXterm에서는:

Session → SSH

에서 SSH Session을 생성할 수 있습니다.

공식 MobaXterm 문서에서 SSH Session에는 다음과 같은 설정을 제공합니다.

  • Remote host
  • Specify username
  • Port
  • Use private key
  • X11 Forwarding
  • SSH Browser

따라서 PuTTY에서는 정상인데 MobaXterm에서만 실패한다면 먼저 다음 값을 서로 비교합니다.

PuTTY

  • Host
  • Port
  • Username
  • Key

MobaXterm

  • Remote host
  • Port
  • Username
  • Private Key

MobaXterm의 SSH Client도 PuTTY 기반 기술을 활용하므로 동일 SSH Server에 접근할 수 있지만, 저장된 Session 설정이 서로 다르면 결과 역시 달라질 수 있습니다.

21. SSH Gateway를 사용하는 환경인지 확인

회사 네트워크에서는 대상 서버에 직접 SSH 접속하지 않고 Jump Host 또는 Bastion을 거치는 경우가 있습니다.

MobaXterm 공식 문서는 Connect through SSH gateway 기능을 제공하며 먼저 Gateway에 SSH Tunnel을 생성한 뒤 최종 서버로 접속하는 구조를 지원합니다.

구조는 다음과 같습니다.

Windows PC → SSH Gateway → 대상 서버

따라서 이전 환경에서는 Gateway를 사용했는데 새 Session에서 Gateway 설정이 빠졌다면 대상 서버로 직접 접근할 수 없어 Timeout이 발생할 수 있습니다.

이 경우 TCP 22 테스트도 어디를 대상으로 하는지 구분해야 합니다.

  • Gateway의 TCP 22
  • 최종 Server의 TCP 22
  • Gateway에서 최종 Server로의 접근

세 영역은 서로 다른 연결입니다.

22. Windows OpenSSH Client로 비교 테스트

Windows에 OpenSSH Client가 설치되어 있다면 PuTTY/MobaXterm과 결과를 비교할 수 있습니다.

PowerShell에서 먼저 SSH Client를 확인합니다.

ssh -V

그다음 동일한 서버와 사용자로 접속합니다.

ssh [email protected]

SSH Port가 기본값이 아니라면:

ssh -p 2222 [email protected]

를 사용합니다.

결과 비교

PuTTY 실패 + Windows ssh 성공

→ PuTTY Session·Proxy·Key·저장 설정 우선 확인

MobaXterm 실패 + Windows ssh 성공

→ MobaXterm Session·Private Key·Gateway 설정 우선 확인

PuTTY + MobaXterm + Windows ssh 모두 실패

→ Server·Network·Firewall·인증 정책 등 공통 요소를 우선 확인

Client를 하나 더 설치하기 위한 목적이 아니라 문제 범위를 나누기 위한 비교 테스트입니다.

23. ssh -vvv로 연결 단계를 자세히 확인

Windows OpenSSH에서는 Verbose Mode를 이용해 SSH 연결 과정을 확인할 수 있습니다.

ssh -vvv [email protected]

Microsoft 최신 OpenSSH Troubleshooting 문서에서도 SSH 연결 진단 시 ssh -vvv를 사용해 상세 디버그 출력을 수집하도록 안내합니다.

출력에서는 다음 흐름을 확인합니다.

  • Hostname 해석
  • 대상 IP
  • 연결 Port
  • TCP 연결
  • Host Key 협상
  • 사용자 인증
  • 제공한 Public Key
  • 서버가 허용한 인증 방식

예를 들어 TCP 연결 단계에서 멈춘다면 인증 문제보다 앞단입니다.

반대로 Public Key를 제시한 이후 Server가 Key를 거부한다면 네트워크보다 인증 구성을 확인해야 합니다.

24. No supported authentication methods available 오류

PuTTY에서 다음 오류가 발생할 수 있습니다.

No supported authentication methods available

PuTTY 공식 문서는 이 메시지를 사용할 수 있는 인증 방법이 더 이상 없는 상태로 설명합니다.

예를 들어 Server는 Public Key 인증만 허용하지만 Client에는 사용할 Key가 설정되지 않은 상황일 수 있습니다.

또는 Server가 요구하는 인증 방법과 Client의 활성화된 방법이 맞지 않을 수도 있습니다.

다음 항목을 확인합니다.

  • Server가 허용하는 인증 방식
  • Password Authentication
  • Public Key Authentication
  • Keyboard-interactive
  • MFA
  • PuTTY Authentication 설정
  • 올바른 Private Key 선택 여부

오류를 없애기 위해 Server의 인증 정책을 무조건 완화하지 않는 것이 중요합니다.

25. 레거시 SSH 알고리즘 오류는 무작정 약한 알고리즘을 활성화하지 않기

오래된 서버나 네트워크 장비에서는 최신 SSH Client와 Algorithm 협상이 되지 않는 경우도 있습니다.

이때 다음과 같은 유형의 오류가 발생할 수 있습니다.

  • Host Key Algorithm 불일치
  • Cipher 불일치
  • 오래된 ssh-rsa 의존
  • 구형 SSH 구현

Microsoft도 최신 OpenSSH 환경에서 Algorithm 불일치가 연결 실패의 원인이 될 수 있다고 설명합니다. 다만 레거시 Algorithm을 다시 허용하는 설정은 임시 호환성 조치로만 사용하고 이후 제거하는 방향을 권장합니다.

따라서 문제 해결을 위해 무조건 보안 수준을 낮추기보다:

Server 또는 장비 업데이트 가능 여부

를 먼저 확인하는 것이 좋습니다.

26. PuTTY Event Log 확인

PuTTY에서는 접속 과정의 상세 정보를 Event Log에서 확인할 수 있습니다.

Session을 실행한 뒤 PuTTY 창의 메뉴에서 Event Log를 확인합니다.

PuTTY 공식 문서에서도 Public Key 거부나 인증 문제 발생 시 Event Log에 Server가 보낸 추가 진단 메시지가 있을 수 있으므로 확인하도록 안내합니다.

특히 다음과 같은 문제에서 유용합니다.

  • Server refused our key
  • Authentication refused
  • Host Key 관련 문제
  • SSH Algorithm 협상
  • Proxy 연결
  • Session 종료 원인

화면에 표시된 마지막 한 줄만 보지 말고 Event Log 앞부분부터 확인하는 것이 좋습니다.

27. MobaXterm 로그를 사용할 때 주의

MobaXterm은 Terminal Output을 파일로 기록하는 기능을 제공합니다.

장시간 발생하는 접속 종료 문제나 반복 장애를 확인할 때 로그를 사용할 수 있습니다.

다만 SSH Terminal 로그에는 다음 정보가 포함될 수 있습니다.

  • Username
  • Hostname
  • 내부 IP
  • 서버 명령어
  • 파일 경로
  • 애플리케이션 정보
  • 사용자 데이터

따라서 로그를 게시글이나 외부 서비스에 첨부하기 전에 민감정보를 제거해야 합니다.

Private Key 파일은 어떤 경우에도 공유해서는 안 됩니다.

28. SSH 로그인 직후 연결이 끊기는 경우

TCP 연결과 인증까지 성공했는데 SSH Session이 바로 종료된다면 앞의 Timeout과는 다른 문제입니다.

이 경우에는 Server 측 로그와 사용자 Shell 환경도 확인해야 합니다.

대표적인 확인 영역은 다음과 같습니다.

  • SSH Server 로그
  • 사용자 Login Shell
  • Shell 초기화 스크립트
  • 계정 정책
  • 강제 실행 명령
  • Session Timeout
  • 방화벽/NAT Idle Timeout
  • 서버 프로세스 종료

PuTTY 공식 문서에서도 Connection reset by peer는 Server 종료나 Firewall/NAT에 의한 Session 상태 손실 등과 연관될 수 있다고 설명합니다.

단순한 최초 연결 실패와 연결 후 세션 종료 문제를 구분해야 합니다.

29. 서버 로그를 확인할 수 있다면 Client 오류와 비교

서버 관리 권한이 있다면 Client 오류와 Server 로그를 같은 시각으로 비교하는 것이 좋습니다.

Ubuntu/Debian 계열에서는 환경에 따라:

sudo journalctl -u ssh

RHEL 계열에서는:

sudo journalctl -u sshd

등으로 Service 관련 로그를 확인할 수 있습니다.

다만 실제 SSH 인증 로그 위치는 Linux 배포판과 로깅 구성에 따라 다를 수 있습니다.

중요한 것은:

Client 오류 발생 시간

과:

Server 로그 시간

을 맞춰 보는 것입니다.

Client에서는 Access denied 하나만 보이더라도 Server에서는 계정, Key, 정책과 관련된 더 구체적인 이유를 확인할 수 있습니다.

30. Windows OpenSSH Server의 상세 로그가 필요한 경우

대상 서버가 Windows OpenSSH Server이고 기본 로그만으로 원인을 찾기 어렵다면 Microsoft가 제공하는 Verbose Logging 방식을 사용할 수 있습니다.

기본 설정 파일은:

%ProgramData%\ssh\sshd_config

입니다.

Microsoft 문서에서는 LogLevel VERBOSE를 설정하고 sshd 서비스를 재시작하면 상세 로그를 얻을 수 있다고 설명합니다.

다만 운영 서버에서는 로그 수준 변경이 로그 발생량과 개인정보·시스템 정보 노출에 영향을 줄 수 있으므로 문제 분석 기간에만 필요한 범위로 적용하고 이후 원래 정책으로 되돌리는 것이 좋습니다.

31. Wireshark로 TCP 22 연결 자체를 확인

PuTTY, MobaXterm, Windows OpenSSH가 모두 실패하고 Test-NetConnection에서도 명확한 원인을 찾기 어렵다면 Wireshark를 활용할 수 있습니다.

확인 흐름은 다음과 같습니다.

DNS Query
↓
서버 IP 확인
↓
TCP SYN → Port 22
↓
SYN/ACK 또는 RST 확인
↓
SSH Protocol 시작 여부

예를 들어 SYN만 반복되고 응답이 없다면 Timeout 영역으로 볼 수 있습니다.

SYN 이후 즉시 RST가 돌아온다면 Connection Refused에 가까운 상황을 확인할 수 있습니다.

Wireshark 기본 캡처와 필터 확인은 다음 글과 연결할 수 있습니다.

Windows에서 Wireshark 설치 후 패킷 캡처 확인하기 — Npcap·인터페이스·필터 점검

패킷을 확인할 때는 자신이 관리하거나 분석 권한이 있는 네트워크와 시스템에서만 캡처합니다.

32. 여러 설정을 한꺼번에 변경하지 않기

SSH 연결이 되지 않는다고 다음 작업을 동시에 진행하는 것은 권장하지 않습니다.

Firewall 전체 비활성화

sshd_config 수정

Private Key 새로 생성

Host Key Cache 삭제

PuTTY 재설치

이렇게 하면 어떤 설정이 실제 원인이었는지 확인하기 어렵습니다.

다음처럼 한 단계씩 진행합니다.

오류 메시지 기록
↓
DNS 확인
↓
TCP Port 확인
↓
SSH Service 확인
↓
Host Key 확인
↓
인증 확인
↓
Client 로그 비교
↓
필요한 설정 하나만 수정
↓
동일 조건으로 재검증

이 방식이 문제 해결 후 같은 장애가 다시 발생했을 때도 훨씬 유용합니다.

33. 수정 후 정상 여부 최종 검증

설정을 변경했다면 처음 사용했던 확인 방법으로 다시 검증합니다.

DNS

Resolve-DnsName server.example.com

예상한 IP가 반환되는지 확인합니다.

TCP SSH Port

Test-NetConnection server.example.com -Port 22

TcpTestSucceeded : True인지 확인합니다.

Windows OpenSSH 비교

ssh -vvv [email protected]

Host Key와 인증이 정상적으로 진행되는지 확인합니다.

PuTTY

동일 Host, Port, Username으로 다시 연결합니다.

MobaXterm

동일 Remote Host, Port, Username, Key 설정으로 다시 연결합니다.

최종적으로 Remote Shell에 로그인한 뒤 간단한 명령을 실행하고 Session이 안정적으로 유지되는지도 확인합니다.

해결되지 않는 경우 추가 확인

문제가 계속된다면 다음 정보를 먼저 정리합니다.

  • Windows 버전
  • PuTTY 또는 MobaXterm 버전
  • SSH Server 주소
  • SSH Port
  • 발생한 정확한 오류 메시지
  • Resolve-DnsName 결과
  • Test-NetConnection 결과
  • Windows ssh -vvv 결과
  • PuTTY Event Log
  • Password 또는 Public Key 인증 여부
  • VPN 사용 여부
  • Proxy 또는 SSH Gateway 사용 여부
  • Server SSH 서비스 상태
  • Server Listening Port
  • 오류 발생 시간

이 정보를 기준으로:

Client 문제인지

Network 문제인지

Server 문제인지

Authentication 문제인지

를 구분합니다.

주의사항

SSH 문제를 확인할 때 다음 사항을 주의합니다.

  • Host Key 경고를 확인 없이 무조건 Accept하지 않기
  • Host Key Cache를 이유 없이 삭제하지 않기
  • Private Key를 메신저·게시글·로그에 노출하지 않기
  • Private Key와 Public Key의 쌍을 임의로 변경하지 않기
  • Firewall 전체를 장시간 비활성화하지 않기
  • 인터넷에 TCP 22를 무조건 전체 개방하지 않기
  • 레거시 SSH Algorithm을 영구적으로 허용하지 않기
  • Server 인증 정책을 문제 해결 목적으로 무조건 약화하지 않기
  • PuTTY 재설치를 첫 번째 해결 방법으로 사용하지 않기
  • 로그 공유 전 Hostname·IP·Username 등 민감정보 확인
  • 설정 변경 후 동일 조건으로 반드시 재검증하기

마무리

Windows 11에서 PuTTY나 MobaXterm SSH 접속이 실패할 때 가장 중요한 것은 네트워크 오류와 인증 오류를 먼저 구분하는 것입니다.

Connection timed out이 발생한다면 Password나 Private Key부터 바꾸기보다:

Hostname / IP → DNS → TCP Port → Firewall → SSH Server

순서로 확인합니다.

Connection refused가 발생한다면 대상 서버까지의 연결 요청이 거부된 상황이므로:

SSH Port → SSH 서비스 → Listening 상태 → Firewall Reject

를 확인합니다.

반대로 Access denied, Server refused our key 같은 메시지가 나타난다면 TCP 연결 이후의 인증 단계로 범위를 좁힙니다.

이 경우에는:

Username → Server 인증 정책 → Password/Public Key → Private Key 설정 → Server 로그

순서가 더 적절합니다.

Host Key 경고도 단순한 접속 방해 메시지가 아닙니다.

SSH가 현재 접속 중인 서버가 이전에 신뢰했던 서버와 같은 시스템인지 확인하는 중요한 보안 기능이므로 Fingerprint를 별도 신뢰 경로로 확인한 뒤 처리해야 합니다.

전체 흐름을 정리하면 다음과 같습니다.

SSH 접속 실패
↓
오류 메시지 확인
↓
DNS 정상 여부
↓
TCP SSH Port 연결
↓
SSH Server / Firewall
↓
Host Key 검증
↓
Password / Public Key 인증
↓
PuTTY·MobaXterm 설정 확인
↓
Windows ssh -vvv 비교
↓
Client / Server 로그 확인
↓
필요한 설정만 변경
↓
같은 조건으로 재검증

예를 들어 Test-NetConnection에서 TCP 22가 실패하는데 Private Key를 계속 변경하는 것은 문제 해결에 도움이 되지 않습니다.

반대로 TCP 22가 정상이고 Server가 실제로 Access denied를 반환하고 있다면 네트워크 장비보다 계정과 인증 정책을 확인하는 편이 효율적입니다.

결국 SSH 문제 해결의 핵심도 어느 계층까지 정상적으로 진행됐는지를 확인하는 것입니다.

PuTTY와 MobaXterm을 단순 원격 접속 프로그램으로 사용하는 것보다 DNS → TCP → SSH → Host Key → 인증 단계로 나누어 확인하면 SSH 장애 원인을 훨씬 명확하게 좁힐 수 있습니다.

참고 자료

변경 이력

2026-08-25

  • 기존 PuTTY·MobaXterm 설치 및 기본 사용 중심 콘텐츠를 SSH 접속 실패 진단 중심으로 개편
  • Windows 11 25H2 확인 기준 환경 반영
  • Connection timed out과 Connection refused 원인 구분 추가
  • Resolve-DnsName, Test-NetConnection 기반 네트워크 진단 추가
  • SSH Server 서비스 및 Listening Port 확인 절차 추가
  • Host Key 신규·변경 경고의 안전한 확인 절차 추가
  • Access denied, Server refused our key 인증 오류 구분 추가
  • PuTTY 0.78 이후 Private Key 설정 경로 변경 내용 반영
  • MobaXterm SSH Session·Private Key·SSH Gateway 확인 절차 추가
  • Windows OpenSSH ssh -vvv 비교 진단 추가
  • PuTTY Event Log 및 Server 로그 확인 절차 추가
  • Wireshark를 이용한 TCP 22 추가 확인 흐름 연결
  • 수정 후 동일 조건으로 재검증하는 절차 추가

Post Views: 48