scp (copie sécurisée) à ec2 instance sans mot de passe
j'ai une instance EC2 en cours d'exécution (FreeBSD 9 AMI ami-8cce3fe5), et je peux m'y connecter en utilisant mon fichier clé créé par amazon sans demander de mot de passe, pas de problème.
cependant, lorsque je veux copier un fichier vers l'instance en utilisant scp, je suis invité à entrer un mot de passe:
scp somefile.txt -i mykey.pem root@my.ec2.id.amazonaws.com:/
Password:
des idées pourquoi cela se produit et comment il peut être empêché?
12 réponses
j'ai compris. J'ai eu les arguments dans le mauvais ordre. Cela fonctionne:
scp -i mykey.pem somefile.txt root@my.ec2.id.amazonaws.com:/
scp -i /path/to/your/.pemkey -r /copy/from/path user@server:/copy/to/path
scp -i ~/.ssh/key.pem ec2-user@ip:/home/ec2-user/file-to-copy.txt .
le nom du fichier ne doit pas se trouver entre le fichier pem et la chaîne ec2-user - that doesnt work. Cela vous permet également de réserver le nom du fichier copié.
Faire siliconerockstar commentaire une réponse depuis il a travaillé pour moi
scp -i kp1.pem ./file.txt ec2-user@1.2.3.4:/home/ec2-user
j'ai utilisé la commande ci-dessous pour copier de Linux Centos local 7 à AWS EC2.
scp -i user_key.pem file.txt ec2-user@my.ec2.id.amazonaws.com:/home/ec2-user
laisse supposer que votre fichier pem et somefile.txt que vous voulez envoyer est dans le dossier Téléchargements
scp -i ~/Downloads/mykey.pem ~/Downloads/somefile.txt root@my.ec2.id.amazonaws.com:~/
laissez-moi savoir si cela ne fonctionne pas
scp -i /home/barkat/Downloads/LamppServer.pem lampp_x64_12.04.tar.gz
ce sera très utile pour tous les gars
mon fichier hadoopec2cluster.pem était le seul dans le répertoire de mon mac local, ne pouvait pas le scp à aws en utilisant scp -i hadoopec2cluster.pem hadoopec2cluster.pem ubuntu@serverip:~ .
copié hadoopec2cluster.pem à hadoopec2cluster_2.pem et puis scp -i hadoopec2cluster.pem hadoopec2cluster_2.pem ubuntu@serverip:~ . Voila!
j'ai été retenu parce que je spécifiais mon fichier de clé publique dans
scp -i [private key file path]
quand j'ai attrapé cette erreur et que je l'ai changée en chemin de clé privé à la place, j'étais prêt.
écrivez ce code
scp -r -o "ForwardAgent=yes" /Users/pengge/11.vim root@192.168.2.228:/root/
si vous avez une clé SSH avec accès au serveur de destination et que le serveur source n'y a pas accès, ajouter-o" ForwardAgent=yes " vous permettra de transmettre votre agent SSH au serveur source afin qu'il puisse utiliser votre clé SSH pour se connecter au serveur de destination.
dans votre cas, l'utilisateur root n'aura aucun problème. Mais dans certains cas où vous devez vous connecter sous SSH en tant qu'utilisateur différent, assurez-vous que le répertoire que vous êtes scp -ing a les permissions adéquates pour l'utilisateur que vous êtes ssh-ing.
vient d'être testé:
exécuter la commande suivante:
sudo shred -u /etc/ssh/*_key /etc/ssh/*_key.pub
puis:
- créer ami (image de l'ec2).
- lancement de new ami (image) de l'étape no 2 a choisi de nouvelles clés.