ssh key auth ainda pede senha (sem passphrase set)

Question

Tentando configurar o SSH para o meu CentOS VPS com chave de autenticação e nenhuma frase secreta para que eu possa me conectar automaticamente a partir do meu servidor local Debian 7. Eu tenho ido tão longe quanto copiar e colar de dois guias diferentes na rede ( aqui e aqui ) e ainda me pedem uma senha. (não passa frase)

Minha seção de Autenticação sshd_config remota, cortada pouco antes da seção do kerberos:

    # Authentication:

#LoginGraceTime 2m
#PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile ~/.ssh/authorized_keys
#AuthorizedKeysCommand none
#AuthorizedKeysCommandRunAs nobody

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no
PasswordAuthentication yes

# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes
ChallengeResponseAuthentication no

Remoto / var / log / secure não tem erros:

Jun 13 07:02:14 *remote host* sshd[4206]: Accepted password for admin from *my-ip* port 48919 ssh2
Jun 13 07:02:15 *remote host* sshd[4206]: pam_unix(sshd:session): session opened for user admin by (uid=0)
Jun 13 07:02:20 *remote host* sshd[4220]: Received disconnect from *my-ip*: 11: disconnected by user
Jun 13 07:02:20 *remote host* sshd[4206]: pam_unix(sshd:session): session closed for user admin

e a conexão detalhada no cliente não tem erros, apenas envia uma chave privada e pula para a senha:

debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: *local/user/home*/.ssh/id_rsa ((nil))
debug2: key: *local/user/home*/.ssh/id_dsa ((nil))
debug2: key: *local/user/home*/.ssh/id_ecdsa ((nil))
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug2: we did not send a packet, disable method
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_1000' not found

debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_1000' not found

debug1: Unspecified GSS failure.  Minor code may provide more information


debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_1000' not found

debug2: we did not send a packet, disable method
debug1: Next authentication method: publickey
debug1: Trying private key: *local/user/home*/.ssh/id_rsa
debug1: read PEM private key done: type RSA
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Trying private key: *local/user/home*/.ssh/id_dsa
debug1: Trying private key: *local/user/home*/.ssh/id_ecdsa
debug2: we did not send a packet, disable method
debug1: Next authentication method: password
admin@*remote server*'s password:

Depois de ler as sugestões e seguir o segundo guia, tentei configurar 755 e 600 em todos os diretórios locais e remotos ~ / .ssh /, e ainda não funciona. Como eu disse, copiei e colei este comando:

cat id_rsa.pub >> authorized_keys

para copiar a chave no arquivo authorized_keys; Copiei e colei todos os comandos de ambos os guias para garantir que nada esteja errado na minha configuração.

Alguma idéia?

    

Answer 1

Você tem um valor incorreto para o parâmetro AuthorizedKeysFile. Do homem sshd_config:

AuthorizedKeysFile pode conter tokens da forma% T que são substituídos durante a configuração da conexão. Os seguintes tokens são definidos: %% é substituído por um literal '%',% h é substituído pelo diretório inicial do usuário que está sendo autenticado e% u é substituído pelo nome de usuário desse usuário. Após a expansão, AuthorizedKeysFile é considerado um caminho absoluto ou relativo ao diretório inicial do usuário. O padrão é ".ssh / authorized_keys".

    

Answer 2

Obrigado a todos pela ajuda. Eu acho que todos vocês irão odiar ouvir que isso só se consertou magicamente hoje. É isso mesmo: eu acordei, instalei algum outro software no VPS, (algumas coisas relacionadas ao irssi) reiniciei, (apesar de ter tentado isso ontem à noite, junto com recarregar o serviço sshd) entrei no SSH para tentar algumas sugestões e me deu uma nova mensagem WARNING: UNPROTECTED PRIVATE KEY FILE! . Desde que eu tenho feito chmod -R 755 .ssh/ ultimamente em meus arquivos SSH locais porque 600 não vai deixar emitar a chave por algum motivo estranho, eu usei chmod -R 700 .ssh/ após este aviso e agora tudo funciona bem. Eu realmente não sei o que aconteceu. Mais uma vez, obrigado a todos pelo seu tempo.

    

Answer 3

Outra solução para o SELinux, que impede o sshd de ler o $ HOME / .ssh, é usar o restorecon, veja meu respondedor aqui link .

    

Answer 4

Se o SELinux estiver no sistema, edite /etc/selinux/config e altere

SELINUX=enforcing

para

SELINUX=permissive

    

Answer 5

Outra coisa que pode causar we did not send a packet, disable method é se o servidor está configurado para rejeitar seu login. Por exemplo, se você tentar efetuar login como root quando a configuração contiver PermitRootLogin no .