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

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 pasta .ssh: 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 $HOME diretório. No entanto, basta executar chmod g-w ~/ não corrigiu o problema. Além de chmod g-w ~/ Eu também precisei modificar as permissões de others no $HOME diretório executando chmod o-wx ~/

Juntos:

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

Observe que não tenho certeza se o-x era necessário, eu simplesmente o corria como precaução.

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

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 [email protected] 

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:

~/.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à

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 alternativa necessária.

No meu caso no servidor remoto, o seguinte arquivo:

/etc/ssh/sshd_config

tinha a seguinte propriedade definida como no:

PubkeyAuthentication no

comentando com um hash:

#PubkeyAuthentication no

fez metade do truque, o resto foi reiniciar o serviço ssh:

/etc/init.d/sshd restart

Fonte: Após o ssh-copy-id, ainda é necessário fornecer a senha

A razão pela qual a chave pública não estava sobrevivendo após a reinicialização foi que o diretório inicial do meu servidor estava criptografado. (você faz isso enquanto instala o servidor)

Eu postaria isso como um comentário, mas provavelmente seria muito longo. Eu só queria acrescentar que ssh-copy-id Tenta enviar a chave pública do local /.ssh Dentro da pasta $HOME.

Se você estiver tentando ssh como root com uma chave pública (salve os comentários relacionados à segurança), ssh-copy-id Poderá estar tentando fazer login com a chave pública errada se o seu $HOME A variável é definida como algo diferente de /root (como sendo definido como o diretório inicial do usuário normal), portanto, o usuário root receberá uma solicitação 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 [email protected] "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

Outro possível problema é que o servidor não suporta o seu algoritmo de chave. No meu caso, encontrei as seguintes mensagens nos meus sshd logs (/var/log/auth.log No 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 configuração sshd (que pode exigir uma atualização para uma versão mais recente sshd) ou precisa mudar sua chave para um algoritmo suportado pelo sshd ao qual você está tentando se conectar.