ATTENZIONE: FILE CHIAVE PRIVATO NON PROTETTO! quando si tenta di SSH nell'istanza Amazon EC2
-
03-07-2019 - |
Domanda
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.
Soluzione
Ho modificato la mia coppia di chiavi a 600 per entrare nella mia istanza personale ieri sera
Ed è così che dovrebbe essere.
Dalla documentazione EC2 abbiamo " ; Se stai utilizzando OpenSSH (o qualsiasi client SSH ragionevolmente paranoico), probabilmente dovrai impostare le autorizzazioni di questo file in modo che sia leggibile solo da te. & Quot; La documentazione di Panda a cui rimandate si collega a collegamenti La 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!
Altri suggerimenti
Assicurati 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 modificate 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 impostarlo vai nella cartella principale dell'utente ed esegui il seguente comando
Imposta 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
Imposta 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/
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
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 nel senso,
cd / Users / prince / Desktop
. Ora digita il comandols
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 file ~ / .ssh / config
...
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 sia il nome che inserisci dopo " Host ").
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 se lo sei
ssh -i file.pem centos @ public_IP
per favore 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
Dove keyfile.pem
è la chiave privata / pubblica condivisa con te e la stai usando per connetterti, assicurati di salvarla in ~ / .ssh /
e chmod 777
.
Il tentativo di utilizzare il file quando è stato salvato altrove sul mio computer stava dando l'errore dell'OP. Non sono sicuro che sia direttamente correlato.