O ssh solicita a senha, apesar do ssh-copy-id

Estou usando a autenticação de chave pública em um servidor remoto há algum tempo para uso remoto do shell, bem como para montagens sshfs. Depois de forçar uma parte do meu diretório sshfs, notei que o ssh começou a solicitar uma senha. Tentei limpar o .ssh / protected_keys remoto de qualquer menção à máquina local e limpei a máquina local das referências à máquina remota. Repeti então meu ssh-copy-id, ele solicitou uma senha e retornei normalmente. Mas eis que, quando eu ssh no servidor remoto, ainda é solicitada uma senha. Estou um pouco confuso quanto ao que poderia ser o problema, alguma sugestão?

O sshd fica estranho com as permissões em $ HOME, $ HOME / .ssh (ambos os diretórios) e em $ HOME / .ssh / allowed_keys.

Uma das minhas caixas Linux terminou com permissões drwxrwxrwx no meu diretório $ HOME. Uma caixa do Arch linux absolutamente não efetuaria login usando chaves públicas até eu remover a permissão 'w' para o grupo, outra no meu diretório $ HOME.

Tente fazer com que $ HOME e $ HOME / .ssh / tenham permissões mais restritivas para grupos e outros. Veja se isso não deixa o sshd fazer suas coisas.

As seguintes permissões são necessárias:

• A .sshpasta:700 (drwx------)
• A chave pública: 644 (-rw-r--r--)
• A chave privada: 600 (-rw-------)

Recentemente, também tive esse problema.

Foi corrigido modificando as permissões do $HOMEdiretório. No entanto, a simples execução chmod g-w ~/não corrigiu o problema. Além de chmod g-w ~/eu também precisar modificar as permissões othersno $HOMEdiretório executandochmod o-wx ~/

Juntos:

chmod g-w ~/
chmod o-wx ~/

Observe que não tenho certeza se o-xfoi necessário; simplesmente executei como precaução.

Alterar as permissões da pasta ~ / .ssh resolveu meu problema de acordo com esta postagem no Super User SE .

O problema ocorre também em logons paralelos, ou seja, se você tentar montar o sshfs durante uma sessão ssh aberta? Caso contrário, acho que você tem seu diretório pessoal criptografado? Nesse caso$HOME/.ssh/authorized_keys , só se tornaria utilizável na máquina remota após o seu primeiro login (usando sua senha).

Confira https://help.ubuntu.com/community/SSH/OpenSSH/Keys#Trou Troubleshooting para obter uma explicação e a solução necessária.

Eu postaria isso como um comentário, mas provavelmente seria muito longo. Eu só queria acrescentar que ssh-copy-idtenta enviar a chave pública do /.sshlocal dentro do seu$HOME pasta.

Se você está tentando fazer ssho root com uma chave pública (salve os comentários relacionados à segurança), ssh-copy-idpode estar tentando fazer login com a chave pública errada se a sua $HOMEvariável estiver definida como algo diferente de /root(como estar definido no diretório inicial do usuário normal) ), portanto, o usuário root seria solicitado porque a chave pública do root não está instalada no sistema remoto.

Você pode usar a seguinte linha única para especificar a chave pública exata:

pub="$(cat /root/.ssh/id_rsa.pub)"; ssh user@remotehost "echo $pub >> .ssh/authorized_keys; chmod 700 .ssh; chmod 600 .ssh/authorized_keys"

Eu encontrei esse cenário na natureza algumas vezes (inclusive esta manhã) e imaginei que tentaria colocar meus 2 centavos, apenas no caso de alguém se encontrar na mesma situação.

Como outros colaboradores mencionados, este é provavelmente um problema de permissão.

A melhor maneira de diagnosticar isso é reiniciar o daemon SSH no servidor remoto com a opção de depuração ativada - geralmente a opção "-d". A mensagem do daemon OpenSSH é muito explícita. Por exemplo, você verá mensagens como:

Authentication refused: bad ownership or modes for directory /some/path

O motivo pelo qual a chave pública não estava sobrevivendo após a reinicialização foi o fato de o diretório inicial do meu servidor estar criptografado. (você faz isso enquanto instala o servidor)

Outro possível problema é que o servidor não suporta o seu algoritmo de chave. No meu caso, encontrei as seguintes mensagens nos meus sshdlogs ( /var/log/auth.logno meu caso):

userauth_pubkey: unsupported public key algorithm: ssh-ed25519 [preauth]

Se for esse o caso, você precisa habilitar o suporte para esse algoritmo em sua sshdconfiguração (o que pode exigir uma atualização para uma sshdversão mais recente ) ou precisa alternar sua chave para um algoritmo suportado pelo qual sshdvocê está tentando se conectar. .

Como essa pergunta aparece entre os primeiros resultados da pesquisa ao pesquisar esse comportamento, também adicionarei minha solução:

No meu caso, não havia nada relacionado às permissões. Por qualquer motivo (não me incomodei em descobrir por qual motivo, como encontrei uma solução rápida) ao executar o comando ssh, o programa não procurou o arquivo de identidade correto. Uma solução foi adicionar manualmente no servidor remoto uma chave SSH que o programa SSH tentou usar. Você pode observar o que o programa SSH faz ao executar o comando adicionando -v ao comando:

ssh -v username@your-host-ip-or-domain 

Depois, basta pegar na máquina local qualquer chave pública para a qual o programa SSH tente encontrar um arquivo de identidade / chave privada, em um Mac, por exemplo:

cat ~/.ssh/id_rsa.pub

... e adicione-o ao arquivo allowed_keys do controle remoto em:

~/.ssh/authorized_keys

Outra, no meu caso, a melhor solução foi adicionar um host personalizado no meu arquivo de configuração ssh local. No meu Mac é:

/Users/my-user-name/.ssh/config

Aqui você pode adicionar, por exemplo, algo como isto:

Host mynewserver
        HostName some.IP.number.or.domain
        Port 20000 #if custom port is used and not the default 22
        User the_root
        PreferredAuthentications publickey
        IdentityFile ~/.ssh/id_rsa_for_my_new_server

Então você só precisa executar:

ssh mynewserver

... e Voilà