ssh는 협상할 수 없습니다: "일치하는 비밀번호를 찾을 수 없습니다", cbc를 거부합니다

ssh는 협상할 수 없습니다: "일치하는 비밀번호를 찾을 수 없습니다", cbc를 거부합니다

원격 컴퓨터에 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, 클라이언트도 이를 사용할 수 있다는 것을 이해하는데 직접 사용해보면 어떨까요?

몇 가지 추가 참고 사항:

업데이트: 문제가 해결됨

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

  1. 터미널을 시작하십시오.
  2. 다음 줄을 터미널에 붙여넣습니다.sudo nano /etc/ssh/ssh_config
  3. 비밀번호를 입력하세요. 엔터 키를 치시오. SSH 구성 파일이 표시됩니다.
  4. 다음 줄의 주석 처리를 해제하세요.Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc
  5. 에 따르면 Ctrl + X. 저장하고 종료하려면 Enter를 누르세요.

답변4

저는 오랫동안 Synology 서버에서도 OP와 동일한 문제를 겪고 있었는데 이는 ssh -c aes256-cbc diskstation.local유용한 임시방편입니다. 그러나 서버가 오래된 비밀번호를 사용한다는 사실을 아는 것은 실제로 안심할 수 없습니다.

진짜 해결책은아니요내가 수년 동안 순진하게 알고 있었던 것처럼 Synology가 펌웨어를 업데이트할 때까지 기다리십시오(또는 최소한 업데이트만 하지 말고). 대신 서버 구성을 확인하십시오. 허용된 비밀번호는 뒤에 숨겨져 있습니다.터미널 및 SNMP>고급 매개변수. 옵션을 선택하면 최신 비밀번호가 허용되며, 낮은 보안 이외의 옵션을 선택하면 -cbc비밀번호가 무효화됩니다.

관련 정보