chaves SSH falham para um usuário

Question

Eu apenas configurei um novo servidor Debian. Eu desabilitei o SSH root e a senha auth, então você precisa usar um arquivo de chave.

Para meu usuário principal, tudo funciona exatamente como esperado. Eu usei ssh-keygen -t dsa e consegui uma chave pública e privada. Coloque um em chaves autorizadas, coloque o outro em um arquivo pem localmente.

Eu queria criar um usuário com o qual eu pudesse implantar coisas, então fiz basicamente o mesmo processo. Eu adduser ed, fiz um .ssh pasta, corri ssh-keygen -t dsa (eu também tentei RSA), coloque as chaves em seus locais apropriados.

Sem sorte. Estou recebendo um erro Permission denied (publickey) . Quando eu uso exatamente as mesmas chaves que a conta que funciona, o mesmo erro. Quando habilito a autenticação de senha, posso efetuar login via SSH com a senha.

Como depuro isso?

EDITAR

Verbose ssh output (deployer.pem é a chave apropriada):

debug2: key: /Users/eli/.ec2/deployer.pem (0x100126830)
debug2: key: /Users/eli/.ec2/deployer.pem (0x100126b30)
debug2: key: /Users/eli/.ec2/deployer.pem (0x0)
debug1: Authentications that can continue: publickey
debug3: start over, passed a different list publickey
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /Users/eli/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey
debug1: Offering public key: eli.pem
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey
debug1: Offering public key: /Users/eli/.ec2/deployer.pem
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey
debug1: Offering public key: /Users/eli/.ec2/deployer.pem
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey
debug1: Trying private key: /Users/eli/.ec2/deployer.pem
debug1: read PEM private key done: type DSA
debug3: sign_and_send_pubkey
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).

    

Answer 1

Duas partes: primeiro, ative a depuração no seu ssh sever. Edite /etc/ssh/sshd_config e aumente LogLevel para DEBUG. Então force seu servidor ssh a recarregar sua configuração com killall -HUP <sshd pid> .

Isso fará com que o servidor adicione muito mais detalhes aos arquivos de log /var/log/secure e / ou /var/log/auth .

Em segundo lugar (na verdade você não pode tentar isso primeiro), aumentar o nível de depuração no lado do cliente. ssh para a caixa com

$ ssh -vvv hostname

e isso imprimirá muito mais informações sobre onde o processo está falhando.

Se você aumentar o nível de depuração no seu servidor ssh, não se esqueça de desativá-lo quando terminar.

    

Answer 2

Você verificou as permissões nos arquivos de chaves? O arquivo .ssh/id_dsa deve ser 600 e de propriedade do usuário. Execute ssh -v root@host para ver se esse é o problema.

    

Answer 3

Se o diretório pessoal do usuário, o diretório .ssh no diretório inicial do usuário ou o arquivo authorized_keys do usuário for gravável por qualquer pessoa que não seja o usuário (grupo ou outro), a autenticação da chave falhará porque o .ssh / authorized_keys o arquivo não pode mais ser confiável (como outro usuário poderia substituí-lo ou modificá-lo e, assim, efetuar login como esse usuário).

Tente:

chmod go-w ~USER ~USER/.ssh ~USER/.ssh/authorized_keys

e veja se isso elimina o seu problema.

    

Answer 4

chown -R username. /home/username/.ssh

chmod 700 /home/username/.ssh

chmod 400 /home/username/.ssh/id_dsa /home/username/.ssh/id_dsa.pub

chmod 600 /home/username/.ssh/authorized_keys

    

Answer 5

Aqui estão algumas dicas baseadas nos problemas que eu tive ao tentar fazer o ssh funcionar via Autenticação do Pubkey, isto é, ssh rsa:

além das dicas acima (permissões, -vvv): - no servidor de destino, verifique as informações da conta por meio do passwd -S username ou passwd -s username. A saída será semelhante a [nome de usuário] [stat] [pwchg] [min] [max] [warn]. se a coluna [stat] disser LK, você precisa desbloquear o nome de usuário passwd -u da conta. se a data [pwchg] for mais antiga que [max] dias, você precisará alterar os dias máximos ou alterar a senha no nome de usuário por meio de passwd -x 999 ou passwd username

exemplo:

# uname -n
myserver

# pwd
/export/home/santac
# ls -l .ssh
-rw-------   1 santac   users        796 Jul  8 00:27 authorized_keys
# cat .ssh/authorized_keys
ssh-rsa AAABBBCCCboogaboogaAAABBBCCCidonthinkyougetthatthisisbogusbutwhattheheck== santac@otherserv
# date
Wed Jul  8 00:55:10 GMT 2015
# passwd -S santac
santac    LK    03/05/14     7   60     10
(note stat is LK or locked)
# passwd -u santac
# passwd -S santac
santac    PS    03/05/14     7   60     10
(note [pwchg] date is older than 60 days)
# passwd santac
Enter New Password:
Confirm New Password:
# passwd -S santac
santac    PS    07/08/15     7   60     10
(all good now)

FROM THE OTHER SERVER:
# uname -n
otherserv
# pwd
/export/home/santac
# ls -l .ssh
-rw-------   1 santa   users       1675 Jul  6 20:23 id_rsa
-rw-------   1 santa   users        394 Jul  6 20:23 id_rsa.pub
# cat .ssh/id_rsa.pub
ssh-rsa AAABBBCCCboogaboogaAAABBBCCCidonthinkyougetthatthisisbogusbutwhattheheck== santac@otherserv

LOOKS GOOD...