SSH usando chaves públicas não está funcionando

Question

Eu tenho um sistema que está tentando ssh para o meu usando ssh [email protected]. Eles me enviaram a chave RSA pública e eu a instalei no meu arquivo de chaves autorizadas .ssh /. Quando eles tentam se conectar, eles vêem "Permissão negada".

No log seguro do meu servidor, vejo que uma chave correspondente foi encontrada, mas ainda nega o acesso.

Alguma idéia?

Atualização:

Na minha pressa de postar isso no final do dia de ontem, deixei de fora alguns detalhes importantes.

Primeiro, e mais importante, várias entidades estão usando esse mesmo usuário do meu lado para fazer login. Este é um repositório de arquivos automatizado e, quando alguém deseja se conectar, ele nos envia a chave pública para seu usuário e servidor, e eu o adiciono ao arquivo authorized_keys para o usuário do meu lado. É um usuário não root. Temos outras partes externas que podem efetuar login com êxito usando o ssh. É apenas este novo usuário no lado remoto não está funcionando.

O log mostra:

Sep  1 15:24:56 SavFTPDNS sshd[31674]: Connection from X.X.X.X port 12857
Sep  1 15:24:56 SavFTPDNS sshd[31674]: debug1: Client protocol version 2.0; client software version OpenSSH_4.0
Sep  1 15:24:56 SavFTPDNS sshd[31674]: debug1: match: OpenSSH_4.0 pat OpenSSH*
Sep  1 15:24:56 SavFTPDNS sshd[31674]: debug1: Enabling compatibility mode for protocol 2.0
Sep  1 15:24:56 SavFTPDNS sshd[31674]: debug1: Local version string SSH-2.0-OpenSSH_4.2
Sep  1 15:24:56 SavFTPDNS sshd[31674]: debug1: PAM: initializing for "userA"
Sep  1 15:24:56 SavFTPDNS sshd[31674]: debug1: PAM: setting PAM_RHOST to "X.X.X.X"
Sep  1 15:24:56 SavFTPDNS sshd[31674]: debug1: PAM: setting PAM_TTY to "ssh"
Sep  1 15:24:56 SavFTPDNS sshd[31674]: debug1: temporarily_use_uid: 504/100 (e=0/0)
Sep  1 15:24:56 SavFTPDNS sshd[31674]: debug1: trying public key file /home/userA/.ssh/authorized_keys
Sep  1 15:24:56 SavFTPDNS sshd[31674]: debug1: matching key found: file /home/userA/.ssh/authorized_keys, line 18
Sep  1 15:24:56 SavFTPDNS sshd[31674]: Found matching RSA key: d2:4f:5e:cb:cf:78:a4:67:19:99:b8:7b:2a:71:9e:61
Sep  1 15:24:56 SavFTPDNS sshd[31674]: debug1: restore_uid: 0/0
Sep  1 15:24:56 SavFTPDNS sshd[31674]: debug1: temporarily_use_uid: 504/100 (e=0/0)
Sep  1 15:24:56 SavFTPDNS sshd[31674]: debug1: trying public key file /home/userA/.ssh/authorized_keys
Sep  1 15:24:56 SavFTPDNS sshd[31674]: debug1: restore_uid: 0/0
Sep  1 15:24:56 SavFTPDNS sshd[31674]: debug1: temporarily_use_uid: 504/100 (e=0/0)
Sep  1 15:24:56 SavFTPDNS sshd[31674]: debug1: trying public key file /home/userA/.ssh/authorized_keys2
Sep  1 15:24:56 SavFTPDNS sshd[31674]: debug1: restore_uid: 0/0
Sep  1 15:24:56 SavFTPDNS sshd[31674]: debug1: do_cleanup
Sep  1 15:24:56 SavFTPDNS sshd[31674]: debug1: PAM: cleanup

    

Answer 1

Se você pudesse copiar / colar as linhas do log que viu, isso ajudaria. Alguns palpites no tempo médio:

Certifique-se de que suas permissões estejam corretas.

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Se você está tentando autenticar como root, você pode precisar do seguinte em seu sshd_config:

PermitRootLogin without-password

Eu descobri isso durante a configuração de um sistema de backup Barracuda para fazer backup de um host do FreeBSD. (No FreeBSD, está em / etc / ssh / sshd_config.)

    

Answer 2

Certifique-se de que não há novas linhas na chave do seu arquivo authorized_keys - eu tinha algo assim antes de me morder. Depois de apertar a tecla backspace até o último caractere ASCII, de repente começou a funcionar.

Além disso, o sshd é muito específico sobre as permissões no diretório .ssh e seus arquivos.

aqui está um (de muitos) links com as permissões listadas.

link

    

Answer 3

Uma cópia do seu arquivo sshd_config seria interessante. Em particular, o sshd requer que a diretiva pubkeyauthentication seja definida como yes:

PubkeyAuthentication yes

Você também pode querer especificar o caminho para os arquivos authorized_keys

AuthorizedKeysFile     %h/.ssh/authorized_keys

Além disso, o controle remoto está tentando se conectar à sua raiz local? Nesse caso, você também deve verificar o permitrootlogin.

Espero que ajude ...

    

Answer 4

Eles podem entrar normalmente usando um nome de usuário e senha? Caso contrário, pode ser que o shell esteja definido como nologin ; verifique /etc/passwd para verificar se o shell está configurado corretamente.

    

Answer 5

Eu tive o mesmo problema (CentOS 6.0). Se o SELinux estiver ligado, tente fazer o seguinte:

restorecon -R -v /root/.ssh