Autorizzazione SSH negata (chiave pubblica)

72

Ho provato a cercare domande precedenti per ottenere risposte alla mia domanda, ma tutte le risposte che sono state suggerite in precedenza non hanno funzionato per me.

Sto provando a connetterti a un linodo (con Ubuntu 12.04 LTS) dalla mia macchina locale (anch'esso con ubnutu 12.04 LTS)

Ho creato una chiave privata e pubblica sul mio computer locale e ho copiato la mia chiave pubblica sul file authorized_keys del mio linode. Comunque ogni volta che provo a ssh sul mio linode ottengo il messaggio di errore "Autorizzazione negata (chiave pubblica).

Non è un problema con il modo in cui ssh è impostato sul mio linodo perché posso ssh ad esso dalla mia macchina Windows usando l'autenticazione della chiave.

Nella mia directory .ssh sulla mia macchina ubuntu locale ho i miei file id_rsa e id_rsa.pub. Devo creare un file authorized_keys sul mio computer locale?

EDIT: Questo è quello che ottengo quando eseguo ssh -vvv -i id_rsa [tuuser] @ [yourLinode]

debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).
    
posta Pattle 22.06.2013 - 23:20

17 risposte

65

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
risposta data earthmeLon 23.06.2013 - 23:04
38

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
    
risposta data Buzut 15.03.2016 - 12:50
12

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)

    
risposta data guntbert 22.06.2013 - 23:42
7

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;
    
risposta data canoodle 20.04.2015 - 21:07
6

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.

    
risposta data iman 09.02.2017 - 11:11
5

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]
    
risposta data Todd 04.02.2017 - 23:28
2

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.

    
risposta data Justin C 24.11.2013 - 06:55
1

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)".

    
risposta data Kent 12.07.2016 - 04:41
1

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)

    
risposta data site80443 07.01.2017 - 22:54
1

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 
    
risposta data Alex Punnen 28.03.2017 - 13:06
1

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

    
risposta data mau 08.04.2017 - 03:25
1

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.

    
risposta data Teemu Leisti 16.05.2017 - 11:41
0

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
    
risposta data biocyberman 17.10.2014 - 08:21
0

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
    
risposta data cmbind55 03.09.2015 - 19:07
0

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.

    
risposta data Glutanimate 01.10.2017 - 22:16
0

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

    
risposta data anask 25.03.2018 - 07:11
0

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

    
risposta data Galapagos 18.07.2018 - 22:22

Leggi altre domande sui tag