* nix 서버를 다루기 시작했을 때, openssh 서버는 rsa 호스트 키뿐만 아니라 dsa와 함께 제공되었으며, openssh 클라이언트는 rsa 키를 선호합니다. 오늘날 openssh 서버에는 dsa, rsa 및 ecdsa 호스트 키가 있으며 openssh 클라이언트는 ecdsa 호스트 키를 선호합니다.
dsa 호스트 키를 제공하도록 openssh를 구성하려면 어느 정도까지 필요합니까?
비 openssh 클라이언트 구현과 관련하여 대부분 궁금합니다.
답변:
나는 적어도 RSA를 지원하지 않는 널리 사용되는 것을 생각할 수 없으며 실제로 DSA 만 지원하는 Windows (예 :)에서 터미널 에뮬레이터를 사용하는 경우 사용을 중지하고 퍼티를 다운로드하거나 업데이트해야합니다.
옵션은 호환성을 제공하기위한 것입니다. 그러나 그것은 또한 당신의 보안 표면에 추가합니다; 공격자는 클라이언트가 DSA에 대한 지원 만 선언하도록 설득하여 암호화를 약화시킬 수 있습니다. 이 시나리오는 상당히 많이 사용됩니다. 문제가 있으면 DSA를 비활성화해야합니다.
심각하게 손상 될 수있는 유일한 시나리오는 사용자 중 하나가 신뢰할 수 없거나 손상된 컴퓨터에서 DSA 키 쌍을 사용하여 항상 DSA를 협상하고 DSA 서명을 만들기 위해 중복 된 임시 값을 생성하는 경우입니다. 결과적으로 사용자의 키가 손상 될 수는 있지만 이것이 공격자에게 가장 적은 저항 경로 인 것처럼 보이지는 않습니다. 국제 스파이가 시스템을 사용하지 않으면 걱정할 필요가 없습니다. 자매 사이트 중 하나에서이 질문을 참조하십시오 : /security//q/29262/12223 .
DSA를 비활성화하는 직접적인 방법은 없습니다. 데비안 버그 528046은이를 제안하고 (PubKeyTypes 옵션을위한) 패치를 제공하고 지원을 받았지만, 업스트림에 대한 증거없이 2009 년부터 조치를 취하지 않았습니다.
당신의 대답은 아마 여기에 있습니다 :
/security/5096/rsa-vs-dsa-for-ssh-authentication-keys
대부분의 권장 사항은 다양한 이유로 RSA 키에 대한 것이므로 DSA 키는 이전 버전과의 호환성을 위해 주로 있습니다. DSA는 RSA가 아직 특허를 받았으며 DSA가 더 개방적이었던 시점부터 SSH2가 나왔을 때 도입되었습니다. 그 이후로 바뀌었다.
이 모든 것 때문에 DSA 키는 거의 쓸모가 없습니다. 그들은 작동 할 것이고, ssh-keygen은 당신이 그것을 요구한다면 그것들을 생산할 것입니다. 그러나 누군가가 그것을 요구해야합니다. 내가 아는 한, DSA 전용은 없었습니다. DSA 키는 금지되어 있습니다.