많은 경우 ssh_exchange_identification: Connection closed by remote host 오류는 hosts.deny 및 hosts.allow 설정 파일 관련 문제로 발생하지만, 그 외에도 다양한 원인이 있을 수 있습니다. 이 글을 읽고 계시다면 이미 두 파일이 IP 주소를 차단하고 있지 않은지 확인해 보셨을 가능성이 높습니다.
그렇다면 종속성 문제, 메모리 단편화, 또는 개별 클라이언트에서 과도한 세션이 생성되는 상황을 의심해 볼 필요가 있습니다. 다행히 근본 원인을 해결하면 이 오류는 다시 나타나지 않습니다.
방법 1: 누락된 종속성 수정
OpenSSL 또는 glibc를 업데이트한 후에만 이 오류가 발생했다면 누락된 종속성이 원인일 가능성이 큽니다. 이 경우 명령줄에서 sudo lsof -n | grep ssh | grep DEL 명령을 실행하세요. 열려 있는 파일 목록이 출력되며, 그중 최근 삭제된 ssh 데몬 관련 파일만 골라내면 됩니다.
아무것도 출력되지 않더라도 데몬이나 시스템 자체를 재시작해 볼 수 있습니다. 여러 오류가 반환되었다면 재시작을 시도하는 것이 좋습니다. 다만 /run/user/1000/gvfs 관련 메시지는 가상 파일 시스템과 관련된 별개의 문제로 인한 것이므로 무시해도 안전합니다.
종속성이 문제라고 판단되면 apt-get, pacman, yum 등의 패키지 관리자로 업데이트를 진행할 수도 있습니다. Debian 또는 Ubuntu 기반 시스템이라면 sudo apt-get -f upgrade를 실행하여 손상된 패키지를 복구해 보세요.
방법 2: 메모리 단편화 문제 해결
위 방법으로 해결되지 않았다면 호스트 측에 문제가 있을 수 있습니다. VM(가상 머신)에서 실행되는 호스트는 스왑 파티션이 없는 경우가 많아 메모리 단편화가 발생하기 쉽습니다. 다른 경로로 호스트에 접근하거나 가능하다면 물리적으로 접근하여 문제가 있는 서비스를 재시작하세요. MySQL, Apache, nginx 등이 범인인 경우가 많습니다.
호스트 재부팅이 항상 가능한 것은 아니지만, 문제를 해결하는 효과적인 방법입니다. 특히 이 오류와 IP 주소를 반환하는 오류가 번갈아 나타난다면 재부팅을 적극적으로 고려해 보세요. 서버에 어떤 형태로든 접근 권한이 있다면 vmstat -s 명령을 통해 일반 사용자 권한으로도 메모리 사용 현황에 대한 중요한 통계를 확인할 수 있습니다.
방법 3: 불필요한 SSH 세션 확인
문제가 계속된다면 다른 호스트들이 서버에 접속을 시도하고 있는지 확인하세요. 모르는 사이에 최대 SSH 세션 수를 초과했을 수 있습니다. 기존 세션을 정리한 후 다시 연결해 보세요. 간단한 방법은 who 명령을 실행하여 로그인된 사용자 프로세스를 확인하는 것입니다. 보통 한두 명의 사용자만 로그인되어 있어야 하며, 여러 세션이 병렬로 존재한다면 해당 사용자 프로세스를 종료한 후 다시 로그인해 보세요.
이 문제는 루프 안에서 여러 SSH 세션을 반복적으로 시작하는 스크립트를 sshd가 감당하지 못할 때 발생할 수 있습니다. 이런 상황이라면 루프에 sleep 0.3 명령을 추가하여 sshd 데몬이 요청을 처리할 시간을 확보해 주세요.
방법 4: sshd 연결 제한 확인
이러한 연결 문제는 SSH로 라우터나 독립형 스위치 장비에 접속할 때 특히 흔하게 발생합니다. 기본 최대 연결 수가 매우 작게 설정되어 있기 때문입니다. 서버에 과부하를 주고 싶지는 않겠지만, 기본 설정값이 어느 정도인지 확인해 볼 수는 있습니다.
서버에서 
명령을 실행하여 sshd가 처리할 수 있는 최대 연결 수를 확인하세요. 대부분의 시스템은 동시 접속 10개를 기본값으로 사용하며, 일반적인 서버 환경에서는 충분한 수준입니다.