Chiave SSH accettata dall'host ma disconnessione del client

Helo,

Ho un problema con SSH dopo l'installazione di fedora 23.

Quando non voglio collegarmi al mio host remoto con chiave privata, il mio host trova la chiave:

debug1: matching key found: file /home/theo/.ssh/authorized_keys, line 1 RSA {REDACTED}
debug1: restore_uid: 0/0
Postponed publickey for theo from {REDACTED} port 60351 ssh2 [preauth]
Connection closed by {REDACTED} [preauth]
debug1: do_cleanup [preauth]
debug1: monitor_read_log: child log fd closed

Ma come vedi il mio cliente disconnettersi da solo

debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/tbouge/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 1047
debug2: input_userauth_pk_ok: fp SHA256:{REDACTED}
debug3: sign_and_send_pubkey: RSA SHA256:{REDACTED}
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).

Posso connettermi al mio host con putty su Windows usando la stessa chiave privata e posso connettermi con il mio telefono usando una chiave privata diversa.

Hai qualche idea ?

/ Etc / ssh / ssh_conf

Host *
        GSSAPIAuthentication yes
# If this option is set to yes then remote X11 clients will have full access
# to the original X11 display. As virtually no X11 client supports the untrusted
# mode correctly we set this to yes.
        ForwardX11Trusted yes
# Send locale-related environment variables
        SendEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
        SendEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
        SendEnv LC_IDENTIFICATION LC_ALL LANGUAGE
        SendEnv XMODIFIERS

Grazie

Modifica: posso collegarmi con una password

Innanzitutto, sono disponibili online numerosi documenti dettagliati, molto ben scritti, su come impostare o configurare l'autenticazione basata su chiave pubblica . Dai un'occhiata a uno di questi e vedi se hai seguito tutto correttamente. Eccone uno. Quindi non lo ripeterò più.

Il concetto di base è (copiato da qui ):

L'autenticazione basata su chiave utilizza due chiavi, una chiave "pubblica" che chiunque può vedere e un'altra chiave "privata" che solo il proprietario può vedere. Per comunicare in modo sicuro utilizzando l'autenticazione basata su chiave, è necessario creare una coppia di chiavi, archiviare in modo sicuro la chiave privata sul computer da cui si desidera accedere e archiviare la chiave pubblica sul computer a cui si desidera accedere.

Ora dal registro di debug hai pubblicato:

• Sembra che siano coinvolti due diversi utenti. /home/theo/.ssh/authorized_keyse /home/tbouge/.ssh/id_rsa. Stai tentando di accedere come utente alla home directory di un altro utente?
• L'errore di Postponed publickey for theo..metodo di autenticazione indesiderato mezzi sono stati provati prima di metodo di chiave pubblica. SSH proverà tutti i metodi di autenticazione abilitati in config, uno dopo l'altro. Nel tuo caso hai GSSAPIAuthentication yesabilitato ciò che non stai utilizzando. Puoi disabilitarlo in sicurezza facendo GSSAPIAuthentication no.
• debug2: we did not send a packet, disable methodè molto probabile che non sia in grado di elaborare il file della chiave privata (autorizzazione del file o problema con il nome). SSH è molto sensibile alle autorizzazioni di directory e file sia nei computer locali che in quelli remoti. ( chown user_name:user_group -R /home/user, chmod 700 /home/.ssh, chmod 600 /home/.ssh/authorized_keys). Quindi, assicurati che i tuoi siano impostati correttamente. Vedi questo: /unix/131886/ssh-public-key-wont-send-to-server

• Per quanto riguarda il terzo errore: Permission denied (public key).ci sono un paio di cose da controllare.

  • Username sbagliato
  • Coppia di chiavi sbagliata

  • Host di destinazione errato

    • Ecco ulteriori dettagli: /programming/18551556/permission-denied-publickey-when-ssh-access-to-amazon-ec2-instance .

La parte seguente è un po 'confusa:

debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 1047
debug2: input_userauth_pk_ok: fp SHA256:{REDACTED}
debug3: sign_and_send_pubkey: RSA SHA256:{REDACTED}
debug2: we did not send a packet, disable method

Per capirlo meglio, seguiamo il processo di autenticazione passo dopo passo, come descritto qui su digitalocean :

1. Il client inizia inviando un ID per la coppia di chiavi con cui desidera autenticarsi al server.
2. Il server controlla il file authorized_keys dell'account a cui il client sta tentando di accedere per l'ID chiave.
3. Se nel file viene trovata una chiave pubblica con ID corrispondente, il server genera un numero casuale e utilizza la chiave pubblica per crittografare il numero.
4. Il server invia al client questo messaggio crittografato.
5. Se il client ha effettivamente la chiave privata associata, sarà in grado di decrittografare il messaggio utilizzando quella chiave, rivelando il numero originale.
6. Il client combina il numero decrittografato con la chiave di sessione condivisa utilizzata per crittografare la comunicazione e calcola l'hash MD5 di questo valore.
7. Il client quindi invia questo hash MD5 al server come risposta al messaggio numerico crittografato.
8. Il server utilizza la stessa chiave di sessione condivisa e il numero originale che ha inviato al client per calcolare da solo il valore MD5. Confronta il proprio calcolo con quello che il cliente ha rispedito. Se questi due valori corrispondono, si dimostra che il client era in possesso della chiave privata e il client è autenticato.

Nel tuo caso, come puoi vedere, il computer remoto ha accettato solo il tuo public key, ha crittografato il pacchetto con quella chiave e lo ha rispedito al computer client. Ora il computer client deve dimostrare di avere il diritto private key. Con solo la giusta chiave privata può decifrare il messaggio ricevuto e rispedire una risposta. In questo caso, il client non riesce a farlo e il processo di autenticazione termina senza successo.

Spero che questo ti aiuti a capire i problemi e risolverli.

I privilegi sui tuoi file ssh sono corretti?

Cartella .ssh -> 700

chiave pubblica -> 644

chiave privata -> 600

Controlla anche utente e gruppo

Dici di avere la stessa chiave su una macchina Windows; sei sicuro che il file della chiave privata che hai sulla tua macchina Linux sia corretto? Forse la chiave privata è in un formato putty che ssh non capisce facilmente. In ogni caso, se inserisco un file di chiave privata errato o non valido, visualizzo esattamente lo stesso errore che hai.

Per correggere il problema, sarebbe più appropriato generare una nuova chiave sulla macchina Linux invece di riutilizzare una chiave da un'altra macchina. Puoi semplicemente aggiungere la nuova chiave pubblica al file authorized_keys sull'host, quindi puoi usare sia la chiave Windows di Windows sia la nuova chiave Linux di Fedora.

il tuo problema sembra essere abbastanza comune e anche chiaro che ho detto.

 Permission denied (publickey).

questo significa qualcosa per te? per me significa molto per me.

puoi controllare sul lato server se hai selinux in esecuzione in modalità forzata pls? in caso contrario dimmi a che modalità è in esecuzione selinux.

Inoltre, se puoi fare un altro tentativo e acquisire i registri di controllo di quel tentativo e pubblicare qui ci dirà sicuramente perché:

  tail -f /var/log/audit/audit.log  (and try to attempt)

È un problema di autorizzazione che è chiaro ma non l'autorizzazione del file :-)

Sembra che il problema (nel mio caso ...) sia stato causato dal tipo di chiave.

Ho appena risolto aggiungendo quanto segue al ~/.ssh/configfile locale (la macchina client Fedora 23):

PubkeyAcceptedKeyTypes=+ssh-dss

Anche se ho aggiunto quella linea sia al server che al file di configurazione del client, solo il lato client ha fatto la differenza. Si noti che le autorizzazioni devono essere necessarie 600per la lettura del file di configurazione.

Non so se qualcun altro abbia ancora questo problema, ma alla fine l'ho risolto per il mio unico computer (un laptop) che stava riscontrando il problema. Io credo che so quello che alla fine ha risolto, e lascio le info qui nella speranza che possa aiutare chiunque altro possa essere ancora incontrare questo - e anche in modo che qualcuno possa auspicabilmente controllare la mia soluzione e confermare che è in realtà ciò che problema risolto.

Il problema, a quanto pare, non era affatto (per me) con SSH, ma con come PAM stava configurando le mie chiavi. La configurazione non /etc/pam.dera aggiornata (anche se funzionava correttamente tramite Fedora 22) e, di conseguenza, non venivano fatte le cose corrette all'accesso [più] per ritirare le mie chiavi $HOME/.ssh/. Eseguendo questo comando:

# sudo authconfig --updateall

ricostruita correttamente la configurazione /etc/pam.d. Al riavvio successivo, dopo aver effettuato l'accesso, la prima volta che ho provato a eseguire l'shsh sul mio server, una finestra di dialogo mi ha chiesto di inserire la mia passphrase per la mia chiave ssh ( $HOME/.ssh/id_rsa). L'ho fatto, ho selezionato la casella "Sblocca automaticamente all'accesso" e voilà! La mia capacità di uscire dal laptop è stata ripristinata.

sfondo

L'indizio che mi ha portato a risolvere questo problema è arrivato quando ho importato una chiave RSA da una fonte esterna. (Una chiave USB mi porto dietro, con la mia chiave "accesso remoto" per la mia rete domestica. Ho spento PasswordAuth ai miei anni di server rivolte verso l'esterno fa dopo un'intrusione.) Dopo ssh-add-ing CHE chiave RSA, a differenza di quello seduto in $HOME/.ssh/id_rsa, è stato accettato dal server remoto senza problemi.

Poi ho finito per fare quello che avrebbe dovuto essere un ridondante ssh-add, per raccogliere $HOME/.ssh/id_rsa. Ho notato che dopo averlo fatto, ssh-add -lconteneva due voci per la stessa chiave:

% ssh-add -l
2048 SHA256:XXXXXXXXXXXXXXXXXXXXXX id_rsa (RSA)
2048 SHA256:XXXXXXXXXXXXXXXXXXXXXX me@host (RSA)
2048 SHA256:YYYYYYYYYYYYYYYYYYYYYY imported@usbkey (RSA)

Nota come una delle due voci non mostra l'identificatore della chiave, ma solo il nome del file della chiave privata corrispondente alla sua firma pubblica. Come se la chiave privata non fosse stata davvero sbloccata dal gestore dei portachiavi.

Credo che sia esattamente quello che stava succedendo e PAM stava passando "chiavi errate" all'agente SSH che non era stato sbloccato con la passphrase. Quindi, quando ssh ha tentato di autenticarsi con la chiave, in realtà non aveva la metà privata (sbloccata) della coppia di chiavi, quindi l'autenticazione non è riuscita.

L'ultimo bit è congettura, ma indipendentemente dal fatto che qualcuno abbia problemi con le chiavi ssh non accettate dagli host remoti (dove erano prima) dopo l'aggiornamento a F23, vale la pena provare a ricostruire la /etc/pam.d/directory usando authconfiguna soluzione.

Controlla le autorizzazioni della home directory dell'utente. È importante. Deve essere 755. 700 o 770 non funzioneranno.

Nella tua ssh_config, provare decommentando e / o l'aggiunta / rimozione / aggiungendo sia al Cipher, Cipherso MACsla linea (s).

Mi sembra che sshdstia cercando un particolare codice di qualche tipo che non viene incluso nella richiesta, che può essere aggiunto configurandolo nel tuo ssh_config.

... e presumo che non ti sia mai stato PubkeyAuthenticationimpostato nosul server remoto, perché ciò provocherebbe sicuramente un errore.