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

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.

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!

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

chmod 700 ~/.ec2

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.

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

Ho anche avuto lo stesso problema, ma lo risolvo cambiando l'autorizzazione del mio file chiave in 600.

sudo chmod 600 /path/to/my/key.pem

Link: http://stackabuse.com/how-to-fix-warning-unprotected-private-key-file-on-mac-and-linux/

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

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

Modificare l'autorizzazione del file usando il comando chmod

sudo chmod 700 keyfile.pem

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

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.

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