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 grande 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 de referências à máquina remota. Repeti meu ssh-copy-id, ele solicitou uma senha e retornou normalmente. Mas eis que, quando 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:
.ssh
: 700 (drwx------)
644 (-rw-r--r--)
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.