ssh richiede la password nonostante ssh-copy-id

Sto usando l'autenticazione con chiave pubblica su un server remoto da un po 'di tempo per l'uso remoto della shell e per i montaggi sshfs. Dopo aver forzato una quantità della mia directory sshfs, ho notato che ssh ha iniziato a chiedermi una password. Ho provato a eliminare il .ssh / authorized_keys remoto da qualsiasi menzione del computer locale e ho pulito il computer locale dai riferimenti al computer remoto. Ho quindi ripetuto il mio ssh-copy-id, mi ha richiesto una password e sono tornato normalmente. Ma ecco, quando invio un messaggio al server remoto mi viene ancora richiesta una password. Sono un po 'confuso su quale potrebbe essere il problema, qualche suggerimento?

sshd diventa strano riguardo alle autorizzazioni su $ HOME, $ HOME / .ssh (entrambe le directory) e su $ HOME / .ssh / authorized_keys.

Una delle mie scatole di Linux ha finito con le autorizzazioni drwxrwxrwx sulla mia directory $ HOME. Una casella Linux di Arch non accederà assolutamente usando le chiavi pubbliche fino a quando non avrò rimosso il permesso 'w' per il gruppo, altro sulla mia directory $ HOME.

Prova a rendere $ HOME e $ HOME / .ssh / avere autorizzazioni più restrittive per il gruppo e altri. Vedi se questo non consente a sshd di fare le sue cose.

Sono necessarie le seguenti autorizzazioni:

• La .sshcartella:700 (drwx------)
• La chiave pubblica: 644 (-rw-r--r--)
• La chiave privata: 600 (-rw-------)

Di recente ho riscontrato anche questo problema.

È stato corretto modificando le autorizzazioni della $HOMEdirectory. Tuttavia, la semplice esecuzione chmod g-w ~/non ha risolto il problema. Oltre a chmod g-w ~/ho anche bisogno di modificare le autorizzazioni di otherssulla $HOMEdirectory eseguendochmod o-wx ~/

Insieme:

chmod g-w ~/
chmod o-wx ~/

Nota che non sono sicuro che o-xfosse necessario, l'ho semplicemente eseguito per precauzione.

La modifica delle autorizzazioni per la cartella ~ / .ssh ha risolto il mio problema in base a questo post su Super User SE .

Il problema si verifica anche con accessi paralleli, ovvero se si tenta di montare sshfs mentre si ha una sessione ssh aperta? In caso contrario, immagino che tu abbia la tua directory home crittografata? In questo caso $HOME/.ssh/authorized_keysdiventerebbe utilizzabile sul computer remoto solo dopo il primo accesso (utilizzando la password).

Controlla https://help.ubuntu.com/community/SSH/OpenSSH/Keys#Tro risoluzione dei problemi per una spiegazione e la soluzione alternativa richiesta.

Pubblicherei questo come commento, ma probabilmente sarebbe troppo lungo. Volevo solo aggiungere che ssh-copy-idtenta di inviare la chiave pubblica dalla /.sshposizione all'interno della $HOMEcartella.

Se si sta tentando di eseguire sshil root come chiave pubblica (salvare i commenti relativi alla sicurezza), è ssh-copy-idpossibile che si stia tentando di accedere con la chiave pubblica errata se la $HOMEvariabile è impostata su un valore diverso da /root(ad esempio, essere impostata sulla home directory dell'utente normale ), pertanto all'utente root verrà richiesto perché la chiave pubblica di root non è installata sul sistema remoto.

È possibile utilizzare il seguente one-liner per specificare la chiave pubblica esatta:

pub="$(cat /root/.ssh/id_rsa.pub)"; ssh user@remotehost "echo $pub >> .ssh/authorized_keys; chmod 700 .ssh; chmod 600 .ssh/authorized_keys"

Ho incontrato questo scenario in natura alcune volte (compresa questa mattina) e ho pensato che avrei provato a mettere i miei 2 centesimi, nel caso in cui qualcuno si fosse trovato nella stessa situazione.

Come altri collaboratori citati, questo è probabilmente un problema di autorizzazione.

Il modo migliore per diagnosticare questo è riavviare il demone SSH sul server remoto con l'opzione di debug attiva - di solito l'opzione "-d". Il messaggio del demone OpenSSH è molto esplicito. Ad esempio, vedrai messaggi come:

Authentication refused: bad ownership or modes for directory /some/path

Il motivo per cui la chiave pubblica non sopravviveva dopo il riavvio era che la directory principale del mio server era crittografata. (lo fai durante l'installazione del server)

Un altro possibile problema è che il server non supporta l'algoritmo chiave. Nel mio caso, ho trovato i seguenti messaggi nei miei sshdregistri ( /var/log/auth.lognel mio caso):

userauth_pubkey: unsupported public key algorithm: ssh-ed25519 [preauth]

Se questo è il caso, vi sia bisogno di abilitare il supporto per tale algoritmo nella sshdconfigurazione (che potrebbe richiedere un aggiornamento ad una più recente sshdversione) oppure è necessario passare la vostra chiave per un algoritmo supportato dal sshdsi sta cercando di connettersi a .

Poiché questa domanda appare tra i primi risultati della ricerca quando si cerca su Google questo comportamento, aggiungerò anche la mia soluzione:

Nel mio caso non era nulla legato alle autorizzazioni. Per qualsiasi motivo (non mi sono preoccupato di scoprire per quale motivo in realtà, poiché ho trovato una soluzione rapida) durante l'esecuzione del comando ssh il programma non ha cercato il file di identità corretto. Una soluzione era aggiungere manualmente sul server remoto una chiave SSH che il programma SSH ha tentato di utilizzare. È possibile osservare cosa fa il programma SSH quando si esegue il comando aggiungendo -v al comando:

ssh -v username@your-host-ip-or-domain 

Quindi prendi sul tuo computer locale qualsiasi chiave pubblica per la quale il programma SSH prova a trovare un file di identità / chiave privata, ad esempio su un Mac:

cat ~/.ssh/id_rsa.pub

... e aggiungilo al file authorized_keys del telecomando in:

~/.ssh/authorized_keys

Un'altra, nel mio caso, la soluzione migliore era quella di aggiungere un host personalizzato nel mio file di configurazione ssh locale. Sul mio Mac è:

/Users/my-user-name/.ssh/config

Qui puoi aggiungere ad esempio qualcosa del genere:

Host mynewserver
        HostName some.IP.number.or.domain
        Port 20000 #if custom port is used and not the default 22
        User the_root
        PreferredAuthentications publickey
        IdentityFile ~/.ssh/id_rsa_for_my_new_server

Quindi devi solo eseguire:

ssh mynewserver

... e Voilà