ssh com a chave rsa pede senha

Question

Eu tenho um servidor com o sistema operacional Ubuntu 14.04 x64.

Parte do meu arquivo sshd_config ( arquivo inteiro ):

Port 2202
Protocol 2
PermitRootLogin without-password
StrictModes yes
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile      /etc/ssh/keys/%u/authorized_keys
RhostsRSAAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
#PasswordAuthentication yes
UsePAM yes

Na pasta /etc/ssh/keys , cada usuário do sistema tem sua própria pasta com authorized_keys file:

ls -l /etc/ssh/keys
drw------- 2 test.com  test.com   4096 Nov 20 06:53 test.com
drw------- 2 root      root       4096 Nov 20 02:29 root

As permissões desses arquivos authorized_keys estão corretas:

ls -l /etc/ssh/keys/*
/etc/ssh/keys/test.com:
total 4
-r-------- 1 test.com test.com 960 Nov 20 07:17 authorized_keys

/etc/ssh/keys/root:
total 4
-r-------- 1 root root 395 Nov 20 02:29 authorized_keys

Eu tenho o mesmo id_rsa público no arquivo authorized_keys do root e do test.com.
Eu consigo logar com root através do ssh, mas com o test.com eu sou solicitado a digitar a senha.

Aqui está a informação de depuração ao tentar se conectar com o usuário test.com:

debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/Ivan/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /Users/Ivan/.ssh/id_dsa
debug1: Next authentication method: password

Quando tento fazer o login com raiz, obtenho sucesso:

debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/Ivan/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug1: Authentication succeeded (publickey).

Eu pesquisei muitas coisas no Google. Não foi possível encontrar nada que resolva meu problema.

Eu tenho um script que cria usuários do sistema usando o comando useradd e esses usuários não têm senhas por padrão. Descobri que os usuários do sistema sem senha podem não fazer login através do ssh, por isso adicionei a senha ao usuário test.com. Não funcionou.

Eu vi que UsePAM yes pode ser um problema. Eu configurei para UsePAM no . Não funcionou.

E sim, eu fiz service ssh restart após cada alteração no arquivo sshd_config .

Eu acho que já tentei de tudo e agora estou sem noção.

Qualquer ajuda será apreciada!

    

Answer 1

Eu tive o mesmo problema e descobri que o SELinux estava impedindo o acesso de leitura ao /usr/bin/sshd ao tentar fazer o remote in para alguns usuários. Geralmente, para usuários que não têm uma pasta base em /home/ . Você pode correr

cat /var/log/messages | grep -i ssh

no servidor de destino , e você deverá ver uma linha semelhante indicando o erro:

<Date/Time> <hostname> python: SELinux is preventing /usr/sbin/sshd from read access on the file authorized_keys.#012#012*****  Plugin catchall (100. confidence) suggests   **************************#012#012
If you believe that sshd should be allowed read access on the authorized_keys file by default.#012Then you should report this as a bug.#012
You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# 
ausearch -c 'sshd' --raw | audit2allow -M my-sshd#012# semodule -i my-sshd.pp#012'

Você pode editar as permissões do SELinux para permitir conexões ssh ou simplesmente desativá-las (com menos segurança) para contornar isso.

    

Answer 2

O sshd é muito exigente quando se trata de permissões!

Parece que as permissões de diretório de /etc/ssh/keys/test.com/ estão erradas! Atualmente, o diretório é de leitura / gravação, mas não pode ser inserido. %código% deve resolver o seu problema. Embora o root possa entrar no diretório, suponho que o sshd verifique se as permissões octal são chmod u+x /etc/ssh/keys/test.com/ && chmod o+rx /etc/ssh/keys ou 0700 + 0755 para o próprio arquivo authorized_keys. Especialmente, quando 0600 .

Sem permissão de acesso ao diretório e permissões apropriadas, o arquivo authorized_keys não pode ser lido ou está sendo ignorado pelo sshd por questões de segurança.