ATTENZIONE: FILE CHIAVE PRIVATO NON PROTETTO! quando si tenta di SSH nell'istanza Amazon EC2


190

Sto lavorando per configurare Panda su un'istanza Amazon EC2. Ieri sera ho configurato il mio account e i miei strumenti e non ho avuto problemi a utilizzare SSH per interagire con la mia istanza personale, ma in questo momento non mi è stato permesso il permesso nell'istanza EC2 di Panda. Introduzione a Panda

Ricevo il seguente errore:

@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @

Permissions 0644 for '~/.ec2/id_rsa-gsg-keypair' are too open.
It is recommended that your private key files are NOT accessible by others.
This private key will be ignored.

Ho modificato la mia coppia di chiavi a 600 per entrare nella mia istanza personale ieri sera, e ho sperimentato a lungo impostando le autorizzazioni su 0 e persino generando nuove stringhe di chiavi, ma nulla sembra funzionare.

Qualsiasi aiuto sarebbe di grande aiuto!


Hm, sembra che a meno che le autorizzazioni non siano impostate su 777 nella directory, lo script ec2-run-instance non è in grado di trovare i miei file di chiavi. Sono nuovo di SSH, quindi potrei trascurare qualcosa.


Le istanze di ec2-run dovrebbero richiedere solo un nome di coppia di chiavi, che è qualcosa che vive dalla parte di Amazon. Dovresti usare la tua vera chiave privata (quella su disco) solo quando entri in SSH. Che errore ricevi dalle istanze ec2-run?
user27619

3
titolo terribile per questa domanda.
MikeNereson,

2
@MikeNereson: sentiti libero di modificarlo, ecco come miglioriamo le cose qui
Stu Thompson,

Sei sicuro di averlo impostato su 0600 (ottale) e non su 600 (decimale)?
hyde,

5
chmod 400 ~/.ssh/id_rsa Riferimento: stackoverflow.com/a/9270753/2082569
atulkhatri

Risposte:


210

Ho modificato la mia coppia di chiavi a 600 per entrare nella mia istanza personale ieri sera,

E questo è il modo in cui dovrebbe essere.

Dalla documentazione EC2 abbiamo "Se stai usando OpenSSH (o qualsiasi client SSH ragionevolmente paranoico) allora probabilmente dovrai impostare le autorizzazioni di questo file in modo che sia leggibile solo da te." La documentazione di Panda che colleghi ai collegamenti alla documentazione di Amazon, ma in realtà non trasmette quanto sia importante tutto.

L'idea è che i file delle coppie di chiavi siano come password e debbano essere protetti. Quindi, il client ssh che stai usando richiede che quei file siano protetti e che solo il tuo account li possa leggere.

L'impostazione della directory su 700 dovrebbe davvero essere sufficiente, ma 777 non farà male finché i file saranno 600.

Eventuali problemi si verificano sul lato client, quindi assicurati di includere le informazioni sul sistema operativo locale con eventuali domande di follow-up!


3
Mi sono appena trovato in una situazione in cui VOGLIO che il file di chiavi sia leggibile in gruppo (usando ssh non per l'accesso personale, ma per eseguire uno script su un server remoto, utente dedicato sul server remoto per questo scopo, chiavi_utente bloccate così solo detto script verrà eseguito e più persone sul server di origine dovrebbero avere accesso per eseguire lo script). Vabbè, suppongo che la semplice soluzione alternativa sia quella di mettere copie in ~ / .ssh / per tutti gli utenti che dovrebbero avere accesso - o popolare le chiavi autorizzate con tutte le chiavi personali.
tobixen,

@tobixen: Tra due anni, ma ... la soluzione "corretta" sarebbe quella di posizionare la chiave in un utente dedicato e consentire agli utenti del gruppo di accedere su tale comando come utente dedicato.
Stu Thompson,

Il link @StuThompson alla documentazione EC2 sembra essere morto. Puoi aggiornare per favore?
Aniket Thakur,

Non riesco a vedere cosa devo fare per farlo funzionare nella tua risposta, per favore fornisci la risposta :)
Pratik

L'impostazione di @Pratik 600 per entrambi i file chiave e 777 per la directory dovrebbe funzionare.
Jamo

55

Assicurarsi che la directory contenente i file della chiave privata sia impostata su 700

chmod 700 ~/.ec2

Qualche motivo speciale per cui si desidera avere i privilegi di esecuzione sul file?
Zoltán,

1
@ Zoltán è una directory, non un file.
avmohan,

Ho appena usato questo nel file .pem e ha funzionato per me.
CGTheLegend,

30

Per risolvere questo problema, 1) dovrai ripristinare le autorizzazioni ai valori predefiniti:

sudo chmod 600 ~/.ssh/id_rsa sudo chmod 600 ~/.ssh/id_rsa.pub

Se ricevi un altro errore: sei sicuro di voler continuare a connetterti (sì / no)? sì Impossibile aggiungere l'host all'elenco di host noti (/home/geek/.ssh/known_hosts).

2) Ciò significa che anche le autorizzazioni per quel file sono impostate in modo errato e possono essere regolate con questo:

sudo chmod 644 ~/.ssh/known_hosts

3) Infine, potrebbe essere necessario modificare anche le autorizzazioni della directory:

sudo chmod 755 ~/.ssh

Questo dovrebbe farti tornare in esecuzione.


17

Il file della chiave privata deve essere protetto. Nel mio caso uso l'autenticazione public_key da molto tempo e ho usato l'autorizzazione come 600 (rw- --- ---) per la chiave privata e 644 (rw- r-- r--) e per nella cartella .ssh nella cartella home avrai 700 permessi (rwx --- ---). Per impostare questo vai nella cartella principale dell'utente ed esegui il seguente comando


Impostare l' autorizzazione 700 per la cartella .ssh

chmod 700 .ssh


Imposta l' autorizzazione 600 per il file della chiave privata

chmod 600 .ssh/id_rsa


Impostare l' autorizzazione 644 per il file della chiave pubblica

chmod 644 .ssh/id_rsa.pub


2

Conserva la tua chiave privata, chiave pubblica, known_hosts nella stessa directory e prova ad accedere come di seguito:

ssh -I(small i) "hi.pem" ec2-user@ec2-**-***-**-***.us-west-2.compute.amazonaws.com
  • Stessa directory in senso, cd /Users/prince/Desktop. Ora digita lscommand e dovresti vedere **.pem **.ppk known_hosts

Nota: devi provare ad accedere dalla stessa directory o riceverai un errore di autorizzazione negata in quanto non riesce a trovare il file .pem dalla tua directory attuale.


Se vuoi essere in grado di SSH da qualsiasi directory, puoi aggiungere quanto segue al tuo ~/.ssh/configfile ...

Host your.server
HostName ec2-user@ec2-**-***-**-***.us-west-2.compute.amazonaws.com
User ec2-user
IdentityFile ~/.ec2/id_rsa-gsg-keypair
IdentitiesOnly yes

Ora puoi SSH sul tuo server indipendentemente da dove si trovi la directory semplicemente digitando ssh your.server(o qualunque nome tu inserisca dopo "Host").


1

Su Windows, prova a usare git bash e usa i tuoi comandi Linux lì. Approccio semplice

chmod 400 *****.pem

ssh -i "******.pem" ubuntu@ec2-11-111-111-111.us-east-2.compute.amazonaws.com

Se usi WSL, assicurati di copiare il file pem in una cartella Linux perché chmod non sarà efficace nelle directory / mnt.
Paulo Merson,

1

Modificare l'autorizzazione del file usando il comando chmod

sudo chmod 700 keyfile.pem

0

Sto pensando a qualcos'altro, se stai provando ad accedere con un nome utente diverso che non esiste questo è il messaggio che riceverai.

Quindi suppongo che potresti provare a ssh con ec2-user ma ricordo di recente la maggior parte delle AMI di centos, ad esempio, usano centos user invece di ec2-user

quindi, per ssh -i file.pem centos@public_IPfavore, dimmi che stai scrivendo a ssh con il nome utente giusto, altrimenti questo potrebbe essere un motivo forte per cui vedi questo messaggio di errore anche con le giuste autorizzazioni sul tuo ~ / .ssh / id_rsa o file.pem


0

Solo una nota per chiunque si imbatte in questo:

Se stai provando a SSH con una chiave che è stata condivisa con te, ad esempio:

ssh -i /path/to/keyfile.pem user@some-host

Dov'è keyfile.pemla chiave privata / pubblica condivisa con te e la stai usando per connetterti, assicurati di salvarla in ~/.ssh/e chmod 777.

Cercare di usare il file quando è stato salvato altrove sulla mia macchina stava dando l'errore dell'OP. Non sono sicuro che sia direttamente correlato.


0

La soluzione è renderlo leggibile solo dal proprietario del file, ovvero le ultime due cifre della rappresentazione della modalità ottale dovrebbero essere zero (es. Mode 0400 ).

OpenSSH controlla questo authfile.c, in una funzione chiamata sshkey_perm_ok:

/*
 * if a key owned by the user is accessed, then we check the
 * permissions of the file. if the key owned by a different user,
 * then we don't care.
 */
if ((st.st_uid == getuid()) && (st.st_mode & 077) != 0) {
    error("@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@");
    error("@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @");
    error("@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@");
    error("Permissions 0%3.3o for '%s' are too open.",
        (u_int)st.st_mode & 0777, filename);
    error("It is required that your private key files are NOT accessible by others.");
    error("This private key will be ignored.");
    return SSH_ERR_KEY_BAD_PERMISSIONS;
}

Vedi la prima riga dopo il commento: fa un "bit per bit e" contro la modalità del file, selezionando tutti i bit nelle ultime due cifre ottali (poiché 07è ottale per 0b111, dove ogni bit sta per r / w / x, rispettivamente) .

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.