Configuration du fichier de configuration ssh avec id_rsa via tunnel

17

J'ai eu du mal à mettre en place une configuration valide pour ouvrir une connexion avec une deuxième machine, en passant par une autre et en utilisant un id_rsa (qui me demande un mot de passe) pour me connecter à la troisième machine.

J'ai posé cette question dans un autre forum, mais je n'ai reçu aucune réponse qui pourrait être considérée comme très utile.

Le problème, mieux décrit, se présente comme suit:

Local machine: user1@localhost
Intermediary machine: user1@inter
Remote target: user2@final

Je peux faire toute la connexion en utilisant un pseudo-tty:

ssh -t inter ssh user2@final

(cela me demandera le mot de passe du fichier id_rsa que j'ai dans la machine "inter")

Cependant, pour accélérer les choses, je voudrais définir mon fichier .ssh / config, afin que je puisse simplement me connecter à la machine "finale" en utilisant:

ssh final

Ce que j'ai jusqu'à présent - qui ne fonctionne pas - se trouve dans mon fichier .ssh / config:

Host inter
    User user1
    HostName inter.com
    IdentityFile ~/.ssh/id_rsa

Host final
    User user2
    HostName final.com
    IdentityFile ~/.ssh/id_rsa_2
    ProxyCommand ssh inter nc %h %p

Le fichier id_rsa est utilisé pour se connecter à la machine du milieu (cela ne nécessite pas de saisie de mot de passe), et le fichier id_rsa_2 est utilisé pour se connecter à la machine "finale" (celle-ci demande un mot de passe).

J'ai essayé de mélanger certains LocalForwardet / ou RemoteForwardchamps, et de placer les fichiers id_rsa dans les première et deuxième machines, mais je n'arrivais pas à réussir sans aucune configuration.

PS: le fil dont j'ai essayé d'obtenir de l'aide:

http://www.linuxquestions.org/questions/linux-general-1/proxycommand-on-ssh-config-file-4175433750/

linux  ssh  ssh-tunnel  rsa 
— Rubens
source

Réponses:

21

MÉTHODE 1 (utilisez la touche ssh sur inter)

Si vous souhaitez conserver le flux d'authentification

local -- authenticate --> inter -- authenticate (ask password) --> final

Cela ne peut pas être fait avec .ssh / config proxyhost.

Vous avez besoin d'un alias shell bash (j'espère que vous utilisez bash).

Dans ~/.bashrc, ajoutez la ligne suivante

alias ssh-final='ssh -t inter ssh user2@final.com'

Dans l'invite de commande, tapez simplement ce qui suit

ssh-final

finalla section dans ~/.ssh/confign'est pas utilisée.

Détails de connexion (1)

ssh -t inter ssh user2@final.com peut être vu comme suit

local# ssh inter
inter# ssh user2@final.com

localne fait que "parler" à inter. Il n'y a pas de connexion ssh directe ou indirecte entre localet final. localaffiche simplement la sortie de ssh user2@final.com.

MÉTHODE 2 (utilisez la clé ssh sur le local)

Authentification avec la même clé ssh

Host inter
    User user1
    HostName inter.example.com

Host final
    User user2
    Hostname <final.com / final IP Address>
    Port 22
    ForwardAgent yes
    ProxyCommand ssh inter nc %h %p

Copier local ~/.ssh/id_ras.pub vers

/home/user1/.ssh/authorized_keys in `inter`
/home/user2/.ssh/authorized_keys in `final`

Détails de connexion (2)

tunneling ssh

Avant d'entrer dans le détail de ProxyCommand, regardons l'exemple suivant

Étape 1, sur la fenêtre du terminal 1

local# ssh inter -L 2000:final.com:22

Étape 2, sur la fenêtre du terminal 2

local# ssh localhost -p 2000

Dans le terminal 1, un tunnel est installé entre le port local 2000 et le port final.com 22. Tout ce qui est envoyé au port local 2000 sera transmis au port final.com 22 et vice versa.

Dans le terminal 2, ssh se connecte au port local 2000, mais communique en réalité avec le port final.com 22, qui est le sshd.

Avec le tunneling, le client ssh local à l'étape 2 est directement connecté à final.com sshd.

La "sortie" du port local 2000 est le trafic démon ssh "brut".

L'utilisation courante d'un tel tunnel est d'accéder au serveur Web interne ou au serveur de messagerie. Voici un exemple de serveur Web

local# ssh inter -L 2000:final.com:80

Dans le navigateur, utilisez l'URL suivante

http://localhost:2000

Les deux points d'extrémité du tunnel sont le port local 2000 et le port final.com 80.

Trafic entrant et sortant du point d'extrémité du tunnel "TEL QUEL". Permet d'appeler ce trafic "brut".

ProxyCommand

Host final
    User user2
    Hostname <final.com / final IP Address>
    Port 22
    ForwardAgent yes
    ProxyCommand ssh inter nc %h %p

Le ProxyCommandprendre un peu plus loin. Il saute l'étape de création d'un port local et s'y connecte.

Un client ssh exécutera la commande jamais donnée derrière ProxyCommandet traitera la sortie de cette commande comme du trafic "brut". Il conserve le point de terminaison local, puis démarre une connexion ssh avec lui.

Pourquoi l'un ne fonctionne pas l'autre?

La commande suivante

ssh inter nc final.com 22

signifie essentiellement (1) se connecter à inter, puis (2) sur inter, exécuter la commande nc final.com 22.

nc - arbitrary TCP and UDP connections and listens

Il nc final.com 22se connectera donc au port final.com 22, imprimera tout le trafic entrant sur stdout et enverra tous les stdin de l'autre côté. Il s'agit d'un "tunnel" entre nc stdin / out et le port final.com 22.

Puisqu'il ncest exécuté dans la session ssh, toute sa sortie standard est retransmise au client ssh, sous forme de trafic "brut". Et le client ssh peut transmettre le trafic à nc stdin, qui se terminera au port final.com 22.

Grâce au "tunnel" ci-dessus, le client ssh local démarrera final.comdirectement une session ssh .

La commande suivante

ssh -t inter ssh user2@final.com

ne fonctionne pas avec ProxyCommandcar le trafic n'est pas "brut" à partir d'un démon ssh. C'est la sortie standard d'un client ssh . Le client parle au client signifie pas d'affaires.

Authentification avec une clé ssh différente (configuration d'origine OP)

Host inter
    User user1
    HostName inter.com
    IdentityFile ~/.ssh/id_rsa

Host final
    User user2
    HostName final.com
    IdentityFile ~/.ssh/id_rsa_2
    ProxyCommand ssh inter nc %h %p

Copier local ~/.ssh/id_ras.pub vers

/home/user1/.ssh/authorized_keys in `inter`

Copier local ~/.ssh/id_ras_2.pub vers

/home/user2/.ssh/authorized_keys in `final`

Les deux ci-dessus permettront l'utilisation suivante

local# ssh final

Vérification supplémentaire

Utilisez verbeux

local# ssh -v final

Cela devrait aider à identifier le problème ssh.

Vérifier nc

ProxcyCommandest l' exécution ncsur inter. Vérifiez si ncest réellement disponible sur inter.

local# ssh inter
inter# nc final.com 22

Vérifiez que la clé rsa est configurée correctement

Si différentes clés doivent être utilisées pour interet final, les fichiers suivants doivent exister sur la machine locale

local# ls ~/.ssh
id_rsa id_rsa_2 id_rsa.pub id_rsa_2.pub

Comme vous pouvez interdéjà utiliser ssh , vérifiez la configuration des touches final. Depuis votre machine locale

local# ssh -t inter ssh user2@final
final# cat .ssh/authorized_keys

Vous devriez en voir le contenu id_rsa_2.pub.

— John Siu
source
Désolé, j'aurais dû le souligner; En fait, je peux me connecter en utilisant ssh -t, mais ce que j'aimerais faire, c'est simuler exactement le comportement que j'ai de l'utilisation en ssh -tutilisant uniquement la configuration sur le .ssh/config.
— Rubens
Le fichier de configuration, même celui que vous publiez devrait fonctionner. Essayez de passer par l' checkingétape. Il doit y avoir quelque chose qui manque / qui ne va pas.
— John Siu
1
Avec ssh -t, votre ssh to finalest lancé à partir de inter, qui est "presque" le même local# ssh interqu'alors inter# ssh final. L'authentification se situe entre interet final. Avec proxy / nc, votre ssh à final est initié depuis votre machine locale, via un tunnel, vers final. L'authentification se situe entre localet final.
— John Siu
@Rubens se base sur votre commentaire, je pense que vous vous trompez en utilisant toujours la interclé ssh pour vous authentifier final. Essayez de copier id_rsa_2dans local~ / .ssh / id_rsa_2 (NE PAS ÉCRIRE TROP ÉCRIRE local id_rsa) et votre problème pourrait avoir disparu.
— John Siu
2
Notez que ssh2 est ncintégré. Donc, au lieu de ProxyCommand ssh gateway nc %h %p, vous écririez ProxyCommand ssh inter -W %h:%p.
— user123444555621
2

Je n'ai pas vu d'erreurs ni de déclarations ssh -v qui aideraient à voir où ça se bloque.

Hé mec, vous avez presque raison --- le meilleur moyen et le plus sûr est d'avoir les deux clés sur la machine locale. Vous utiliseriez alors le transfert ssh-agent pour vous connecter plutôt que de laisser des clés à des étapes intermédiaires. Vous avez également l'avantage de ne devoir saisir votre phrase secrète de clé qu'une seule fois par connexion.

Si vous avez un système d'exploitation moderne / convivial comme Ubuntu (sur votre machine locale), cela ne devrait pas poser de problème sans * massage *. J'ai laissé le fichier d'identité intentionnellement, vous n'en aurez pas besoin.

Votre fichier de configuration ressemblerait à ceci:

Host inter
    User user1
    ForwardAgent yes
    HostName inter.com

Host final
    ForwardAgent yes
    User user2
    HostName final.com
    ProxyCommand ssh inter nc %h %p

Si ce n'est pas le cas, exécutez ces étapes pour vous assurer que ssh-agent est en cours d'exécution:

'ssh-add -l' (lower case L) will list your private keys if any are loaded, or will be blank, or will say can’t connect to ssh-agent, if so, start ssh-agent.
'eval `ssh-agent`' (those are backticks) starts ssh agent
'ssh-add' will add your key… you can add a path argument if you have a key in a non-default area. At this point you will enter your passphrase.

Il y a un bon guide expliquant comment cela fonctionne, ici.

— MattPark
source
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.