sviluppo-web-qa.it

Impossibile far funzionare l'autenticazione con chiave pubblica SSH

Il mio server esegue CentOS 5.3. Sono su un Mac con Leopard. Non so chi sia responsabile di questo:

Posso accedere al mio server bene tramite l'autenticazione con password. Ho seguito tutti i passaggi per impostare PKA (come descritto in http://www.centos.org/docs/5/html/Deployment_Guide-en-US/s1-ssh-beyondshell.html ), ma quando utilizzo SSH, rifiuta persino di provare la verifica con chiave pubblica. Usando il comando

ssh -vvv [email protected]

(dove -vvv porta la verbosità al massimo livello) Ottengo il seguente risultato rilevante:

debug2: key: /Users/me/.ssh/id_dsa (0x123456)
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-with-mic,password
debug3: preferred keyboard-interactive,password
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password

seguito da un prompt per la mia password. Se provo a forzare il problema con

ssh -vvv -o PreferredAuthentications=publickey [email protected]

Ottengo

debug2: key: /Users/me/.ssh/id_dsa (0x123456)
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-with-mic,password
debug3: preferred publickey
debug3: authmethod_lookup publickey
debug3: No more authentication methods to try.

Quindi, anche se il server dice che accetta il metodo di autenticazione publickey e il mio client SSH insiste su di esso, sono confutato. (Nota la cospicua assenza di una "Chiave pubblica offerta:" sopra.) Qualche suggerimento?

41
Trey Parkman

Verifica che la tua macchina Centos abbia:

RSAAuthentication yes
PubkeyAuthentication yes

in sshd_config

e assicurarsi di disporre delle autorizzazioni appropriate sulla directory ~/.ssh/della macchina centos.

chmod 700 ~/.ssh/
chmod 600 ~/.ssh/*

dovrebbe fare il trucco.

44
pyhimys

Ho avuto un problema simile: il PC remoto non ha potuto utilizzare l'autenticazione con chiave pubblica per accedere al server CentOs 6. Il problema nel mio caso era relativo a SELinux: la home directory dell'utente che cercava di accedere aveva messaggi in contesti di sicurezza. Ho risolto questo usando lo strumento restorecon in questo modo:

restorecon -Rv /home
17
Gareth

1- controlla il tuo/etc/ssh/sshd_config, assicurati di averlo

 RSAAutenticazione sì 
 PubkeyAuthentication sì 

2- controllare il registro sicuro dal computer remoto, cercare il registro degli errori del demone sshd di dettaglio. per esempio. nel mio Ubuntu

 # grep 'sshd'/var/log/secure | grep "Autenticazione rifiutata" | tail -5 
 4 ago 06:20:22 xxx sshd [16860]: Autenticazione rifiutata: cattiva proprietà o modalità per la directory /home/xxx[.____.[Aug 4 06:20:22 xxx sshd [16860 ]: Autenticazione rifiutata: cattiva proprietà o modalità per la directory /home/xxx[.____.[Aug 4 06:21:21 xxx sshd [17028]: Autenticazione rifiutata: cattiva proprietà o modalità per la directory /home/xxx
 4 ago 06:21:21 xxx sshd [17028]: Autenticazione rifiutata: cattiva proprietà o modalità per la directory /home/xxx[.____.[Aug 4 06:27:39 xxx sshd [20362]: Autenticazione rifiutata: cattiva proprietà o modalità per la directory /home/xxx

Quindi controlla la proprietà e le modalità per directory/home/xxx, forse è necessario eseguirlo

 chmod 755 /home/xxx
13
Jinyu Liu

Controlla che le tue autorizzazioni siano corrette e che la struttura dei file (in particolare l'ortografia) sia corretta, sia per i computer locali che per quelli remoti. L'URL a cui ti riferisci li indica tutti, ma vale la pena verificare che ciò che hai corrisponda. Normalmente le autorizzazioni generano un errore rilevante.

Hai verificato che la casella sshd_config sulla tua casella CentOS 5.3 sia impostata per consentire PubkeyAuthentication o RSAAuthentication?

Controllare i registri del server SSH sul sistema CentOS: potrebbe fornire ulteriori informazioni. Non sono sicuro che CentOS esegua il controllo della chiave ssh nella lista nera verificando che debian lo faccia, ma ho visto rifiuti di ssh publickey relativamente silenziosi per quanto riguarda l'output di -vvv, ma i registri hanno spiegato chiaramente cosa stava succedendo

11
Daniel Lawson

Fatto! Si è scoperto che era un problema sul lato client. (Penso che qualsiasi problema sul lato server avrebbe prodotto un output di debug più utile.) Per motivi a me sconosciuti, sul mio Mac, il file/etc/ssh_config aveva la riga

PubkeyAuthentication = no

Ho commentato quella riga e ora funziona tutto bene.

7
Trey Parkman

Oltre alle modalità di file/directory, assicurati che la proprietà sia corretta! Un utente deve possedere la propria directory home, .ssh/e i relativi file.

Ho dovuto correre chown -R $user:$user /home/$user per superare i miei errori ssh.

4
Visser

Mi sembra un problema di configurazione. Come Daniel ha suggerito ci sono due cose da controllare:

  1. Le chiavi SSH in $HOME/.ssh/authorized_keys sono leggibili; e
  2. SSHd è configurato per consentire l'accesso con chiave pubblica.
2
sybreon

Controlla il nome utente con cui stai tentando di accedere. Per impostazione predefinita è il tuo nome utente sul computer locale.

2
Creotiv

Controlla anche che sia in grado di fornire automaticamente una chiave o meno, usa -i path/to/key in caso contrario o solo per testare

2
Jimsmithkka

sono rimasto intrappolato nello stesso problema di accesso con il core Fedora da 16 a 5,5 centesimi

i registri e il verbose sembravano esattamente uguali

il problema era la chiave pubblica, ha ottenuto alcuni dati fasulli, li rigenera e li pubblica nel server sshd, tu sshd_client sta inviando le informazioni sulla chiave ma non è riconosciuto dal server (non corrisponde a nessuna delle chiavi in ​​authorized_keys)

1
Freaktor

L'output del client come in ssh -v rivelerà che c'è un problema ad un certo punto del protocollo, ma quando è dovuto a qualcosa sul server il client non verrà informato della causa. Controlla i file di registro del server per scoprire cosa c'è che non va. Probabilmente devi essere root per avere i permessi per farlo. Ad esempio, per un sshd configurato per accedere a syslog, potresti trovare i messaggi in /var/log/secure. Come questi:

Authentication refused: bad ownership or modes for directory /home/you/.ssh
Authentication refused: bad ownership or modes for file /home/you/.ssh/authorized_keys

Il motivo in questo caso era un (stupido) predefinito default di 0002. Ciò significa che l'accesso in scrittura per il gruppo. (Nome gruppo = nome utente, ma comunque.) Il demone SSH non si fiderà dei file che possono essere manomessi da altri rispetto all'utente (bene, e root, ovviamente). È possibile risolvere il problema utilizzando chmod.

chmod 700 ~/.ssh # solve the issue
chmod 720 ~/.ssh # reproduce the issue
# or similar for a file
1
Lumi