SSH richiede ancora la password dopo aver impostato l'autenticazione basata su chiave


10

Ho creato con successo un'autorizzazione basata su chiave per l'utente root dalla mia macchina A alla mia macchina B.

Ora, ho creato un nuovo utente sulla macchina B, lo stesso che sulla macchina A, chiamiamolo USER. Ho creato una home directory per lui sulla macchina B /home/USERe voglio creare un'autorizzazione basata su chiave per lui dalla macchina A alla macchina B.

Quindi, ho corso su una macchina

  1. ssh-keygen -t rsa, ha accettato tutti i percorsi, quindi /home/USER/.ssh/id_rsae senza frasi
  2. ssh-copy-id -i /home/USER/.ssh/id_rsa.pub USER@BmachinesIP, ha inserito la password e ha ricevuto il massaggio

Ora prova ad accedere alla macchina bla bla bla

Quindi sembra tutto a posto.

Ma quando ho provato a connettermi ssh USER@BmachinesIPmi è stata chiesta una password. Ho provato a vedere il registro ed eseguito ssh -vvv USER@BmachinesIPed ecco una parte dell'output:

debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-keyex,gssapi-with-mic,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: /home/USER/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/USER/.ssh/id_dsa
debug3: no such identity: /home/USER/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
USER@BmachinesIP's password:

Quindi, qualcuno può dirmi cosa ho fatto di sbagliato o cosa dovrei cambiare? Forse il problema è nelle autorizzazioni, eccole:

su una macchina:

drwx------  2 USER USER    SIZE DATE TIME .ssh
-rw-------  1 USER USER 1675 2011-10-31 14:36 id_rsa
-rw-r--r--  1 USER USER 413 2011-10-31 14:36 id_rsa.pub

e sulla macchina B:

drwx------  2 USER defaultGroup    SIZE DATE TIME .ssh
-rw-------    1 USER defaultGroup    SIZE DATE TIME authorized_keys

Risposte:


13

Ho trovato una soluzione Si è verificato un problema con le autorizzazioni.

/home/USER sulla macchina remota sono state concesse tutte le autorizzazioni, ma per l'autent basata su chiave deve essere impostato su 755


2
Wow. Incredibile che non vi sia alcun output di debug sulle autorizzazioni anche se sono fondamentali per la corretta configurazione della chiave pubblica.
— jchook,

Wow, hai ragione. Ora funziona .... anche se voglio davvero mantenere il permesso che aveva originariamente (775). Qualche idea su come cambiarlo?
— Pablo Olmos de Aguilera C.

Sembra che non ci sia alcun modo, solo la soluzione alternativa sarebbe impostare No StrictModes in sshd_config. : /.
— Pablo Olmos de Aguilera C.

2
In sostanza hai bisogno di queste autorizzazioni:, chmod o-w ~/; chmod 700 ~/.ssh; chmod 600 ~/.ssh/authorized_keysquindi funziona. Copiato dalla risposta di Maxime R. da qui: askubuntu.com/questions/54670/passwordless-ssh-not-working
— erik

2
Ho apportato tutte queste modifiche ai permessi e mi chiede ancora una password quando ssh. Ho anche verificato che la chiave privata è la stessa su entrambe le macchine (Ubuntu). Abbastanza perplesso.
— Amalgovinus,

2

Lo stesso problema per me nuova installazione di CentOS7.

1. controlla le autorizzazioni home dir e le autorizzazioni ~ / .ssh e ~ / .ssh / authorized_keys (come da @erik)

chmod o-w ~/; chmod 700 ~/.ssh; chmod 600 ~/.ssh/authorized_keys

2. controlla le impostazioni / etc / ssh / sshd_config && service sshd restart (dopo ogni modifica) Utile: prova "LogLevel VERBOSE" in sshd_config.

Ho ancora ricevuto la richiesta della password dopo aver controllato tutto ciò che era ok.

Esegui il client ssh con i registri -vvv:

debug3: send_pubkey_test 
debug2: we sent a publickey packet, wait for reply

Log del server (/ var / log / secure):

Failed publickey for * from * port * ssh2: RSA *

Il server SSH non invia più informazioni di errore al client poiché ciò costituirebbe un rischio per la sicurezza.

Se avessi eseguito sshd su un'altra porta 'sshd -p 5555 -d'. La chiave ha funzionato. Accesso senza password ok. WTF?

Quindi ho disabilitato selinux (impostare SELINUX = disabilitato in / etc / selinux / config) e riavviare. Il login senza password ha funzionato bene.

le mie attuali impostazioni sshd_config funzionanti:

[root@hp-bl-05 ~]# grep -vE "^#|^$" /etc/ssh/sshd_config  
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
SyslogFacility AUTHPRIV
LogLevel VERBOSE
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile  .ssh/authorized_keys
HostbasedAuthentication yes
PasswordAuthentication yes
ChallengeResponseAuthentication no
GSSAPIAuthentication no
GSSAPICleanupCredentials no
UsePAM yes
X11Forwarding yes
UseDNS no
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE
AcceptEnv XMODIFIERS
Subsystem   sftp    /usr/libexec/openssh/sftp-server

Quindi sarebbe bello sapere se potremmo cambiare qualcosa di piccolo in selinux per far funzionare il login ssh senza password. Qualcuno può migliorare la risposta?


0

La soluzione non sta disabilitando SELinux ma per correggere le autorizzazioni SELinux della directory utente. Il contesto della directory utente deve essere impostato su user_home_t.

Controllare,

$ sudo ls -Z /home/

Se il contesto per la tua directory utente è qualcosa di diverso user_home_t, SELinux non consentirebbe SSH tramite chiave pubblica nella directory utente per quell'utente.

Aggiustare,

$ sudo semanage fcontext -a -t user_home_t /home/azureuser
$ sudo restorecon -vvRF /home/azureuser

L'accesso basato su chiave ora dovrebbe funzionare.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.