원격 컴퓨터에 SSH를 통해 연결하려고 하는데 실패합니다.
$ ssh -vvv [email protected]
OpenSSH_7.7p1, OpenSSL 1.0.2o 27 Mar 2018
.....
debug2: ciphers ctos: aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
debug2: ciphers stoc: aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
debug2: MACs ctos: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,[email protected]
debug2: compression stoc: none,[email protected]
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: rsa-sha2-512
Unable to negotiate with 192.168.100.14 port 22: no matching cipher found. Their offer: aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
내가 로그의 마지막 문자열을 이해하는 한, 서버는 다음 4가지 암호화 알고리즘 중 하나를 사용할 것을 권장합니다 aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
. 내 SSH 클라이언트가 이들 중 하나를 지원하지 않는 것 같으므로 서버와 클라이언트가 더 이상 협상할 수 없습니다.
하지만 내 고객은 제안된 모든 알고리즘을 지원합니다.
$ ssh -Q cipher
3des-cbc
aes128-cbc
aes192-cbc
aes256-cbc
[email protected]
aes128-ctr
... and there are several more.
다음과 같이 알고리즘을 명시적으로 지정하는 경우:
ssh -vvv -c aes256-cbc [email protected]
서버에 성공적으로 로그인할 수 있습니다.
내 비밀번호 ~/.ssh/config
에는 비밀번호 관련 지침이 포함되어 있지 않습니다(실제로 완전히 제거했지만 문제가 지속됩니다).
그렇다면 왜 클라이언트와 서버는 나의 명시적인 지시 없이 사용할 암호를 결정할 수 없는 걸까요? 클라이언트는 서버가 지원한다는 것을 알고 aes256-cbc
, 클라이언트도 이를 사용할 수 있다는 것을 이해하는데 직접 사용해보면 어떨까요?
몇 가지 추가 참고 사항:
얼마 전까지만 해도(한 달 정도) 그런 문제는 없었습니다. 그 이후로 SSH 구성 파일을 변경하지 않았습니다. 그래도 설치된 패키지를 업데이트했습니다.
매우 유사한 문제를 설명하는 질문이 있지만 내 질문에 대답하지 않습니다.SSH가 협상할 수 없습니다. 일치하는 키 교환 방법을 찾을 수 없습니다.
업데이트: 문제가 해결됨
TelcoM이 설명했듯이 문제는 서버에 있습니다. 서버는 오래된 암호화 알고리즘만 사용하도록 권장합니다. 클라이언트도 서버도 오래되지 않았다고 확신합니다. 서버에 로그인하고(그런데 Synology는 사용 가능한 최신 버전으로 업데이트되었습니다) /etc/ssh/sshd_config
파일의 첫 번째 줄(!)을 확인했습니다.
Ciphers aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
이것은 이상하며(이 줄이 파일의 첫 번째 줄이라는 사실) 이전에 해당 파일을 만져본 적이 없다고 확신합니다. 그러나 나는 줄을 다음과 같이 변경했습니다.
Ciphers aes256-ctr,aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
서버를 다시 시작했는데(서비스를 다시 시작하는 방법을 몰랐음 sshd
) 이제 문제가 사라졌습니다. 평소처럼 서버에 SSH를 통해 연결할 수 있습니다.
답변1
-cbc
이러한 알고리즘은 공격에 취약한 것으로 나타났습니다 .결과적으로 최신 버전의 OpenSSH는 이제 기본적으로 이러한 알고리즘을 거부합니다. 현재는 필요한 경우 계속 사용할 수 있지만 발견한 대로 명시적으로 활성화해야 합니다.
처음에 취약점이 발견되었을 때(2008년 말, 거의 10년 전!) 이러한 알고리즘은 호환성 이유로 우선 순위 목록의 맨 아래에 배치되었지만 이제 SSH에서의 사용 중단은 제거 단계에 도달했습니다. 기본적으로 비활성화되어 있습니다. ~에 따르면Cryptography.SE의 이 문제, 이 지원 중단 단계는 이미 2014년 초에 발생했습니다.
이 알림을 친절하게 생각해 주세요.SSH 서버 업데이트,가능하다면. (펌웨어 기반 구현인 경우 하드웨어에 사용할 수 있는 최신 펌웨어가 있는지 확인하세요.)
답변2
내부에 파일을 생성하세요.~/.ssh/config그리고 다음을 붙여넣으세요
Host 192.168.100.14
SendEnv LANG LC_*
Ciphers +aes256-cbc
답변3
다음 위치에 있는 파일에서 SSH 구성을 업데이트할 수 있습니다./etc/ssh/ssh_config
- 터미널을 시작하십시오.
- 다음 줄을 터미널에 붙여넣습니다.
sudo nano /etc/ssh/ssh_config
- 비밀번호를 입력하세요. 엔터 키를 치시오. SSH 구성 파일이 표시됩니다.
- 다음 줄의 주석 처리를 해제하세요.
Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc
- 에 따르면
Ctrl + X
. 저장하고 종료하려면 Enter를 누르세요.
답변4
저는 오랫동안 Synology 서버에서도 OP와 동일한 문제를 겪고 있었는데 이는 ssh -c aes256-cbc diskstation.local
유용한 임시방편입니다. 그러나 서버가 오래된 비밀번호를 사용한다는 사실을 아는 것은 실제로 안심할 수 없습니다.
진짜 해결책은아니요내가 수년 동안 순진하게 알고 있었던 것처럼 Synology가 펌웨어를 업데이트할 때까지 기다리십시오(또는 최소한 업데이트만 하지 말고). 대신 서버 구성을 확인하십시오. 허용된 비밀번호는 뒤에 숨겨져 있습니다.터미널 및 SNMP>고급 매개변수. 옵션을 선택하면 최신 비밀번호가 허용되며, 낮은 보안 이외의 옵션을 선택하면 -cbc
비밀번호가 무효화됩니다.