최근에 워크스테이션인 Fedora 31을 Fedora 34로 업그레이드했습니다. 일반적으로 업그레이드 후에 발생하는 일이므로 일부 SSH 알고리즘은 더 이상 사용되지 않으며 .ssh/config에 추가 행을 추가해야 합니다. 안전을 위해 최선을 다하는 데 동의합니다.
이번에는 ssh-rsa 용어가 나를 혼란스럽게 했습니다. 예를 들어 Debian 10, Debian 8 및 Cisco 4k 라우터에 대해 openssh 클라이언트에 권한을 부여하는 이전 RSA 공개 키가 있습니다.
업그레이드 후에는 PubkeyAcceptedKeyTypes +ssh-rsa
대부분의 이전 호스트에 대해 .ssh/config에 추가해야 합니다. 이 경우에는 Debian 8 및 Cisco 4k 라우터가 됩니다. 이제 이전처럼 로그인할 수 있습니다. 그러나 Cisco 4k는 다음 메시지를 기록합니다.
Public-key Algorithm compliance violation detected.Kindly note that weaker Public-key Algorithm 'ssh-rsa' will be disabled
내 질문은 다음과 같습니다.
- Cisco 4k가 ssh-rsa보다 높은 PK를 허용하는 경우 기본 SSH 설정을 사용할 수 없는 이유는 무엇입니까?
- 키 유형 "ssh-rsa"와 허용되는 PK 알고리즘 사이에 연결이 있습니까? 예를 들어 공개 키 유형은 허용되는 알고리즘을 키 길이 등으로 제한합니까?
- 이 인증은 항상 ssh-rsa라고 부르지만, 구성에 수동으로 추가해야 하는 경우 기본적으로 어떤 실제 PK 인증이 사용됩니까? ssh-rsa 유형인가요 아니면 다른 유형인가요?
- 암호와 마찬가지로 서버와 클라이언트가 어떤 PK 알고리즘을 지원하는지 명확하게 이해할 수 있는 방법이 있습니까(Ssh 디버그 및 sshd 디버그를 시도했습니다)?
고쳐 쓰다:
Cisco 4k 라우터에 대한 새로운 정보: Cisco는 기본적으로 호스트 키 알고리즘을 지원합니다: rsa-sha2-512, rsa-sha2-256, ssh-rsa
이를 추가 PubkeyAcceptedKeyTypes +rsa-sha2-512
하고 로그인할 수 있지만 여전히 ssh-rsa에 대한 경고가 표시됩니다.
rsa-sha2-512를 일종의 ssh-rsa라고 생각하세요(둘 다 최근 openssh에서 덤프되었기 때문입니다). 다른 질문은 다음과 같습니다.
- 라우터 선언은 ssh-rsa를 rsa-sha2-512를 포함한 모든 종류의 ssh-rsa로 취급하는 것 같습니다.
- 라우터에서 활성화된 호스트 키 알고리즘이 다른 방식으로 제한되는 것처럼 보입니까?
답변1
배경으로...
이 주제에 대한 좋은 답변이 있습니다보안 스택 교환openssh에 대한 링크ssh-rsa 지원 중단에 대한 지침.
문제는 원래 ssh-rsa 알고리즘인 것 같습니다(RFC 4253에 설명되어 있음) 의지하다SHA-1이제 암호화의 경우 기본적으로 사라졌습니다.
2005년부터 SHA-1은 자금이 충분한 적에게 효과적이지 않은 것으로 간주되었으며 2010년 현재 많은 조직에서 이를 교체할 것을 권장했습니다. NIST는 2011년 공식적으로 SHA-1을 더 이상 사용하지 않으며 2013년에는 디지털 서명에 대한 사용을 금지했습니다. 2020년 현재 SHA-1에 대한 선택된 접두사 공격이 가능합니다.
그러나 키 자체가 아닌 SHA-1 서명 알고리즘이 사용됩니다.
이를 염두에 두고...
Cisco 4k가 ssh-rsa보다 높은 PK를 허용하는 경우 기본 SSH 설정을 사용할 수 없는 이유는 무엇입니까?
변경 사항은 openssh가 더 이상 기본적으로 ssh-rsa를 허용하지 않는다는 것입니다. 귀하가 수행한 변경 사항은 고객이 수락합니다 ssh-rsa
. 따라서 라우터는 여전히 이를 수락합니다(신음 소리가 나더라도). 그러나 알고리즘의 엄격한 계층 구조는 없으며 단지 일부 알고리즘이 다른 알고리즘보다 "더 우수"할 뿐입니다. 따라서 "더 높은" 알고리즘을 허용한다고 해서 라우터와 클라이언트가 동일한 "더 높은" 알고리즘을 공유한다는 의미는 아닙니다.
또 다른 가능한 이유는 클라이언트와 라우터가 모두 "더 나은" 알고리즘을 공유하지만 원래 RSA 키와 호환되지 않기 때문입니다. 예를 들어 SSH 인증서를 허용하지만 키는 있지만 인증서가 없습니다. 이 경우 기본 설정을 사용할 수 있지만 기존 키를 기본 설정으로 사용할 수는 없습니다.
키 유형 "ssh-rsa"와 허용되는 PK 알고리즘 사이에 연결이 있습니까?
내가 그 주제에 관해 찾은 바에 따르면 그렇습니다. 그들의 알고리즘은 단일로 제한될 수 있습니다.비밀번호그러나 일반적으로 키 길이에는 크게 신경 쓰지 않습니다. 키는 기본적으로 [일부] 매우 큰 숫자입니다. 크기는 중요하지 않지만 알고리즘은 이를 어떻게 처리할지 알아야 합니다.
암호와 마찬가지로 서버와 클라이언트가 어떤 PK 알고리즘을 지원하는지 명확하게 이해할 수 있는 방법이 있습니까(Ssh 디버그 및 sshd 디버그를 시도했습니다)?
다소 난해하지만 -vv
openssh 레벨 2 디버그()를 통해 달성할 수 있습니다. 당신은 볼 수 있습니다 debug2: KEX algorithms: ...
및 debug2: host key algorithms: ...
. 또한 어떤 알고리즘이 선택되었는지 확인해야 합니다. -vvv
더 자세히 알아보고 싶다면 세 번째 수준의 디버깅( )도 있습니다.