Perché sto ancora ricevendo una richiesta di password con ssh con autenticazione con chiave pubblica?

Sto lavorando dall'URL che ho trovato qui:

http://web.archive.org/web/20160404025901/http://jaybyjayfresh.com/2009/02/04/logging-in-without-a-password-certificates-ssh/

Il mio client ssh è desktop Ubuntu 64 bit 11.10 e il mio server è Centos 6.2 64 bit. Ho seguito le indicazioni. Ricevo ancora una richiesta di password su ssh.

Non sono sicuro di cosa fare dopo.

Assicurarsi che le autorizzazioni per la ~/.sshdirectory e il suo contenuto siano corrette. Quando ho impostato per la prima volta la mia chiave di autenticazione ssh, non avevo la ~/.sshcartella impostata correttamente e mi ha urlato contro.

• La tua home directory ~, la tua ~/.sshdirectory e il ~/.ssh/authorized_keysfile sul computer remoto devono essere scrivibili solo da te: rwx------e rwxr-xr-xvanno bene, ma rwxrwx---non vanno bene¹, anche se sei l'unico utente del tuo gruppo (se preferisci le modalità numeriche: 700oppure 755no 775) .
  Se ~/.ssho authorized_keysè un collegamento simbolico, viene controllato il percorso canonico (con collegamenti simbolici espansi) .
• Il ~/.ssh/authorized_keysfile (sul computer remoto) deve essere leggibile (almeno 400), ma sarà necessario che sia anche scrivibile (600) se si aggiungono ulteriori chiavi.
• Il tuo file di chiave privata (sul computer locale) deve essere leggibile e scrivibile solo da te: ad rw-------es 600.
• Inoltre, se SELinux è impostato per l'applicazione, potrebbe essere necessario eseguire restorecon -R -v ~/.ssh(vedere ad es. Bug Ubuntu 965663 e segnalazione bug Debian # 658675 ; questo è corretto in CentOS 6 ).

¹ _{Tranne alcune distribuzioni (Debian e derivati) che hanno corretto il codice per consentire la scrivibilità del gruppo se sei l'unico utente del tuo gruppo.}

Se si dispone dell'accesso root al server, il modo più semplice per risolvere tali problemi è eseguire sshd in modalità debug, emettendo qualcosa di simile /usr/sbin/sshd -d -p 2222sul server (è necessario il percorso completo dell'eseguibile sshd, which sshdpuò aiutare) e quindi connettersi dal client con ssh -p 2222 user@host. Ciò costringerà il demone SSH a rimanere in primo piano e visualizzare le informazioni di debug su ogni connessione. Cerca qualcosa di simile

debug1: trying public key file /path/to/home/.ssh/authorized_keys
...
Authentication refused: bad ownership or modes for directory /path/to/home/

Se non è possibile utilizzare una porta alternativa, è possibile arrestare temporaneamente il demone SSH e sostituirlo con uno in modalità debug. L'arresto del demone SSH non interrompe le connessioni esistenti, quindi è possibile farlo tramite un terminale remoto, ma in qualche modo rischioso - se la connessione si interrompe in qualche modo in un momento in cui la sostituzione del debug non è in esecuzione, si viene bloccati dalla macchina fino a quando non è possibile riavviarlo. I comandi richiesti:

service ssh stop
/usr/sbin/sshd -d
#...debug output...
service ssh start

(A seconda della distribuzione Linux, la prima / ultima riga potrebbe essere systemctl stop sshd.service/ systemctl start sshd.serviceinvece.)

La tua home directory è crittografata? In tal caso, per la tua prima sessione SSH dovrai fornire una password. La seconda sessione ssh sullo stesso server funziona con la chiave di autenticazione. In questo caso, potresti spostare il tuo authorized_keysin una directory non crittografata e modificare il percorso in ~/.ssh/config.

Quello che ho finito per fare è stato creare una /etc/ssh/usernamecartella, di proprietà del nome utente, con le autorizzazioni corrette e inserito il authorized_keysfile. Quindi modificato la direttiva AuthorizedKeysFile in /etc/ssh/config:

AuthorizedKeysFile    /etc/ssh/%u/authorized_keys

Ciò consente a più utenti di avere questo accesso ssh senza compromettere le autorizzazioni.

Dopo aver copiato le chiavi sul computer remoto e averle inserite all'interno, authorized_keysdevi fare qualcosa del genere:

ssh-agent bash
ssh-add ~/.ssh/id_dsa or id_rsa

Prova questi seguenti comandi

1. ssh-keygen

   Premere il tasto Invio fino a quando non viene visualizzato il messaggio

2. ssh-copy-id -i root@ip_address

   (Chiederà una volta la password del sistema host)

3. ssh root@ip_address

   Ora dovresti essere in grado di accedere senza alcuna password

Ho affrontato sfide quando la home directory sul telecomando non ha i privilegi corretti. Nel mio caso l'utente ha cambiato la home directory in 777 per un accesso locale con nel team. La macchina non è più riuscita a connettersi con i tasti SSH. Ho cambiato il permesso in 744 e ha ricominciato a funzionare.

SELinux su RedHat / CentOS 6 ha un problema con l'autenticazione pubkey , probabilmente quando vengono creati alcuni file selinux non sta impostando correttamente i propri ACL.

Per correggere manualmente gli ACL di SElinux per l'utente root:

restorecon -R -v /root/.ssh

Abbiamo riscontrato lo stesso problema e abbiamo seguito i passaggi nella risposta. Ma non ha ancora funzionato per noi. Il nostro problema era che il login funzionava da un client ma non da un altro (la directory .ssh era montata su NFS ed entrambi i client utilizzavano le stesse chiavi).

Quindi abbiamo dovuto fare un ulteriore passo avanti. Eseguendo il comando ssh in modalità dettagliata si ottengono molte informazioni.

ssh -vv user@host

Ciò che abbiamo scoperto è che la chiave predefinita (id_rsa) non è stata accettata e invece il client ssh ha offerto una chiave corrispondente al nome host del client:

debug1: Offering public key: /home/user/.ssh/id_rsa                                    
debug2: we sent a publickey packet, wait for reply                                        
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering public key: /home/user/.ssh/id_dsa                                    
debug2: we sent a publickey packet, wait for reply                                        
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering public key: user@myclient                                          
debug2: we sent a publickey packet, wait for reply                                        
debug1: Server accepts key: pkalg ssh-rsa blen 277                  

Ovviamente questo non funzionerà da nessun altro client.

Quindi la soluzione nel nostro caso era quella di passare la chiave rsa predefinita a quella che conteneva user @ myclient. Quando una chiave è predefinita, non è possibile verificare il nome del client.

Quindi abbiamo riscontrato un altro problema, dopo il passaggio. Apparentemente le chiavi sono memorizzate nella cache nell'agente ssh locale e abbiamo ottenuto il seguente errore nel registro di debug:

'Agent admitted failure to sign using the key'

Ciò è stato risolto ricaricando le chiavi dell'agente ssh:

ssh-add

Sarebbe SSH Miss Configuration alla fine del server. Il file sshd_config lato server deve essere modificato. Situato in /etc/ssh/sshd_config. In quel file, cambia le variabili

• da "sì" a "no" per ChallengeResponseAuthentication, PasswordAuthentication, UsePAM

• 'no' a 'yes' per PubkeyAuthentication

Basato su http://kaotickreation.com/2008/05/21/disable-ssh-password-authentication-for-added-security/

Assicurati che AuthorizedKeysFilepunti nella posizione corretta, utilizza %ucome segnaposto per il nome utente:

# /etc/ssh/sshd_config
AuthorizedKeysFile /home/%u/authorized_keys

Potrebbe essere che devi solo decommentare la linea:

AuthorizedKeysFile .ssh / authorized_keys

Ricorda che è necessario ricaricare il servizio ssh affinché le modifiche abbiano luogo:

service sshd reload

Due commenti: questo sovrascriverà il file originale. Vorrei solo copiare la chiave pubblica generata e fare qualcosa del tipo:

cat your_public_key.pub >> .ssh/authorized_keys

Ciò aggiungerà la chiave che si desidera utilizzare all'elenco di chiavi preesistente. Inoltre, alcuni sistemi utilizzano il file authorized_keys2, quindi è una buona idea creare un collegamento rigido che punti tra authorized_keyse authorized_keys2, per ogni evenienza.

La mia soluzione era che l'account era bloccato. Messaggio trovato in / var / log / secure: Utente non consentito perché l'account è bloccato Soluzione: fornire all'utente una nuova password.

Ho riscontrato un problema simile e ho seguito i passaggi utilizzando la modalità debug.

/usr/sbin/sshd -d

Ciò ha mostrato il seguente risultato

debug1: trying public key file /root/.ssh/authorized_keys
debug1: fd 4 clearing O_NONBLOCK
Authentication refused: bad ownership or modes for directory /root
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: trying public key file /root/.ssh/authorized_keys2
debug1: Could not open authorized keys '/root/.ssh/authorized_keys2': No such file or directory
debug1: restore_uid: 0/0
Failed publickey for root from 135.250.24.32 port 54553 ssh2
debug1: userauth-request for user root service ssh-connection method gssapi-with-mic

È stato davvero confuso

[root@sys-135 ~]# ls -l /
drwxrwxrwx.   2 root root     4096 Dec 14 20:05 bin
drwxrwxrwx.   5 root root     1024 May  6  2014 boot
drwxrwxrwx.   2 root root     4096 Dec  2  2013 cgroup
drwxrwxrwx.  10 root root     1024 Sep 25 23:46 data
drwxrwxrwx. 124 root root    12288 Dec 16 10:26 etc
drwxrwxrwx.  11 root root     4096 Jan 14  2014 lib
drwxrwxrwx.   9 root root    12288 Dec 14 20:05 lib64
drwxrwxrwx.   2 root root    16384 Jan 10  2014 lost+found
drwxrwxrwx.   2 root root     4096 Jun 28  2011 media
drwxr-xr-x.   2 root root        0 Dec 10 14:35 misc
drwxrwxrwx.   2 root root     4096 Jun 28  2011 mnt
drwxrwxrwx.   4 root root     4096 Nov 24 23:13 opt
dr-xr-xr-x. 580 root root        0 Dec 10 14:35 proc
drwxrwxrwx.  45 root root     4096 Dec 16 10:26 root

Ha mostrato che la directory principale aveva i permessi per ognuno. Lo abbiamo cambiato in modo che gli altri non avessero i permessi.

[root@sys-135 ~]# chmod 750 /root

L'autenticazione con chiave ha iniziato a funzionare.

Nel file / etc / selinux / config la modifica di SELINUX in disabilitato dall'applicazione forzata ha fatto sì che ssh senza password funzionasse correttamente.

In precedenza sono in grado di farlo in un modo. Ora da entrambe le parti sono in grado di fare ssh senza password.

Una cosa che ho sbagliato era la proprietà sulla mia home directory sul sistema server. Il sistema server è stato impostato sul valore predefinito: default quindi I:

chown -R root:root /root

E ha funzionato. Un'altra soluzione economica è Disabilitare StrictModes: StirctModes no. in sshd_config. Questo ti dirà almeno se i protocolli di scambio delle chiavi e di connessione sono buoni. Quindi puoi andare a caccia delle autorizzazioni sbagliate.

Per me, la soluzione era di fronte a Wojtek Rzepala : non avevo notato che stavo ancora usando authorized_keys2, che è stato deprecato . La mia configurazione ssh ha smesso di funzionare ad un certo punto, presumibilmente quando il server è stato aggiornato. Rinominare .ssh/authorized_keys2come .ssh/authorized_keysrisolto il problema.

D'oh!

In passato mi sono imbattuto in alcuni tutorial che descrivono come ottenere una configurazione senza password SSH, ma alcuni sono purtroppo sbagliati.
Ricominciamo da capo e controlliamo ogni passaggio:

1. DAL CLIENTE - Genera chiave: la chiave ssh-keygen -t rsa
   pubblica e privata ( id_rsa.pube id_rsa) verrà automaticamente memorizzata nella ~/.ssh/directory.
   L'installazione sarà più semplice se si utilizza una passphrase vuota. Se non sei disposto a farlo, segui comunque questa guida, ma controlla anche il punto seguente.
   
   
2. DAL CLIENTE - Copia la chiave pubblica sul server : ssh-copy-id user@server
   la chiave pubblica del client verrà copiata nella posizione del server ~/.ssh/authorized_keys .
   
   
3. DAL CLIENTE - Connetti al server:ssh user@server
   
   

Ora, se non funziona ancora dopo i 3 passaggi descritti, proviamo quanto segue:

• Controlla le ~/sshautorizzazioni per le cartelle nel computer client e server .
• Verificare /etc/ssh/sshd_confignel server per assicurarsi che RSAAuthentication, PubkeyAuthenticatione le UsePAMopzioni non siano disabilitate, possano essere abilitate per impostazione predefinita con yes.
• Se hai inserito una passphrase durante la generazione della chiave del client, puoi provare ssh-agent&ssh-add ottenere connessioni senza password nella sessione.
• Controllare i contenuti di /var/log/auth.logsul server per trovare il problema per cui l'autenticazione con chiave viene saltata affatto.

Stavo avendo lo stesso identico problema con la connessione PuTTY a una macchina Ubuntu 16.04. Era sconcertante perché il programma pscp di PuTTY funzionava bene con la stessa chiave (e la stessa chiave funzionava in PuTTY per connettersi a un altro host).

Grazie al prezioso commento di @UtahJarhead, ho controllato il mio file /var/log/auth.log e ho trovato quanto segue:

sshd[17278]: userauth_pubkey: key type ssh-dss not in PubkeyAcceptedKeyTypes [preauth]

Si scopre che le versioni più recenti di OpenSSH non accettano le chiavi DSA per impostazione predefinita. Una volta passato da un DSA a una chiave RSA, ha funzionato bene.

Un altro approccio: questa domanda discute su come configurare il server SSH per accettare le chiavi DSA: https://superuser.com/questions/1016989/ssh-dsa-keys-no-longer-work-for-password-less-authentication?lq = 1

Questi passaggi dovrebbero aiutarti. Lo uso regolarmente tra molte macchine Ubuntu 10.04 a 64 bit.

[ ! -f ~/.ssh/id_rsa.pub ] && ssh-keygen -t rsa;
ssh <username>@<remote_machine> 'mkdir -p ~/.ssh'
cat ~/.ssh/id_rsa.pub | ssh <username>@<remote_machine> 'cat >> ~/.ssh/authorized_keys'

potresti metterlo in uno script con alcuni prompt e invocarlo come

script_name username remote_machine

Ho avuto un problema simile con ssh. Nel mio caso il problema era che ho installato hadoop cloudera (da rpm su centos 6) e ha creato hdf utente con home directory

/var/lib/hadoop-hdfs(non standard /home/hdfs).

Ho cambiato in / etc / passwd /var/lib/hadoop-hdfsin /home/hdfs, ho spostato la directory home in una nuova posizione e ora posso collegarmi con l'autenticazione con chiave pubblica.

Ho appena avuto questo stesso problema, e per me la soluzione è stata per impostare UsePAMa no. Vedi, anche se PasswordAuthenticationimpostato su no, otterrai comunque keyboard-interactive, e nel mio caso il mio programma ssh locale ha continuato a non farlo, per qualche motivo.

Background extra per aiutare chiunque abbia la stessa situazione: mi sto collegando da un host che esegue Dropbear a uno che esegue OpenSSH. Con PasswordAuthenticationed UsePAMentrambi impostati nosul computer remoto, se inserisco riceverò il seguente messaggio ssh user@server:

ssh: Connection to user@server:22 exited: Disconnect received

Fornendo il file di identità -i, tutto funziona come previsto.

Potrebbero esserci alcune informazioni in più qui.

Dopo aver controllato le autorizzazioni e provato diverse altre soluzioni elencate qui, ho finalmente rimosso la directory ssh sul server, e ho nuovamente impostato la mia chiave pubblica.

Comandi del server:

# rm -rf ~/.ssh

Comandi locali:

# ssh-copy-id user@192.168.1.1        # where <user> is your username and <192.168.1.1> is the server IP

Al server:

$ ls -lh /home
$ sudo chmod 700 /home/$USER

Lo è stato directory permission issue. Era 777 sul server, quindi I changed it back to 700. Questo è il fixedmio problema ssh password less login failureanche dopo aver copiato $USER/.ssh/id_rsa.pubsul server $USER/.ssh/authorized_keys.

Un'altra opzione è una variante del @Jagadish 's risposta : per straceil demone SSH.

Ha il vantaggio significativo, che non abbiamo bisogno di fermare la sshd, cosa può comportare un blocco completo se qualcosa va male.

Innanzitutto, troviamo il pid del processo sshd principale. Qui possiamo vederlo eseguendo un pstree -pa|less.

  |-sshd,633 -D  <-- THIS IS WHAT WE WANT!
  |   `-sshd,21973   
  |       `-sshd,21996    
  |           `-bash,22000
  |               `-screen,638 -r

Dopo aver saputo che il pid è 633, possiamo stracefarlo, seguendo i suoi figli:

strace -p 633 -s 4096 -f -o sux

Il risultato sarà che tutto ciò che questo sshd, e i suoi processi figli hanno fatto, saranno inseriti nel file indicato suxnella directory locale.

Quindi riprodurre il problema.

Avrà un enorme elenco di log delle chiamate del kernel, che è per lo più incomprensibile / irrilevante per noi, ma non ovunque. Nel mio caso, l'importante era questo:

6834  sendto(4, "<38>Jan 15 18:49:21 sshd[6834]: User cica not allowed because account is locked\0", 84, MSG_NOSIGNAL, NULL, 0) = 84

Significava che sshd ha tentato di registrare il messaggio User cica non consentito perché l'account è bloccato - non è stato possibile, perché la registrazione non è abbastanza dettagliata per questo. Ma sappiamo già, il pubkey è stato rifiutato perché l'account era bloccato.

Non è ancora una soluzione - ora abbiamo bisogno di google, che significa un "account bloccato" nel caso di sshd. Molto probabilmente sarà un po 'di magia, banale /etc/passwd, /etc/shadowma la cosa importante è fatta: il problema non è misterioso, ma facilmente debuggabile / googlabile.

Nel mio caso avevo tutte le autorizzazioni giuste e anche quando eseguivo ssh con -vvv flag non riuscivo a capire quale fosse il problema.

Quindi ho generato un nuovo certificato sull'host remoto

ssh-keygen -t rsa -C "your_email@example.com"

e ha copiato le chiavi generate sul computer locale e ha aggiunto una nuova chiave pubblica a ~ / .ssh / authorized_keys sull'host remoto

cat id_rsa.pub >> authorized_keys

L'uso delle chiavi generate dalla connessione della macchina host remota ora funziona. Quindi, se altre soluzioni falliscono, questa è un'altra cosa da provare.

Il mio scenario era che avevo un server NAS su cui ho creato un backupbotutente, dopo la creazione del mio account principale, che era in grado di accedere per creare inizialmente l' backupbotutente. Dopo aver armeggiato sudo vim /etc/ssh/sshd_confige creato l' backupbotutente, vimpuoi creare, almeno su Ubuntu 16.04 e in base alla tua ~/.vimrcconfigurazione, un file di scambio lasciato dalla modifica della tua sessione vim di/etc/ssh/sshd_config .

Controlla se: /etc/ssh/.sshd_config.swpesiste e se lo rimuove e riavvia il sshddemone:

$ sudo rm /etc/ssh/.sshd_config.swp
$ sudo service sshd restart

Questo ha magicamente risolto il mio problema. In precedenza avevo controllato tutte le mie autorizzazioni e persino le impronte digitali RSA delle chiavi pubbliche e private. Questo è strano e probabilmente un bug con sshd, in particolare questa versione:

OpenSSH_7.4p1 Ubuntu-10, OpenSSL 1.0.2g 1 marzo 2016