Chaves SSH DSA não funcionam mais para autenticação sem senha

Após a atualização para o Fedora 23, a autenticação sem senha (baseada em chave pública) não funciona mais no SSH: ao tentar fazer o SSH para algum host, solicita minha senha no host remoto. Não consigo usar minha chave privada SSH. Tudo funcionou bem com o Fedora 22.

Minha chave pública é uma chave DSA ( ~/.ssh/id_dsa.pub). Estou usando o OpenSSH 7.1 ( openssh-7.1p1-5.fc23.x86_64).

Como faço para que a autenticação sem senha funcione corretamente novamente?

— DW
fonte

Dupe de superuser.com/questions/962918/… e (cross) unix.stackexchange.com/questions/247612/…

— dave_thompson_085

Obrigado, @ dave_thompson_085. Este não é um truque de superuser.com/q/962918/93541 . Essa pergunta está perguntando como usar ssh -Q. Isso está perguntando como solucionar uma falha do SSH. Eu encontrei parte do material em superuser.com/q/962918/93541 e em outros lugares útil na identificação dessa solução, mas a resposta lá descreve como usar ssh -Qe não responde a essa pergunta (por exemplo, não explica como corrigir esse problema), então, na minha opinião, não é um dup. O do Unix e Linux é muito semelhante; Eu gostaria de ter visto isso antes. Mais uma vez obrigado pelos links!

— DW

Ack, você está certo. Eu tinha os dois marcados como "OpenSSH 7.0 no DSA", que no caso anterior não está próximo o suficiente. Desculpe.

— David_thompson_085

Respostas:

Isso é resultado da atualização para o OpenSSH 7.0. Como dizem as notas de versão do OpenSSH 7.0 , "O suporte para chaves de host e usuário ssh-dss está desativado por padrão no tempo de execução".

A solução é adicionar a seguinte linha ~/.ssh/configem todas as máquinas clientes (todas as máquinas em que você executa o cliente SSH):

PubkeyAcceptedKeyTypes=+ssh-dss

Se o servidor estiver usando o OpenSSH 7.0 ou mais recente, você também precisará adicionar esta linha /etc/ssh/sshd_configem cada máquina servidor.

Como alternativa, você pode gerar uma chave SSH totalmente nova e adicioná-la ao seu arquivo allowed_keys em todos os servidores nos quais deseja efetuar login. Eu recomendo que você use o RSA , para evitar problemas de compatibilidade. Eu não recomendo o ECDSA, pois aparentemente o gnome-keyring-daemon não pega automaticamente as chaves SSH do tipo ECDSA.

Comentário editorial: Por que o pessoal do OpenSSH desativou as chaves DSA? Eu não sei. Até onde eu sei, não há nada de errado com a segurança das chaves DSA (ssh-dss). A página da Web OpenSSH afirma que o ssh-dss é fraco, mas até onde eu sei, o ssh-dss de 1024 bits não é mais fraco que o RSA de 1024 bits e as chaves RSA de 1024 bits não estão desabilitadas.

— DW
fonte

A seleção do tipo de chave é discutida em Segurança por algum tempo. A segurança das chaves DSA é questionável desde o início e menos segura se você não tiver um bom gerador aleatório (o que você não pode ter certeza). E como agora existem outros tipos de chaves possíveis de usar, não há motivo para reter os questionáveis.

— Jakuje 23/12/15

@Jakuje, sim, a seleção do tipo de chave é discutida sobre Segurança da Informação aqui e aqui . Eu li tudo isso antes de escrever minha observação editorial e fico perplexo por que as chaves DSA foram desativadas: elas não são mais fracas que as chaves RSA do mesmo comprimento, que não foram desativadas. Não há nada em nenhum desses segmentos que indique que o DSA seja "questionável" e, como diz Thomas Pornin, "não há motivo relacionado à segurança para preferir um tipo a outro, assumindo chaves grandes o suficiente". (cont.)

— DW

Veja aqui uma discussão mais detalhada.

— DW

Meus dois centavos

Como editar o .ssh/configarquivo para permitir que isso pareça uma idéia não tão boa , sugiro

Crie uma nova chave, usando a ferramenta recente.

Em seguida, copie a nova chave pública (para o clipbord)
Registre uma última vez usando a chave antiga:
```
ssh -i .ssh/id_dsa.pub -o PubkeyAcceptedKeyTypes=+ssh-dss user@host
```
Em seguida, atualize @hosto authorized_keysarquivo, adicionando seu novo pubkey e logout
```
cat >>.ssh/authorized_keys
```
paste, então Ctrl+D
Faça logon com nova chave usando a sintaxe padrão:
```
ssh user@host
```
1. Em seguida, atualize @hosto authorized_keysarquivo removendo seu antigo pubkey (eu uso sed -e 1d -i .ssh/authorized_keysquando meu antigo pubkey está na linha 1desse arquivo).
2. Sugiro atualizar seu servidor ssh, se puder.
3. sair

Teste se a chave antiga não funciona mais.

ssh -i .ssh/id_dsa.pub -o PubkeyAcceptedKeyTypes=+ssh-dss user@host
...
Permission denied...

Isso tem que não funcionar ;-)

Você pode até verificar novamente se está tudo bem:
```
ssh user@host uptime
```

— F. Hauri
fonte

Não é óbvio para mim por que você acha que editar ~/.ssh/confignão é uma boa idéia.

— DW

Porque isso está obsoleto e o autor ssh recomenda não usar. Veja openssh.com/legacy.html

— F. Hauri

Ah, Eu entendi. Parece que sua preocupação não é com a ideia de editar em ~/.ssh/configsi, mas com a ideia de permitir o DSA. Obrigado por explicar. Isso faz sentido. (Eu acho que eu já abordados em minha resposta e meus comentários por isso que acho que a recomendação de ser intrigante, mas não vou tentar discutir isso aqui.)

— DW

A edição .configpermite que você execute sshpor um longo período de tempo e até mesmo perca o uso do algoritmo fraco . Ao usar -o Pubkey...na linha de comando, você não perdoará que há algo a ser atualizado .

— F. Hauri 21/10