PubkeyAuthentication

Imposta il tuo cliente

1. Genera la tua chiave
   • ssh-keygen
2. Configura ssh per usare la chiave
   • vim ~/.ssh/config
3. Copia la tua chiave sul tuo server
   • ssh-copy-id -i /path/to/key.pub SERVERNAME

Il tuo file di configurazione da passaggio 2 dovrebbe avere qualcosa di simile al seguente:

Host SERVERNAME
Hostname ip-or-domain-of-server
User USERNAME
PubKeyAuthentication yes
IdentityFile ./path/to/key

Risoluzione dei problemi

1. usa l'opzione "-vvv"
2. Assicurati che il server abbia la tua chiave pubblica (.pub).
3. Assicurati che il tuo IdentiyFile punti al tuo codice PRIVATO.
4. Assicurati che la tua directory .ssh abbia 700 e i tuoi file siano 700 permessi (rwx ------).
5. tail -f /var/log/auth.log (sul server) e monitora gli errori quando tenti di accedere

A volte il problema deriva da autorizzazioni e proprietà. Ad esempio, se si desidera accedere come root, /root , .ssh e authorized_keys devono appartenere a root. Altrimenti, sshd non sarà in grado di leggerli e quindi non sarà in grado di dire se l'utente è autorizzato ad accedere.

Nella tua directory home:

chown -R your_user:your_user .ssh

Per quanto riguarda i diritti, vai con 700 per .ssh e 600 per authorized_keys

chmod 700 .ssh
chmod 600 .ssh/authorized_keys

Non hai bisogno di authorized_keys sul tuo client.

Devi dire al client ssh di usare effettivamente la chiave che hai generato. Ci sono diversi modi per farlo. Solo per testare il tipo ssh -vvv -i .ssh/id_rsa [youruser]@[yourLinode] . Dovrai fornire la passphrase ogni volta che desideri connetterti al server.

Se hai funzionato, puoi aggiungere la chiave a ssh-agent con ssh-add .ssh/id_rsa (dovrai fornire la passphrase solo una volta per questo e dovrebbe funzionare finché non si effettua il logout / il riavvio)

Assicurati inoltre che la directory home dell'utente (sul server) appartenga effettivamente all'utente ssh'ing in (era impostata su root: root nel mio caso).

Avrebbe dovuto essere:

sudo chown username:username /home/username;

Controlla anche il valore di PasswordAuthentication in /etc/ssh/sshd_config e se è no cambialo in yes . Non dimenticare di riavviare il servizio ssh in seguito.

Il problema che ho avuto è stato l'utilizzo delle chiavi sbagliate sul client. Ho rinominato id_rsa e id_rsa.pub in qualcos'altro. Puoi rinominarli di nuovo al loro valore predefinito, oppure quando esegui il comando ssh, usalo in questo modo

ssh -i ~/.ssh/private_key [email protected]

Mi sono imbattuto recentemente in questo problema con il mio server web.

Di solito mantengo un elenco di chiavi autorizzate su tutti i miei server in ~/.ssh/authorized_keys2 . Dalla mia esperienza, sshd cercherà ~/.ssh/authorized_keys o ~/.ssh/authorized_keys2 per impostazione predefinita.

Nel caso del mio webserver, /etc/ssh/sshd_config aveva questa linea

AuthorizedKeysFile    %h/.ssh/authorized_keys

invece di

AuthorizedKeysFile    %h/.ssh/authorized_keys2

Ho applicato quest'ultimo, ho riavviato il mio demone ssh e ho risolto il problema accedendo a ssh usando il mio pubkey.

Il mio caso, il client è ubuntu 14.04lts, il server è stato win 2012 server che esegue cygwin. Stavo usando 'ssh [email protected]', quando la directory del server 2012 in cygwin era / home / Administrator. Quindi è stato case sensitive, quando ho provato 'ssh [email protected]' (notare la A maiuscola su Administrator) quindi ha funzionato bene.

Un messaggio di errore come "utente non trovato" mi avrebbe portato alla soluzione molto più rapidamente di "Autorizzazione negata (publickey, tastiera interattiva)".

Ho avuto lo stesso problema durante la copia di una chiave pubblica di un utente regolare (ad esempio johndoe) da un sistema cPanel Centos su un server Ubuntu su AWS. Come suggerito da gertvdijk qui sopra, ho controllato /var/log/auth.log e ne ho detto abbastanza Authentication refused: bad ownership or modes for directory /home/johndoe . Risulta che avevo erroneamente 777% /home/johndoe quando provavo a impostare /home/johndoe/public_html come root di documento predefinito di virtualhost per apache2 (che non è nemmeno necessario per quella attività).

Vedi anche le risposte qui e here

Il server deve avere solo la chiave pubblica in .ssh/authorized_keys e il client (il computer su cui stai lavorando) deve avere la chiave privata (.pem, o se usi SFTP con Filezilla, .ppk)

Per quegli utenti di Putty come me che sono venuti in questa discussione, potresti anche ricevere questo errore se ti sei dimenticato di aggiungere utente utente @ Ip!

Altri sono permessi sul file chiave chmod a 600)

ssh 1.1.1.1 -i /path/to/.pem file 
Permission denied (publickey).'

ssh [email protected] -i /path/to/.pem file 

Questo è quello che ha funzionato per me, la correzione non è mia, ma preferisco scriverla qui nel caso in cui qualcun altro abbia lo stesso problema.

L'autore originale lo ha pubblicato qui: digital-ocean -Pubblico-access-key-negato

sudo nano /etc/ssh/sshd_config

Sostituisci questo

UsePAM yes
IgnoreUserKnownHosts no
PasswordAuthentication no

Con questo

UsePAM no
IgnoreUserKnownHosts no
PasswordAuthentication yes

Salva il file e riavvia ssh

reload ssh

ssh dovrebbe funzionare ora chiedendo una password

Ho avuto lo stesso problema descritto nella domanda. L'output dell'esecuzione di ssh -vvv -i id_rsa [youruser]@[yourLinode] sulla macchina client è stato simile a quello descritto nella domanda. Ho controllato tutte le autorizzazioni per file e directory come consigliato nelle altre risposte, ed erano corrette.

È emerso che durante la copia del file generato id_rsa.pub sulla macchina server, come file ~username/.ssh/authorized_keys , per errore avevo omesso la parola ssh-rsa dall'inizio. L'aggiunta è stata risolta il problema.

Se tutto il resto fallisce, verificare che l'utente di accesso appartenga al Gruppo consentito di ssh. Cioè, i tuoi utenti sono membri del gruppo mostrato nella seguente riga in /etc/ssh/sshd_config sul server:

AllowGroups ssh #Here only users of 'ssh' group can login

Un'altra possibile causa potrebbe essere la configurazione AllowedUsers in /etc/ssh/sshd_conf . NOTA: l'elenco è spazio delimitato (non delimitato da virgole) man mano che apprendo nel modo più duro.

AllowUsers user1 user2 user3

Nel mio caso il problema è stato causato copiando una directory .ssh da una macchina precedente. Risulta che la mia configurazione SSH precedente utilizzava le chiavi DSA che sono state deprecate . Passare a una nuova coppia di chiavi, questa volta basata su RSA, ha risolto il problema per me.

Il seguente metodo potrebbe funzionare se è possibile accedere a machineA e machineB indipendentemente (ad esempio da machineC).

Se ssh-copy-id non funziona, l'autenticazione della password potrebbe essere disabilitata. Quanto segue è una soluzione alternativa .

Avere la chiave pubblica di machineA nelle chiavi autorizzate di machineB (ad esempio ~ / .ssh / authorized_keys) ti permetterà di ssh da machineA. Questo vale anche per SCP.

Dopo aver generato le coppie di chiavi usando: ssh-keygen

Su machineA , esegui cat ~/.ssh/id_rsa.pub

Output di esempio:

  

ssh-rsa AAAAB3NzaSGMFZW7yB [email protected]

Copia il tasto stampato ( ⌘ Comando + C o CRTL + C ) quindi aggiungilo a il file ~ / .ssh / authorized_keys su machineB .

Ad esempio, esegui quanto segue su machineB :

  

echo 'ssh-rsa AAAAB3NzaSGMFZW7yB [email protected]' >> ~/.ssh/authorized_keys

Funziona anche su Ubuntu 16.04.

Il problema è all'interno del file sshd_config

Ecco la soluzione ULTIMATE:

Accedi come root al tuo server Ubuntu

vi /etc/ssh/sshd_config

Ora vai in fondo e modifica il valore da "no" a "sì".

Dovrebbe assomigliare a questo:

Passare a no per disabilitare le password di testo in chiaro

PasswordAuthentication yes
service sshd reload

avere effetto.

Ora puoi semplicemente un tasto usando il seguente comando dal tuo computer LOCAL (noto anche come laptop ecc.)

Quindi apri una nuova finestra di terminale e NON accedi al server, metti semplicemente questo comando:

ssh-copy-id john @ serverIPAddress

(Sostituisci john con il tuo nome utente).

dovresti andare per andare