비밀번호가없는 인증에 SSH DSA 키가 더 이상 작동하지 않습니다

Fedora 23으로 업그레이드 한 후 비밀번호없는 공개 키 기반 인증이 SSH에서 더 이상 작동하지 않습니다. 일부 호스트에 SSH를 시도하면 원격 호스트에서 비밀번호를 입력하라는 메시지가 표시됩니다. SSH 개인 키를 사용할 수 없습니다. Fedora 22에서는 모든 것이 잘 작동했습니다.

내 공개 키는 DSA 키 ( ~/.ssh/id_dsa.pub)입니다. OpenSSH 7.1 ( openssh-7.1p1-5.fc23.x86_64)을 사용하고 있습니다.

암호가없는 인증을 다시 올바르게 작동 시키려면 어떻게해야합니까?

— DW
소스

의 속는 superuser.com/questions/962918/... 및 (크로스) unix.stackexchange.com/questions/247612/...

— dave_thompson_085

감사합니다, @ dave_thompson_085. 이것은 superuser.com/q/962918/93541 의 속임수가 아닙니다 . 그 질문은 사용법을 묻는 것 ssh -Q입니다. 이것은 SSH 장애를 해결하는 방법을 묻습니다. superuser.com/q/962918/93541 에서 일부 자료를 찾았 으며이 솔루션을 식별하는 데 도움이되는 다른 곳에서이 답변을 사용하는 방법 ssh -Q과이 질문에 대한 답변이 없습니다 (예 : 해결 방법을 설명하지 않음) 이 문제), 그래서 내 견해로는 dup이 아닙니다. 유닉스와 리눅스의 것은 매우 유사합니다. 나는 그것을 더 일찍 보길 바란다. 링크에 다시 한번 감사드립니다!

— DW

Ack, 당신 말이 맞아 나는 두 경우 모두 "OpenSSH 7.0 no DSA"로 북마크를했고 이전의 경우에는 충분히 가깝지 않았다. 죄송합니다.

— dave_thompson_085

답변:

OpenSSH 7.0으로 업그레이드 한 결과입니다. OpenSSH 7.0 의 릴리스 정보에 따르면 "ssh-dss 호스트 및 사용자 키 지원은 런타임시 기본적으로 비활성화되어 있습니다"라고 말합니다.

해결책은 ~/.ssh/config모든 클라이언트 시스템 (SSH 클라이언트를 실행하는 모든 시스템)에 다음 행을 추가하는 것 입니다.

PubkeyAcceptedKeyTypes=+ssh-dss

서버가 OpenSSH를 7.0 이상을 사용하는 경우, 당신은 것 또한 이 라인을 추가 할 필요가 /etc/ssh/sshd_config각 서버 시스템에.

또는 완전히 새로운 SSH 키를 생성하여 로그인하려는 모든 서버의 authorized_keys 파일에 추가 할 수 있습니다. 호환성 문제를 피하기 위해 RSA를 사용하는 것이 좋습니다 . gnome-keyring-daemon은 ECDSA 유형의 SSH 키를 자동으로 선택하지 않으므로 ECDSA를 권장 하지 않습니다 .

광고 문안 : OpenSSH 직원이 DSA 키를 비활성화 한 이유는 무엇입니까? 모르겠어요 내가 알 수있는 한 DSA 키 (ssh-dss)의 보안에는 아무런 문제가 없습니다. 그만큼OpenSSH의 웹 페이지 는 ssh-DSS가 약하지만, 지금까지 내가 알고 있어요로서, 1024 비트는 ssh-DSS는 1024 비트 RSA보다 약한 없으며, 1024 비트 RSA 키를 사용할 수없는 것을 주장한다.

— DW
소스

키 유형 선택은 한동안 보안 에 대해 설명됩니다 . DSA 키의 보안은 처음부터 의심 스러우며 좋은 랜덤 생성기가 없으면 확실하지 않습니다. 그리고 사용할 수있는 다른 키 유형이 있으므로 의심스러운 키 유형을 유지할 이유가 없습니다.

— Jakuje

@Jakuje, 예, 키 유형 선택은 여기 와 여기 에 정보 보안에 대해 논의 됩니다 . 편집자 의견을 작성하기 전에이 모든 내용을 읽었으며, DSA 키가 비활성화 된 이유는 여전히 당황 스럽습니다. 같은 길이의 RSA 키보다 약한 키는 비활성화되지 않았습니다. DSA가 "의문의 여지가 있음"을 나타내는 스레드에는 아무 것도 없습니다. Thomas Pornin이 말했듯이 "충분히 큰 키를 가정 할 때 다른 유형보다 한 유형을 선호하는 보안 관련 이유는 없습니다". (계속)

— DW

자세한 내용은 여기 를 참조 하십시오 .

— DW

내 두 센트

.ssh/config이것을 허용하기 위해 파일을 편집 하는 것은 그리 좋은 생각 이 아닌 것 같습니다.

최근 도구를 사용하여 새 키를 작성하십시오.

그런 다음 새 공개 키를 클립 보드에 복사하십시오.
이전 키를 사용하여 마지막으로 한 번 기록 하십시오 .
```
ssh -i .ssh/id_dsa.pub -o PubkeyAcceptedKeyTypes=+ssh-dss user@host
```
그런 다음 업그레이드 @host의 authorized_keys새로운 추가하여 파일을, pubkey 및 로그 아웃
```
cat >>.ssh/authorized_keys
```
paste, Ctrl+D
기본 구문을 사용하여 새 키로 로그인하십시오.
```
ssh user@host
```
1. 그런 다음 업그레이드 @host의 authorized_keys로, 파일을 제거 하면 기존 pubkey을 (내가 사용하는 sed -e 1d -i .ssh/authorized_keys나의 오래된 pubkey 라인에있을 때 1이 파일의).
2. 가능하다면 ssh 서버를 업그레이드하는 것이 좋습니다.
3. 로그 아웃
이전 키가 더 이상 작동하지 않는지 테스트하십시오.
```
ssh -i .ssh/id_dsa.pub -o PubkeyAcceptedKeyTypes=+ssh-dss user@host
...
Permission denied...
```
이 작동하지 않아도 ;-)
모든 것이 정상인지 다시 확인할 수도 있습니다.
```
ssh user@host uptime
```

— F. 하우리
소스

왜 편집 ~/.ssh/config이 그렇게 좋은 아이디어가 아니라고 생각하는지는 분명 하지 않습니다.

— DW

이것은 더 이상 사용되지 않으며 ssh author 는 사용 하지 말 것을 권장합니다. 참조 openssh.com/legacy.html

— F. 하우리에게

아 나 이해 했어. 편집 ~/.ssh/config자체가 아니라 DSA를 허용한다는 생각에 관심이 있는 것 같습니다. 설명해 주셔서 감사합니다. 말이 되네요 (저는 이미 저의 대답 과 의견에서 그 권고가 당혹 스러울 것이라고 생각하는 이유를 다루었다고 생각합니다 . 그러나 여기서 논의하지는 않겠습니다.)

— DW

편집을 .config사용하면 ssh오랫동안 실행할 수 있으며 약한 알고리즘 을 사용하는 것도 모호합니다 . -o Pubkey...at 명령 줄 을 사용 하면 업그레이드 할 것이 있다는 것을 용서할 수 없습니다 .

— F. Hauri