Sto provando a connettermi a un Linode (con Ubuntu 12.04 LTS) dal mio computer locale (anche con Ubuntu 12.04 LTS)

Ho creato una chiave privata e pubblica sul mio computer locale e ho copiato la mia chiave pubblica nel mio file autorizzato_keys di Linode. Tuttavia, ogni volta che provo a ssh sul mio Linode ricevo il messaggio di errore Permission denied (publickey).

Non è un problema con il modo in cui ssh è impostato sul mio Linode perché posso farlo tramite il mio computer Windows usando l'autenticazione con chiave.

Nella mia .sshdirectory sulla mia macchina Ubuntu locale, ho i miei id_rsae id_rsa.pubfile. Devo creare un file authorized_keys sul mio computer locale?

EDIT: Questo è quello che ottengo quando corro ssh -vvv -i id_rsa [youruser]@[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).

PubkeyAuthentication

Configura il tuo client

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 dal 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

È possibile aggiungere IdentitiesOnly yesper assicurarsi che sshusi il file IdentityFilee nessun altro file chiave durante l'autenticazione, il che può causare problemi e non è una buona pratica.

Risoluzione dei problemi

1. usa l'opzione "-vvv"
2. Assicurati che il server abbia la tua chiave PUBLIC (.pub).
3. Assicurati che IdentiyFile punti alla tua chiave PRIVATA.
4. Assicurati che la tua directory .ssh abbia 700 e che i tuoi file siano 700 permessi (rwx ------).
5. tail -f /var/log/auth.log (sul server) e monitorare gli errori quando si tenta di accedere
6. Se si dispone di molti file chiave, provare IdentitiesOnly yesa limitare l'autenticazione per utilizzare la singola chiave specificata.

A volte il problema deriva da autorizzazioni e proprietà. Per esempio, se si vuole accedere come root, /root, .sshe authorized_keysdeve 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 home directory:

chown -R your_user:your_user .ssh

Per quanto riguarda i diritti, vai con 700 per .sshe 600 perauthorized_keys

chmod 700 .ssh
chmod 600 .ssh/authorized_keys

Non hai bisogno authorized_keyssul tuo cliente.

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

Se ciò ha funzionato, puoi aggiungere la chiave ssh-agentcon ssh-add .ssh/id_rsa(dovrai fornire la passphrase una sola volta per questo e dovrebbe funzionare finché non esci / riavvii)

Controlla anche il valore di PasswordAuthenticationin /etc/ssh/sshd_confige se lo nocambia in yes. Non dimenticare di riavviare il servizio ssh dopo quello.

Il problema che ho avuto è che stava usando le chiavi sbagliate sul client. Avevo rinominato id_rsa e id_rsa.pub in qualcos'altro. Puoi rinominarli ai loro valori predefiniti, oppure quando emetti il ​​comando ssh, usalo in questo modo

ssh -i ~/.ssh/private_key username@host

Inoltre, assicurati che la home directory dell'utente (sul server) appartenga effettivamente all'utente ssh'ing (è stato impostato su root: root nel mio caso).

Avrebbe dovuto essere:

sudo chown username:username /home/username;

Di recente ho riscontrato questo problema con il mio server Web.

Di solito tengo un elenco di chiavi autorizzate su tutti i miei server in ~/.ssh/authorized_keys2. Dalla mia esperienza, sshdcercherò ~/.ssh/authorized_keyso ~/.ssh/authorized_keys2per impostazione predefinita.

Nel caso del mio server web, /etc/ssh/sshd_configquesto aveva questa linea

AuthorizedKeysFile    %h/.ssh/authorized_keys

invece di

AuthorizedKeysFile    %h/.ssh/authorized_keys2

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

Un'altra possibile causa potrebbe essere con la AllowedUsersconfigurazione in /etc/ssh/sshd_conf. NOTA: l'elenco è delimitato da spazi (non delimitato da virgole) come ho imparato a mie spese.

AllowUsers user1 user2 user3

Se tutto il resto fallisce, controlla che il tuo utente di accesso appartenga al gruppo consentito di ssh. Cioè, i tuoi utenti sono membri del gruppo mostrato nella seguente riga /etc/ssh/sshd_configsul server:

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

Nel mio caso, il client è Ubuntu 14.04lts, il server è stato Win 2012 server con Cygwin. Stavo usando 'ssh administrator @ xxxx', quando la directory del server 2012 in cygwin era / home / Administrator. Quindi è stata la distinzione tra maiuscole e minuscole, quando ho provato 'ssh Administrator @ xxxx' (notare la maiuscola A 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 (chiave pubblica, tastiera interattiva)".

Ho avuto lo stesso problema durante la copia della chiave pubblica di un utente normale (ad es. Johndoe) da un sistema cPanel Centos su un server Ubuntu su AWS. Come suggerito da gertvdijk sopra, ho controllato /var/log/auth.loge abbastanza sicuro ha detto Authentication refused: bad ownership or modes for directory /home/johndoe. Si è scoperto che avevo sbagliato 777 /home/johndoequando ho cercato di impostare /home/johndoe/public_htmlcome root dei documenti di virtualhost predefinito per apache2 (che non è nemmeno necessario per quell'attività ).

Vedi anche le risposte qui e qui

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

Per quegli utenti Putty come me che sono venuti a questo thread, potresti anche ricevere questo errore se ti sei dimenticato di aggiungere l'utente utente @ Ip!

Altri sono i permessi sul file chiave chmod a 600)

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

ssh user@1.1.1.1 -i /path/to/.pem file 

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

L'autore originale lo ha pubblicato qui: digital-ocean-public-access-key-denied

sudo nano /etc/ssh/sshd_config

Sostituisci questo

UsePAM yes
IgnoreUserKnownHosts no
PasswordAuthentication no

Con questo

UsePAM no
IgnoreUserKnownHosts no
PasswordAuthentication yes

Salvare il file e riavviare ssh

reload ssh

ssh dovrebbe funzionare ora chiedendo una password

Ho avuto lo stesso problema descritto nella domanda. L'output dell'esecuzione ssh -vvv -i id_rsa [youruser]@[yourLinode]sul computer client era simile a quello descritto nella domanda. Ho controllato tutti i permessi di file e directory come consigliato nelle altre risposte, ed erano corretti.

Si è scoperto che durante la copia del file generato id_rsa.pubsulla macchina server, come file ~username/.ssh/authorized_keys, ho accidentalmente omesso la parola ssh-rsadall'inizio. L'aggiunta ha risolto il problema.

Funziona anche su Ubuntu 16.04.

Il problema è nel sshd_configfile

Ecco la soluzione ULTIMATE:

Accedi come root al tuo server Ubuntu

vi /etc/ssh/sshd_config

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

Dovrebbe sembrare come questo:

Passare a no per disabilitare le password di testo non crittografate

PasswordAuthentication yes
service sshd reload

avere effetto.

Ora puoi semplicemente usare un tasto usando il seguente comando dalla tua macchina LOCAL (alias laptop ecc.)

Quindi Apri la nuova finestra del terminale e NON accedere al server, inserisci semplicemente questo comando:

ssh-copy-id john @ serverIPAddress

(Sostituisci john con il tuo nome utente).

dovresti andare per andare

Alcune persone che si chiedono potrebbero aver impostato l'accesso ssh in modo che sia la chiave solo sull'account di root, quindi abbiano creato un nuovo utente e non si siano resi conto di dover

ssh root@your-ip-address

rsync --archive --chown=[user]:[user] ~/.ssh /home/[user]

logout

Quindi riprovare. Sostituisci [utente] con il tuo nuovo account utente.

Questo è comune quando si configura un nuovo server su DigitalOcean quando si sono utilizzati i tasti ssh durante l'installazione.

https://www.digitalocean.com/community/tutorials/initial-server-setup-with-ubuntu-18-04

Nel mio caso il problema è stato causato dalla copia su una .sshdirectory da una macchina più vecchia. Si scopre che la mia vecchia configurazione SSH utilizzava chiavi DSA che da allora sono state deprecate . Il passaggio a una nuova coppia di chiavi, questa volta basato su RSA, ha risolto il problema per me.

Il seguente metodo potrebbe funzionare se è possibile accedere a machineA e machineB in modo indipendente (ad es. Da machineC).

Se ssh-copy-id non funziona, l'autenticazione con password potrebbe essere disabilitata. Di seguito è una soluzione alternativa .

Avere la chiave pubblica di machineA nelle chiavi autorizzate di machineB (es. ~ / .Ssh / authorized_keys) ti permetterà di inviare ssh da machineA. Questo vale anche per scp.

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

Sulla macchina A , eseguirecat ~/.ssh/id_rsa.pub

Uscita campione:

ssh-rsa AAAAB3NzaSGMFZW7yB anask@mahineA

Copia la chiave stampata ( ⌘ Command+ Co CRTL+ C), quindi aggiungila al file ~ / .ssh / authorized_keys su machineB .

Ad esempio, eseguire quanto segue su machineB :

echo 'ssh-rsa AAAAB3NzaSGMFZW7yB anask@mahineA' >> ~/.ssh/authorized_keys