Estou procurando dicas sobre como solucionar um problema com a conexão a um novo servidor via SSH. Eu estou tentando se conectar usando a autenticação de chave privada, onde o SSH usa minha chave privada local para autenticar, sem solicitar uma senha, mas com problemas com isso.
Quando executo ssh root@newserver , a conexão é bem-sucedida imediatamente, sem solicitar uma senha. Por outro lado, quando executo ssh user@newserver , a tentativa de autenticação de chave particular falha e ele me solicita uma senha. Estou perplexo sobre por que o último falha. O que devo tentar depurar isso?
Coisas que eu já tentei:
Eu verifiquei cuidadosamente /root/.ssh/authorized_keys e /home/user/.ssh/authorized_keys . Ambos são idênticos e ambos contêm minha chave pública.
Eu verifiquei cuidadosamente as permissões nos diretórios /root/.ssh e /home/user/.ssh em newserver . Tudo parece bem, e em qualquer caso, as permissões são as mesmas para ambos.
Eu tentei fazer login de dois clientes diferentes e ver o mesmo comportamento em ambos, então não acho que seja específico do cliente. Eu posso logar em outros servidores com sucesso de ambos os clientes.
Eu tentei executar /usr/sbin/sshd -d -p 2323 no novo servidor e, em seguida, conectei-me usando ssh -p 2323 root@newserver e ssh -p 2323 user@newserver . Aqui está a parte de torcer o cérebro: quando eu inicio sshd manualmente a partir da linha de comando, consigo logar (ambos em root e user ) via autenticação de chave privada, mas quando tento usar o padrão do sistema sshd , só posso fazer login no root , mas não no user via autenticação de chave privada.
Eu corri ssh -v . Não vejo mensagens esclarecedoras: com ssh -v root@newserver , obtenho
debug1: Offering DSA public key: /home/user/.ssh/id_dsa
debug1: Server accepts key: pkalg ssh-dss blen 433
Com ssh -v user@newserver , obtenho
debug1: Offering DSA public key: /home/daw/.ssh/id_dsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
Adicionar mais -v não ajuda em nada; com ssh -vvvvv bingen.cs.berkeley.edu , obtenho
debug1: Offering DSA public key: /home/daw/.ssh/id_dsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
Portanto, não há indicação de por que a tentativa de efetuar login via autenticação de chave privada falhou.
Este é o Fedora 21, openssh-6.6.1p1-11.1.fc21.x86_64.
Acho que a nlu apontou na direção certa.
A melhor maneira de rastrear problemas no ssh é parar o sshd no lado do servidor e iniciá-lo com $(which sshd) -d .
Isso fornecerá mensagens de erro mais significativas em quase todos os casos.
Atualização: desculpe - você já fez isso.
Parece haver uma diferença entre o sshd no cli e o serviço: SELINUX.
No CLI, não é tão restritivo. Você tem o selinux ativado? Se assim for - verifique os se-logs / configurações!
Você também deve verificar a propriedade e as permissões de /home/user/.ssh/authorized_keys.
Acontece que foi um problema de permissões do SELinux com arquivos em ~/.ssh/ . Copiei os arquivos de um backup armazenado em uma unidade externa, onde acho que eles receberam rótulos diferentes e eles mantiveram seus rótulos incorretos.
Eu deveria saber. Ao experimentar falhas intrigantes que podem ser problemas de permissão, verifique sempre o SELinux.
A correção: restorecon -r /home/user/.ssh .
Tags ssh fedora troubleshooting