Impossibile ottenere l'autenticazione con chiave pubblica SSH per funzionare [chiuso]

Il mio server esegue CentOS 5.3. Sono su un Mac con Leopard. Non so quale 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 su http://www.centos.org/docs/5/html/Deployment_Guide-en-US/s1-ssh-beyondshell.html ), ma quando Uso SSH, si rifiuta persino di provare la verifica di publickey. Usando il comando

ssh -vvv user@host

(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 una richiesta per la mia password. Se provo a forzare il problema con

ssh -vvv -o PreferredAuthentications=publickey user@host

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 di offerta:" sopra.) Qualche suggerimento?

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.

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 restoreconstrumento in questo modo:

restorecon -Rv /home

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

RSAAutenticazione sì
PubkeyAutenticazione sì

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

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

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

chmod 755 / home / xxx

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, tuttavia, 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 -vv, ma i registri hanno spiegato chiaramente cosa stava succedendo

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.

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/$userper superare i miei fallimenti ssh.

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

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

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

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

L'output del client come in ssh -vrivelerà che c'è un problema ad un certo passo nel 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 rootper avere le autorizzazioni per farlo. Ad esempio, per un sshdconfigurato 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

La ragione in questo caso era un (stupido) default defaultdi 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). Puoi risolvere il problema usando chmod.

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

sono rimasto intrappolato nello stesso problema accedendo con fedora core da 16 a centesimi 5,5

i registri e il verbose erano 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)

Un altro morso da questo. Dopo una lunga ricerca si è scoperto che stavo esplicitamente fornendo a ssh la chiave pubblica (con l'opzione -i) invece della chiave privata. Doh!