Re: Traverser une machine en SSH
Stephane Bortzmeyer wrote:
> On Thu, Nov 08, 2007 at 11:30:08AM +0100,
> François TOURDE <fra-duf-no-spam@tourde.org> wrote
> a message of 31 lines which said:
>
>>> Et un "ssh B.mondomaine" se connectera de manière invisible à A
>>> d'abord, y lancera netcat (nc) et continuera sur B.
>> J'ai pas encore essayé ça, mais ça devrait me plaire aussi. Il faut
>> juste que je vérifie que "Host B.mondomaine" puisse faire référence à
>> un domaine inexistant sur le net.
>
> Sans problème (je l'utilise). ProxyCommand est utilisé avant toute
> requête DNS.
Mieux, ça n'a pas à être un domaine DNS. J'utilise beaucoup de variante de
ça pour atteindre des machines derrière des firewall (sur lesquels j'ai un
compte ssh bien sûr).
Extrait de mon fichier .ssh/config
====
Host *.fakedomain
ProxyCommand ssh fakedomain "tcpconnect `basename %h .fakedomain` %p"
Host fakedomain
Hostname firewall.realdomain.fr
User mylogin
====
Ainsi, je peux faire au choix
* "ssh fakedomain" pour me retrouver sur le firewall
* "ssh machine.fakedomain" pour me retrouver sur la machine "machine" derrière le firewall
Enfin, quand je dis derrière, ce n'est même pas nécessaire : rien ne m'enpêche de faire
ssh ftp-master.debian.org.fakedomain
C'est juste que je vais passer par le firewall avant de contacter ftp-master.debian.org
(ie il aura l'impression que la connexion provient de firewall.realdomain.fr)
En outre, la commande "tcpconnect `basename %h .fakedomain` %p" se passe sur le firewall
(donc la résolution DNS du nom `basename %h .fakedomain` est faite sur le firewall)
À noter : contrairement à deux ssh manuels successif (ssh firewall ssh machine), avec ce
mécanisme, le ssh sur la machine de départ dialogue directement avec le sshd de la machine
d'arrivée. Ça peut être utile pour les clés, le forward d'agent, la redirection de ports,
...
En claire, j'ai utilisé ces mécanismes (redirections de ports, ...) même lorsque que le sshd
du firewall n'était pas un openssh (mais un truc proprio sans aucune de ces fonctionnalités).
Seul point négatif : la double encryption (mais bon, en général on ne fait pas de calcul
haute performance avec ce genre de chose)
Autre remarque : les programmes 'nc' et 'tcpconnect' sont interchangeables pour cette utilisation.
'tcpconnect' est un peu moins souvent installé par défaut mais il a tendance à mieux se
terminer après la fin de la connection. 'nc' reste parfois sur le firewall (il faut alors aller
le tuer à la main). Ça dépend de la version de 'nc' (et de la distribution ou du système (AIX, ...))
sur le firewall.
A+
Vincent
Reply to: