Perché ricevo "Autorizzazione negata (chiave pubblica)" quando provo a SSH da Ubuntu locale a un server Amazon EC2?

Ho un'istanza di un'applicazione in esecuzione nel cloud sull'istanza di Amazon EC2 e devo collegarla dal mio Ubuntu locale. Funziona bene su uno di Ubuntu locale e anche laptop. Ho ricevuto il messaggio "Autorizzazione negata (chiave pubblica)" durante il tentativo di accedere a SSH su EC2 su un altro Ubuntu locale. È così strano per me.

Sto pensando a una sorta di problemi con le impostazioni di sicurezza su Amazon EC2 che ha un accesso IP limitato a un'istanza o potrebbe essere necessario rigenerare un certificato.

Qualcuno conosce una soluzione?

La prima cosa da fare in questa situazione è usare l' -vopzione ssh, in modo da poter vedere quali tipi di autenticazione vengono provati e quali sono i risultati. Questo aiuta a illuminare la situazione?

Nel tuo aggiornamento alla tua domanda, menzioni "su un altro Ubuntu locale". Hai copiato sulla chiave privata ssh sull'altra macchina?

Poiché non è stato esplicitamente menzionato, sshd è di default molto severo per quanto riguarda le autorizzazioni per i authorized_keysfile. Quindi, se authorized_keysè scrivibile per qualcuno diverso dall'utente o può essere reso scrivibile da chiunque diverso dall'utente, rifiuterà di autenticarsi (a meno che non sia configurato con sshd StrictModes no)

Ciò che intendo per "può essere reso scrivibile" è che se una qualsiasi delle directory principali è scrivibile per chiunque non sia l'utente, gli utenti autorizzati a modificare tali directory possono iniziare a modificare le autorizzazioni in modo tale da poter modificare / sostituire le chiavi autorizzate.

Inoltre, se la /home/username/.sshdirectory non è di proprietà dell'utente e quindi l'utente non dispone delle autorizzazioni per leggere la chiave, è possibile riscontrare problemi:

drwxr-xr-x 7 jane jane 4096 Jan 22 02:10 /home/jane
drwx------ 2 root root 4096 Jan 22 03:28 /home/jane/.ssh

Nota che jane non possiede il .sshfile. Correggi tramite

chown -R jane:jane /home/jane/.ssh

Questo tipo di problemi con le autorizzazioni del filesystem non verranno visualizzati ssh -ve non verranno nemmeno visualizzati nei registri sshd (!) Fino a quando non imposterai il livello di registro su DEBUG.

• Modifica /etc/ssh/sshd_config. Vuoi una riga che legga LogLevel DEBUGlì da qualche parte. Ricarica il server SSH usando il meccanismo fornito dalla distribuzione. ( service sshd reloadsu RHEL / CentOS / Scientific.) Un caricamento grazioso non eliminerà le sessioni esistenti.
• Prova a eseguire nuovamente l'autenticazione.
• Scopri dove vanno i log della tua struttura di autenticazione e leggili. (IIRC, /var/log/auth.logsu distribuzioni basate su Debian; /var/log/securesu RHEL / CentOS / Scientific.)

Molto più facile capire cosa non va nell'output di debug che include errori di autorizzazione del filesystem. Ricorda di ripristinare la modifica al /etc/ssh/sshd_configtermine!

Ho ricevuto questo errore, perché ho dimenticato di aggiungere l' -lopzione. Il mio nome utente locale non era lo stesso del sistema remoto.

Questo non risponde alla tua domanda, ma sono arrivato qui alla ricerca di una risposta al mio problema.

Ho ricevuto questo messaggio su una nuova istanza basata sull'AMI di Ubuntu. Stavo usando l'opzione -i per fornire il PEM ma mostrava ancora "Autorizzazione negata (chiave pubblica)".

Il mio problema era che non stavo usando l'utente corretto. Eseguendo ssh con ubuntu @ ec2 ... ha funzionato normalmente.

Qualcosa che è più facile da leggere di ssh -v(secondo me ovviamente), lo è tail -f /var/log/auth.log. Dovrebbe essere eseguito sul server a cui si sta tentando di connettersi, mentre si tenta di connettersi. Mostrerà errori in testo normale.

Questo mi ha aiutato a risolvere il mio problema:

Utente [nome utente] da xx.yy.com non consentito poiché nessuno dei gruppi di utenti è elencato in AllowGroups

Controlla il tuo file / etc / ssh / sshd_config . Lì, trova la linea che dice

PasswordAuthentication no

Quella riga deve essere modificata per dire sì anziché no. Inoltre, riavviare il server sshd in seguito.

sudo /etc/init.d/ssh restart

Forse non è rilevante per l'attuale poster, ma potrebbe aiutare gli altri a trovarlo quando cercano risposte a situazioni simili. Invece di consentire ad Amazon di generare la coppia di chiavi ssh, ti consiglio di caricare su Amazon la tua chiave ssh pubblica standard, standard, specificando che quando esegui un'istanza EC2.

Ciò consente di rilasciare la sintassi di tipo "-i" in ssh, utilizzare rsync con opzioni standard e anche di utilizzare la stessa chiave ssh in tutte le regioni EC2.

Ho scritto un articolo su questo processo qui:

Caricamento delle chiavi SSH personali su Amazon EC2
http://alestic.com/2010/10/ec2-ssh-keys

Stranamente, il mio problema si è rivelato essere che il server era stato riavviato ed è stato emesso un nuovo nome DNS. Stavo usando il vecchio nome DNS. So che sembra stupido, ma mi ci è voluto un po 'per capirlo.

Se stai provando a connetterti a un telefono CyanogenMod con Dropbear, dovresti eseguire le seguenti linee per assicurarti che tutto sia a posto:

chmod 600 /data/dropbear/.ssh/authorized_keys

o

chmod 700 /data/dropbear/.ssh/authorized_keys # In case of MacOS X 10.6-10.8

e

chmod 755 /data/dropbear/ /data/dropbear/.ssh

Questo mi ha risolto, altrimenti niente può connettersi.

Se stai usando CentOS 5, si consiglia di impostare StrictModes noin /etc/ssh/sshd_config. Sto condividendo la directory / home usando NIS / NFS e ho impostato tutte le autorizzazioni correttamente, ma mi ha sempre richiesto la password. Dopo aver impostato StrictModes no, il problema è scomparso!

La risposta di Greg spiega come risolvere meglio i problemi, tuttavia il vero problema è che hai impostato una chiave ssh su un lato della transazione (il client), che sta tentando l'autenticazione con chiave pubblica anziché l'autenticazione basata su password. Dato che non hai la chiave pubblica corrispondente sull'istanza EC2, questo non funzionerà.

Ho avuto lo stesso problema e, dopo aver provato tonnellate di soluzioni che non funzionavano, ho aperto la porta SSH sul firewall del mio router (il pannello di controllo del firewall del mio router è un casino, quindi è difficile dire cosa sta succedendo). Comunque, questo l'ha risolto :)

Super fastidiosamente fastidioso che l'errore che ricevi sia Autorizzazione negata, il che implica che è stato fatto un qualche tipo di connessione, GRR.

Stavo avendo lo stesso problema anche se presumibilmente stavo seguendo tutti i passaggi inclusi

$ ec2-authorize default -p 22

Tuttavia, avevo iniziato la mia istanza nella regione us-west-1. Quindi il comando sopra dovrebbe anche specificare quello.

$ ec2-authorize default -p 22 --region us-west-1

Dopo questo comando sono stato in grado di scrivere nell'istanza. Ho trascorso un po 'di tempo prima di rendermi conto del problema e spero che questo post aiuti gli altri.

Questo è un caso raro, ma se hai selinux abilitato e stai usando nfs per la directory con le directory_autorizzazione (ad es. Directory home condivise), dovrai disabilitare selinux (non raccomandato per motivi di sicurezza, ma puoi disabilitarlo temporaneamente per vedere se questo sta causando il problema) o consentire a selinux di usare le directory home di nfs. Non sono chiaro sui dettagli, ma questo ha funzionato per me setsebool -P use_nfs_home_dirs 1

Ho appena riscontrato lo stesso problema dopo aver aggiunto inavvertitamente le autorizzazioni di scrittura di gruppo alla home directory degli utenti.

Ho scoperto che questa era la causa eseguendo tail -f /var/log/securesulla macchina e vedendo l'errore Authentication refused: bad ownership or modes for directory /home/<username>.