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.