Envoi de l'agent SSH en utilisant différents noms d'utilisateur et différentes clés

Il y a une question très semblable qui, s'il a répondu, a peut-être été la réponse à cette question. Malheureusement, c'est un cas de "pas besoin de répondre à la question que j'ai posée parce que le problème n'était pas ce que je pensais que c'était".

La mise en place

  1. Le serveur bastion.ec2 accepte une connexion ssh depuis mon poste de travail via ssh -i mykey.pem myname@bastion.ec2
  2. Le serveur service1.ec2 accepte les connexions ssh uniquement à partir de bastion.ec2 via ssh -i sharedkey.pem shareduser@service1.ec2

Les exigences

  1. Les deux clés ne sont que sur mon poste de travail, de sorte que je ne peux pas faire la 2ème commande sans avoir à copier la clé.
  2. Pour des raisons de sécurité, je souhaite utiliser le transfert de ssh-agent plutôt que de copier les clés ssh sur bastion.ec2

La solution

C'est là que vous venez. Comment puis-je transférer une autre touche pour la 2ème connexion?

Si l'utilisateur partagé avait mykey.pub dans le fichier ~/.ssh/authorized_keys cela fonctionnerait:

 ssh -i mykey.pem myname@bastion.ec2 ssh shareduser@service1.ec2 

Cependant, je ne veux pas que chaque utilisateur ait à mettre sa clé publique dans chaque serveur.

2 Solutions collect form web for “Envoi de l'agent SSH en utilisant différents noms d'utilisateur et différentes clés”

Étape 1

Assurez-vous que votre agent local est prêt

Juste parce que vous pouvez ssh dans votre serveur de bastion sans spécifier votre chemin d'accès ou être invité à entrer le mot de passe, cela signifie que votre agent ssh est en cours d'exécution et que vous maintenez votre clé. Certains systèmes d'exploitation modernes (par exemple: OSX) répondent à cela pour vous.

Sur votre machine locale

 $ ssh-add -L ssh-rsa ObahfCbvagGbLbhSbeHfvatEBG13== ~/.ssh/mykey.pem ssh-rsa LbhNerWhfgJnnlGbbPyrireEBG13== ~/.ssh/sharedkey.pem 

Fig. 1

Cela signifie que votre agent est en cours d'exécution et a votre clé.

 $ ssh-add -L The agent has no identities. 

Fig.2

Cela signifie que vous n'avez ajouté aucune clé à votre agent. Réparez ceci avec:

 ssh-add ~/.ssh/mykey.pem ~/.ssh/sharedkey.pem 

Fig.3

Étape 2

Assurez-vous que votre agent distant est prêt

SSH dans votre serveur de bastion et répétez la vérification à partir de fig.1 et fig.2 . Cependant, l'erreur que vous êtes plus susceptible d'obtenir est la suivante:

 $ ssh-add -L Could not open a connection to your authentication agent. 

Fig.4

Cela signifie probablement que votre client SSH ne transmet pas votre connexion d'agent d'authentification.

Vous pouvez forcer ceci avec le -A flag.

 $ ssh -A bastion.ec2 

Fig.5

Étape 3

Assurez-vous d'utiliser les touches de droite

Si vous avez ajouté des clés à votre agent, votre agent transfère et votre agent distant répertorie vos clés locales. Il n'y a que deux raisons probables pour lesquelles vous n'êtes pas connecté. Soit vous n'utilisez pas la bonne touche, soit vous n'utilisez pas le bon nom d'utilisateur.

Émettez la contrepartie publique à votre clé privée:

 $ cd $ cd .ssh $ ssh-keygen -y -f mykey.pem ssh-rsa ObahfCbvagGbLbhSbeHfvatEBG13 $ ssh-keygen -y -f sharedkey.pem ssh-rsa LbhNerWhfgJnnlGbbPyrireEBG13 

Fig.6

Ceux-ci devraient être les mêmes que ce que vous voyiez de ssh-add -L à la valeur == près de la fin.

Maintenant, d'une manière ou d'une autre, vous devez entrer dans la boîte où vous ne parvenez pas à vous connecter et à regarder le contenu du fichier $HOME/.ssh/authorized_keys pour l'utilisateur que vous essayez de vous connecter. Vous devez vous assurer que la clé publique que vous produisez avec la commande ci-dessus se trouve dans ce fichier sur une seule ligne. Vous ne pouvez pas croire que la sharedkey.pub que les cubes Bro 2 vous ont envoyé par courrier électronique est juste. Vérifier! Cela peut exiger que quelqu'un d'autre puisse SSH entrer en tant qu'utilisateur pour vous obtenir le fichier authorized_keys ou obtenir un accès root. Si vous êtes arrivé à ce point et que cela ne fonctionne toujours pas, vous allez au-delà de prendre des raccourcis.

Étape 4

Rendre facile

J'espère que les étapes ci-dessus vous ont introduit. Maintenant, laissez ce mal de tête disparaître aussi longtemps que vous utilisez ce poste de travail.

Configurez votre ssh-client local

 Host * # A lot of people put an IdentityFile line in this Host * section. # Don't do that unless you will use only 1 key everywhere forever. #IdentityFile id_rsa Host bastion.ec2 # You want to make sure you always forward your agent to this host. # But don't forward to untrusted hosts. So don't put it in Host * ForwardAgent yes # Go a head and put the IP here in case DNS ever fails you. # Comment it out if you want. Having it recorded is a good backup. HostName 172.31.0.1 # You don't want to create a proxy loop later, so be explicit here. ProxyCommand none # SSH should try using all keys in your .ssh folder, but if you # know you want this key, being explicit speeds authentication. IdentityFile ~/.ssh/mykey.pem # Connect effortlessly by hostname or IP address # This assumes that your internal DNS uses the fake TLD ec2 # This assumes that 172.31.0.0 is your C-Class subnet Host *.ec2 172.31.* # This command says proxy all ssh connections through bastion as if # you had done an ssh -A ProxyCommand ssh -W %h:%p bastion.ec2 ForwardAgent yes # These next lines are documentation you leave as a love letter to # your future self when all else fails or you have to help a # coworker and decide to look at your own config. # ssh-add ~/.ssh/*.pem # ssh -At bastion.ecs ssh admin@172.31.18.19 

Fig.7

Si vous ne prenez rien d'autre de la figure 7, il devrait être l'utilisation correcte de ProxyCommand & ForwardAgent .

Remplissez automatiquement votre fichier .bash_profile

Vous ne voulez pas avoir à faire ssh-add manuellement chaque fois que vous vous connectez à votre machine. ~/.bash_profile est un script qui s'exécute chaque fois que vous vous connectez **. Mettre la ligne de la fig. 3 là-dedans et vous devriez toujours avoir votre agent prêt.

** Ne confondez pas cela avec .bashrc qui s'exécute pour chaque nouveau terminal [interactif]. Votre agent continue de fonctionner même si vous fermez toutes vos sessions de terminal. Non Besoin de recharger vos clés

Alternative à l'utilisation de .bash_profile

J'ai également créé un schéma qui ajoute un agent de lancement OSX / macos . Vous pouvez utiliser cette méthode pour démarrer votre ssh-agent lors du démarrage. Il est très facile à installer:

 curl -sSL https://gist.github.com/RichardBronosky/429a8fff2687a16959294bcee336dd2a/raw/install.sh | bash 

C'est là que vous venez. Comment puis-je transférer une autre touche pour la 2ème connexion?

Vous ne renvoyez pas les clés. Vous transférez un agent et vous pouvez avoir des clés totalement indépendantes que celles que vous utilisez pour l'authentification dans le premier saut. Vérifiez les clés de votre agent en utilisant ssh-add -L .

Mais encore mieux, exécutez la connexion sur ProxyCommand ssh -W %h:%p myname@bastion.ec2 , ce qui évitera la nécessité de transférer les options de l'agent, du tas ou de la ligne de commande et une authentification de l'hôte immédiat.

Vous pouvez simplement le mettre dans votre configuration (voir man ssh_config ).

  • Redhat Linux fail fail ssh
  • Montage de partages SSH / SFTP sur Windows 7
  • Comment SSH à un IP privé derrière un routeur utilisant IP dynamique publique
  • Sign_and_send_pubkey: signature échouée: opération refusée par l'agent
  • Fichiers Rsync via un hôte intermédiaire
  • Gérer quelques serveurs Linux à la fois
  • Tunnel SSH vers le réseau domestique et accès à l'interface Web du routeur
  • Comment WinSCP est-il capable de fournir un utilisateur sudo pour l'exécution de scp?
  • Rsync: impossible de régler les heures sur "<dir path>"
  • Écran équivalent Windows powershell
  • Proxy http sur ssh, pas de chaussettes
  • Soyons le génie de l'ordinateur et du réseau.