Considere este cenário: um administrador configurou um par de chaves pública / privada para usar quando rsync'ing arquivos entre servidores para evitar o prompt de senha. Essa configuração funciona muito bem.
Então, ao tentar usar o SSH / SCP, o sistema solicita uma senha.
Pergunta: por que esse é o caso se o rsync está funcionando corretamente?
Como você configurou o servidor para permitir sua chave? Colocando sua chave pública no .ssh / authorized_keys no servidor? Se for esse o caso, deve funcionar. Você está usando os mesmos nomes de usuários (remotos e locais) quando usa ssh / scp como quando usa o rsync?
Ah, e btw, esta pergunta deve ser feita em serverfault.com em vez disso, eu acho.
A outra coisa que acho útil é executar o servidor no modo de depuração em uma porta diferente. Às vezes, o servidor irá reclamar e o cliente não lhe dará uma boa idéia do motivo.
Lado do servidor: /usr/sbin/sshd -Dedd -p 2222
Lado do cliente: ssh -vv -p 2222 server
Muito obrigado, consegui resolver o problema usando o item de configuração
~ / .ssh / config PasswordAuthentication no
e configurando as permissões 700 para o diretório .ssh e 600 authorized_keys.
Esta postagem foi muito útil.
muito obrigado.
Veja a seção da página man do ssh em Autenticação. Algumas possibilidades:
Quando você criou as chaves, certificou-se de fazer o login como o mesmo usuário que fez com as chaves. Verifique também quando você importou as chaves para as chaves autorizadas corretamente.
No servidor, verifique o arquivo de log relevante para ver se há alguma mensagem lá. O motivo mais comum para um servidor se recusar a usar chaves de configuração corretamente é um erro de permissão (seu diretório inicial, ~/.ssh/ e ~/.ssh/authorized_keys deve ter permissões suficientemente seguras ou o servidor não confiará no conteúdo de ~/.ssh/authorized_keys como poderiam foi alterado por outro usuário). Se a autenticação baseada em chave foi recusada por esse motivo, ela será registrada (assim como várias outras razões). Isso geralmente é em /var/log/auth.log (pelo menos no Debian e sistemas similares com configuração SSHD padrão, o local logado pode variar).
A outra coisa para tentar obter mais informações é aumentar o detalhamento do cliente SSH. Se você estiver usando o OpenSSH na linha de comando, adicione -v para saída mais detalhada durante a conexão e -v novamente (ou apenas -vv conforme as opções podem ser agrupadas dessa forma) para solicitar que ele seja ainda mais conversável. / p>
Verifique os logs de autenticação (provavelmente um dos / var / log / secure ou /var/log/auth.log) no servidor - eles geralmente são um pouco mais detalhados que o cliente (mesmo se você adicionar -vvv para o comando ssh).
De longe, a coisa mais comum que vi foi que isso é permitido em arquivos SSH referenciados devido ao StrictModes estar ativado.
Eu recomendaria adicionar isso a ~ / .ssh / config para evitar que uma senha seja solicitada. Não fará com que as teclas funcionem magicamente, mas tornará o roteiro com falha um pouco mais rápido e claro.
PasswordAuthentication no
Você tem certeza de que não está pedindo uma senha para descriptografar a chave, em oposição a um nome de usuário e senha para acessar o servidor?
Discutimos isso em "Forçando o rsync para o modo não interativo" . Você pode ler sobre várias soluções possíveis, mas em resumo:
rsync -e 'ssh -o "NumberOfPasswordPrompts 0"' source user@target:/path
(Obrigado, guss!) Que não requer nenhuma alteração de configuração que possa alterar alguns outros usos do rsync ou do ssh no servidor.
Udi