Perché il login automatico tramite ssh con authorized

12

Ho creato un dsa-keypair privato / pubblico. Ho inserito la chiave pubblica sul server

~/.ssh/authorized_keys

Tutto è impostato come il mio altro server, ma sembra che il server stia semplicemente ignorando i miei sforzi.

security ssh login

— Magnar
fonte

Controlla /etc/ssh/ssh_confige /etc/ssh/sshd_configper verificare che nulla che desideri sia disabilitato.

— Kristopher Johnson,

Ti consigliamo di controllare anche sshd_config.

— Vagnerr,

Grazie. Ho aggiornato la risposta (che originariamente menzionava solo ssh_config).

— Kristopher Johnson,

Tutte le discussioni di cui sopra sono perfette se stai usando uno stile openssh di ssh. Se il tuo sistema sta usando ssh2, ha un modo totalmente diverso di gestire le chiavi. Questo articolo discute come e come. burnz.wordpress.com/2007/12/14/…

— chris,

1

Solitamente il controllo /var/log/auth.logsui sistemi Debian o /var/log/securesu quelli RedHat dovrebbe darti un chiaro consiglio su cosa non è corretto (di solito problemi di autorizzazione)

— Giovanni Toraldo,

15

Anche se il tuo problema potrebbe essere già stato risolto da altre risposte, mi sono bloccato fuori da un numero sufficiente di macchine dal non convalidare le modifiche sshd_config prima della disconnessione, quindi ho escogitato il seguente processo che potrebbe essere utile per il debug futuro delle modifiche alla configurazione di sshd:

NON SCOLLEGARE una connessione ssh attiva fino a quando DOPO il test non ha verificato che il comportamento è come previsto.

un. verifica cosa pensi che sshd dovrebbe fare

b. verificare che la configurazione sia valida utilizzando "-t"

c. avviare una versione 'test' dettagliata del server su cui è possibile vivere il monitoraggio

d. avviare una connessione client 'test' dettagliata che è possibile monitorare dal vivo

un. verifica cosa pensi che sshd dovrebbe fare

Esamina il file di configurazione sshd senza tutti i commenti con qualcosa come il seguente (supponendo che sshd_config sia il file corretto e in / etc / ssh)

$ grep -v "^ #" / etc / ssh / sshd_config | grep -v "^ $"

Questo chiarisce le cose in modo da verificare ciò che pensiamo di cambiare (non necessariamente se è corretto o meno).

b. verificare che la configurazione sia valida utilizzando "-t"

Dalla pagina man della sshd che sto usando,

-t Modalità test. Controlla solo la validità del file di configurazione e l'integrità delle chiavi. Questo è utile per aggiornare sshd in modo affidabile poiché le opzioni di configurazione possono cambiare.

Altri cambiamenti possono avere circostanze più sottili. Ad esempio, non disabilitare l'autenticazione con password finché non si è certi che l'autenticazione con chiave pubblica funzioni correttamente.

c. avviare una versione 'test' dettagliata del server su cui è possibile vivere il monitoraggio

$ sudo / usr / sbin / sshd -ddd -p 9999

Ciò mantiene attiva la sessione di lavoro esistente, ma offre un'altra istanza di sshd per verificare le nuove modifiche alla configurazione. SSHD è ora in esecuzione in primo piano su una porta definita dall'utente (nel nostro esempio 9999) e spingendo molte informazioni di debug rumorose è possibile tracciare in / var / log / authlog (o eventualmente /var/log/auth.log a seconda sul tuo sistema operativo.)

d. avviare una connessione client 'test' dettagliata che è possibile monitorare dal vivo

Esegui la connessione client ssh in modalità dettagliata per visualizzare sullo schermo più informazioni che potrebbero portare a un migliore debug del tuo errore.

$ ssh -vvv -p 9999 nome-server

Ora è necessario disporre di informazioni sufficienti nei file di registro del server o nella schermata di connessione del client per isolare il problema.

La soluzione generalmente si riduce alle autorizzazioni dei file (come mostrato da Magnar e setatakahashi)

Buona fortuna

— sAMT
fonte

Suppongo che dovresti anche controllare il file ssh_config sull'estremità del client per assicurarti che stia facendo quello che ti aspetti. Usa qualcosa come il seguente per visualizzare i commenti:> grep -v "^ #" / etc / ssh / ssh_config | grep -v "^ $"

— samt

Bene, la configurazione del client ssh può essere riparata in qualsiasi momento, è il server dal quale verrai bloccato se lo hai configurato in modo errato.

— Soviero

33

Il server ignorerà il file authorized_keys se le proprietà del proprietario sono errate. Modificandolo in questo risolve:

chmod 0700 ~/.ssh
chmod 0600 ~/.ssh/authorized_keys

— Magnar
fonte

6

ssh -vvv -l username server.domain ti dirà se stai inviando una chiave valida

— Dave Cheney,

A volte ho visto sshd lamentarsi delle cattive autorizzazioni sulla home directory - quindi aggiungerei "chmod o-rwx ~" (o almeno "chmod ow ~") all'elenco come ha fatto setatakahashi. Questo di solito diventa ovvio quando il file di registro viene monitorato - i messaggi di errore che ho visto lì puntavano sempre nella direzione corretta.

— Olaf,

Questa risposta sembra la più probabile, ma il commento di Dave Cheney è l'unico modo per vedere cosa sta realmente succedendo. Controlla anche i log del server.

— dwc,

Questo era il mio problema Ho battuto la testa su questo per ore. Grazie mille!

— Sam Soffes,

1

Questo ha funzionato, ma i miei permessi precedenti erano 0775e 0644rispettivamente. Perché ridurre le autorizzazioni ha aiutato? È una precauzione di sicurezza configurata da qualche parte?

— Decano del

11

$ chmod 700 ~

$ chmod 700 ~ / .ssh

$ chmod 600 ~ / .ssh / authorized_keys

Controlla questi attributi in / etc / ssh / sshd_config

$ sudo grep PubkeyAuthentication / etc / ssh / sshd_config

$ sudo grep Protocol / etc / ssh / sshd_config

— setatakahashi
fonte

2

Ottimo punto su ~, devi assicurarti che nessuno tranne te possa scrivere nella tua home directory, altrimenti potrebbero rinominare la tua directory ~ / .ssh

— Dave Cheney il

quell'ultimo chmod dovrebbe essere: $ chmod 600 ~/.ssh/authorized_keysno$ chmod 600 ~/.sHh/authorized_keys

— SooDesuNe,

3

quali dovrebbero essere i valori degli attributi ?

— Michael,

0

Un'altra trappola importante ..

Se la tua directory home è crittografata, sshd non avrà accesso a ~ / .ssh / authorized_keys ..

Vedi questa risposta

— A priori
fonte

Perché il login automatico tramite ssh con authorized_keys non funziona?