명령줄 메일을 사용하는 데 문제가 있어서 DSL 라우터에 로그인하려고 합니다. 라우터를 재구성하고 싶습니다.
ssh
명령을 실행하면 다음과 같은 일이 발생합니다.
$ ssh [email protected]
Unable to negotiate with 10.255.252.1 port 22: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1
그러다가 보니이 스택 교환 게시물, 이를 수행하도록 명령을 수정했지만 이번에는 비밀번호와 관련하여 다른 문제가 발생했습니다.
$ ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 [email protected]
Unable to negotiate with 10.255.252.1 port 22: no matching cipher found. Their offer: 3des-cbc
그래서 요령이 있어요공급 3des-cbc
암호화? 3des를 내 시스템에 영구적으로 추가하고 싶은지 잘 모르겠습니다.
비밀번호를 허용하는 명령이 있나요 3des-cbc
?
여기서 문제가 무엇입니까? 비밀번호를 묻지 않습니다.
답변1
이 특정 오류는 암호화된 채널을 설정할 때 발생합니다. 시스템과 원격 시스템이 하나 이상의 비밀번호를 공유하지 않는 경우 합의된 비밀번호에 동의할 수 없으며 암호화된 채널이 존재할 수 없습니다. 일반적으로 SSH 서버는 다양한 클라이언트 요구에 맞게 몇 가지 다른 암호를 제공합니다. 서버가 3DES-CBC만 허용하도록 구성된 이유는 확실하지 않습니다.
이제 3DES-CBC는 끔찍하지 않습니다. 느리지만 제공합니다.덜 안전함다른 알고리즘과 비교하면 키를 올바르게 선택하면 즉시 크랙되지 않습니다.CBC 자체에도 몇 가지 문제가 있습니다.암호문은 전송 중에 수정될 수 있지만 이로 인해 발생하는 손상은 SSH의 HMAC에 의해 거부되어 영향이 줄어들 것이라고 강력히 의심합니다. 전체적으로 3DES-CBC보다 나쁜 옵션도 있고 더 나은 옵션도 있습니다. 하지만,암호 및 키 교환 알고리즘 선택을 포함하여 보안 관련 기본값을 재정의할 때는 주의하십시오.이러한 기본값에는 이유가 있습니다. 일부 매우 똑똑한 사람들은 이러한 옵션에 대해 생각하고 기본값으로 선택한 옵션이 최상의 전반적인 보안과 성능 균형을 제공한다고 결정했습니다.
알아낸 대로 -c ...
(또는 -oCiphers=...
)를 사용하여 클라이언트에서 제공할 암호를 지정할 수 있습니다. 이 경우 -c 3des-cbc
클라이언트에서 3DES-CBC만 허용하도록 추가하세요. 이는 서버에서 제공한 비밀번호와 일치하므로 암호화된 채널이 성립되고 연결이 인증 단계로 들어갑니다.
~/.ssh/config
로컬 문제를 해결하기 위해 전역 변경을 하지 않으려면 Host
섹션에 추가할 수도 있습니다. 예를 들어 SSH 구성이 현재 표시되는 경우(더미 예):
Port 9922
기본값 22 대신 전역 기본 포트 9922를 지정하면 특별한 구성이 필요한 호스트에 대한 호스트 섹션과 기본 경우에 대한 전역 호스트 섹션을 추가할 수 있습니다. 그것은 다음과 같이 변할 것입니다 ...
Host 10.255.252.1
Ciphers 3des-cbc
KexAlgorithms +diffie-hellman-group1-sha1
Host *
Port 9922
들여쓰기는 선택 사항이지만 가독성이 크게 향상됩니다. 빈 줄과 로 시작하는 줄은 #
무시됩니다.
이 시스템에서 항상(또는 대부분) 동일한 사용자로 로그인되어 있는 경우 해당 사용자 이름을 지정할 수도 있습니다.
Host 10.255.252.1
Ciphers 3des-cbc
KexAlgorithms +diffie-hellman-group1-sha1
User enduser
Host *
Port 9922
~/.ssh/config에 아무것도 없으면 Host *
스탠자를 추가할 필요가 없습니다. 이 경우 컴파일 또는 시스템 전체 기본값(보통 /etc/ssh/ssh_config)만 사용되기 때문입니다.
이 시점에서 호스트에 연결하기 위한 SSH 명령줄은 간단한 명령줄로 축소됩니다.
$ ssh 10.255.252.1
시스템의 다른 모든 사용자 및 다른 모든 호스트에 대한 시스템 연결은 변경 사항의 영향을 받지 않습니다.
답변2
좋아, 맨페이지를 읽고 알아냈습니다.
내 구성 파일을 수정하고 싶지 않았기 때문에 매뉴얼 페이지에서 "암호화"라는 용어를 검색했는데 이를 통해 -c
암호화 유형을 지정할 수 있는 옵션이 표시되었습니다. 종료 명령은 다음과 같습니다.
ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 -c 3des-cbc [email protected]
답변3
새로운 SFTP 서버(Ubuntu 22)를 설정하는 동안 이 문제가 발생했습니다. 모든 고객에게 키와 비밀번호를 업데이트하는 것은 선택 사항이 아니라는 점을 알려주세요(참호에 오신 것을 환영합니다).
KexAlgorithms +diffie-hellman-group1-sha1
파일 맨 아래에 추가했지만 /etc/ssh/sshd_config
-앞으로Match group sftp
구성의 일부 - 그렇지 않으면 다음 오류가 발생합니다.
Jun 22 09:43:22 sftp02 sshd[88559]: /etc/ssh/sshd_config line 140: Directive 'KexAlgorithms' is not allowed within a Match block
그 후에도 비밀번호를 업데이트해야 합니다.
Jun 22 09:44:45 sftp02 sshd[88613]: Unable to negotiate with 10.10.1.154 port 46973: no matching host key type found. Their offer: ssh-rsa,ssh-dss [preauth]
해결책: 이것을 sshd_config에 추가하십시오:
HostkeyAlgorithms +ssh-rsa,ssh-dss
나중에 SSH 서비스를 다시 시작하는 것을 잊지 마세요. 나는:
systemctl restart sshd.service
답변4
몇 년 후인 2022년에는 내 모든 SSHD 서버의 로그에 매일 이와 같은 수백 개의 메시지가 있습니다.
Jan 9 00:00:46 server sshd[335552]: Unable to negotiate with x.x.x.x port 53994: no matching key exchange method found. Their offer: diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 [preauth]
저는 단지 사람들에게 이러한 SHA1 비밀번호를 요구하는 클라이언트는 결코 합법적인 사용자가 아니라는 점을 말씀드리고 싶습니다.
https://www.computerworld.com/article/3173616/the-sha1-hash-function-is-now-completely-unsafe.html
이러한 SHA1 기반 비밀번호는 더 이상 정상적이고 안전한 최신 SSH 서버에 포함되지 않습니다. 해당 비밀번호를 추가하지 마세요. 잊어버리세요. 이러한 모든 로그 메시지는 이전 sha1 비밀번호를 사용하여 취약한 SSH 서버를 찾으려는 봇에서 온 것이라고 99% 확신합니다.
이러한 이전 암호가 필요한 합법적인 클라이언트가 있는 경우 서버를 다운그레이드하기보다는 이전의 안전하지 않고 지원되지 않는 SHA1 암호를 추가하여 클라이언트를 업그레이드해야 합니다.
물론, 이를 필요로 하는 매우 오래된 장치에 연결해야 하는 경우에는 이유가 있지만 사람들이 이 경고를 읽어주기를 바랍니다 :) 이유를 알고 있다면 SSH 클라이언트에 이러한 이전 비밀번호를 추가해도 괜찮습니다. 하지만 SSH 서버에 이를 추가하는 것은 2022년에는 의미가 없습니다 :)
이는 ssh failed to 협상 - 일치하는 키 교환 방법을 찾을 수 없음이라는 오류 메시지를 검색할 때 이 스레드를 발견한 SSH 서버 관리자에게 보내는 경고일 뿐입니다.