Bonjour,
J'ai une machine au bureau derriere une machine directement connectée au
net.
Pour y acceder, je dois donc faire un premier SSH sur celle directement
connectée au Net, puis de là, un autre vers ma machine locale.

J'ai un compte utilisateur simple sur celle directement connectée au net, et
je suis (j'ai la possibilité d'etre) root sur ma machine (la seconde).

J'imagine bien que c'est un problème assez répandu et qu'il existe
certainement un moyen de simplifier les choses. Il me manque juste des mots
clés pour chercher. COmment cet état des chose s'appelle? "double SSH"?...

Merci d'avance.

Le vendredi 9 mars 2007 21:13, Mihamina (R12y) Rakotomandimby s'est exprimé
de la sorte sur fr.comp.os.unix :

> J'imagine bien que c'est un problème assez répandu et qu'il existe
> certainement un moyen de simplifier les choses. Il me manque juste des
> mots clés pour chercher. COmment cet état des chose s'appelle? "double
> SSH"?...

ssh over ssh ?

--
@+
Doug [Linux user #307925] - Slackware RuleZ ;-)
[Pourquoi t'es qui, qu'est ce que tu fais par où ?]
-- Pour me contacter enlever no-spam (2X) --

R12y :

> Bonjour,
> J'ai une machine au bureau derriere une machine directement connectée au
> net.
> Pour y acceder, je dois donc faire un premier SSH sur celle directement
> connectée au Net, puis de là, un autre vers ma machine locale.
>
> J'ai un compte utilisateur simple sur celle directement connectée au net,

Tu peux établir une connexion ssh permanente entre ces deux machines, qui
établit un tunnel d'un port quelconque XXXX de la machine rebond A vers le
port 22 de ta machine B. Ce qui se fait depuis la machine A avec:

ssh -N -L :XXXX:B:22 B

(je te le fais faire depuis B histoire de pouvoir forcer à ce que le port
XXXX soit accessible depuis l'extérieur (c'est l'effet du «:» avant le
«22»), et non pas seulement depuis la machine A, comme c'est souvent le
cas par défaut).

Ensuite, de l'extérieur, tu te connectes au port XXXX de la machine rebond,
et ploum.

> COmment cet état des chose s'appelle? "double SSH"?...

Forward de port.

J'oubliais: avant de mettre ça en oeuvre, demande l'aval de
l'administrateur de la machine rebond. Il y a des paranos que ce genre de
bidouilles fait criser...

Luc Habert wrote:

> J'oubliais: avant de mettre ça en oeuvre, demande l'aval de
> l'administrateur de la machine rebond. Il y a des paranos que ce genre de
> bidouilles fait criser...

En fait, normalement, il est censé meme me forwarder une plage de port vers
certains port de ma machine, pour que je puisse travailler de l'exterieur.
La machine de rebond est sous FreeBSD. Et il me dit que pour que le
forwarding prenne effet, il doit redemmarer la machine. Il n'a pas envie.
Donc je dois lui proposer autre chose, et ce système de ssh forwarding est
un/le moindre mal.

Merci pour les indications.

"Mihamina (R12y) Rakotomandimby" <infogerance@asso-polyvalente.fr> wrote:
> Luc Habert wrote:
>
> > J'oubliais: avant de mettre ça en oeuvre, demande l'aval de
> > l'administrateur de la machine rebond. Il y a des paranos que ce genre de
> > bidouilles fait criser...
>
> En fait, normalement, il est censé meme me forwarder une plage de port vers
> certains port de ma machine, pour que je puisse travailler de l'exterieur.
> La machine de rebond est sous FreeBSD. Et il me dit que pour que le
> forwarding prenne effet, il doit redemmarer la machine. Il n'a pas envie.


C'est un sacré clown!
sysctl -w net.inet.ip.forwarding=1
fait ce qu'il faut sans rebooter.

> Donc je dois lui proposer autre chose, et ce système de ssh forwarding est
> un/le moindre mal.
>
> Merci pour les indications.

--

Michel TALON

Michel Talon wrote in message <essjpg$1t9b$1@asmodee.lpthe.jussieu.fr>:
> C'est un sacré clown!

C'est sûr.

> sysctl -w net.inet.ip.forwarding=1
> fait ce qu'il faut sans rebooter.

S'il y a du masquerading dans l'histoire, ce qui m'a l'air assez clair en
l'occurrence, ça va être un poil plus complexe, quand même.

Nicolas George <nicolas$george@salle-s.org> wrote:
> Michel Talon wrote in message <essjpg$1t9b$1@asmodee.lpthe.jussieu.fr>:
> > C'est un sacré clown!
>
> C'est sûr.
>
> > sysctl -w net.inet.ip.forwarding=1
> > fait ce qu'il faut sans rebooter.
>
> S'il y a du masquerading dans l'histoire, ce qui m'a l'air assez clair en
> l'occurrence, ça va être un poil plus complexe, quand même.

Comme ça par exemple:
vi /etc/pf.conf et ajouter
nat on bfe0 from 192.168.1.0/24 to any -> 134.157.10.41
pfctl -f /etc/pf.conf

et vérifier
pfctl -s nat


--

Michel TALON

"Mihamina (R12y) Rakotomandimby" <infogerance@asso-polyvalente.fr>
writes:

> Bonjour,
> J'ai une machine au bureau derriere une machine directement connectée au
> net.
> Pour y acceder, je dois donc faire un premier SSH sur celle directement
> connectée au Net, puis de là, un autre vers ma machine locale.
>
> J'ai un compte utilisateur simple sur celle directement connectée au net, et
> je suis (j'ai la possibilité d'etre) root sur ma machine (la seconde).
>
> J'imagine bien que c'est un problème assez répandu et qu'il existe
> certainement un moyen de simplifier les choses. Il me manque juste des mots
> clés pour chercher. COmment cet état des chose s'appelle? "double SSH"?...

Je suis pas du tout sur que ça fasse ce que tu veux, mais jettes un
coup d'oeil à http://penguin.fr/sshproxy/about.html

Sinon, un script wrapper doit pouvoir faire l'affaire, en faisant un
truc genre

ssh machine-connectee "ssh machine-derriere-firewall $commande"

(l'ironie du sort étant que j'écris en ce moment même depuis un
"double ssh", mais c'est pas moi qui ai configuré la machine relai,
elle forwarde toute seule).


Attention aux solutions à base de forward de port, ton client ssh va
s'emeler les pinceaux sur les authentifications, vu qu'il verra une
clé différente selon le port sur lequel il se connecte sur la même
machine. M'enfin, on doit pouvoir trouver une solution aussi.

--
Matthieu

Matthieu Moy :

> Sinon, un script wrapper doit pouvoir faire l'affaire, en faisant un
> truc genre
>
> ssh machine-connectee "ssh machine-derriere-firewall $commande"

Et pour de l'interactif:

ssh -t machine-connectee 'ssh machine-derriere-firewall'

.. Ça va si tu as des clefs, mais sinon, il faut taper deux fois le mot de
passe, ça commence à devenir lourd. Les chainages d'escape aussi, ça doit
être pénible.

> Attention aux solutions à base de forward de port, ton client ssh va
> s'emeler les pinceaux sur les authentifications, vu qu'il verra une
> clé différente selon le port sur lequel il se connecte sur la même
> machine.

Une solution: dans le .ssh/config:

Host ploum
Hostname nomdelamachinerebond
UserKnownHostsFile ~/.ssh/known_hosts.alt # je sais pas si il expanse le ~
# au besoin, expanser à la main
Port XXXX

et faire un simple «ssh ploum» pour se connecter.

Le 9 mars 2007 à 21:13, Mihamina Rakotomandimby s'est exprimé ainsi :

> J'imagine bien que c'est un problème assez répandu et qu'il existe
> certainement un moyen de simplifier les choses. Il me manque juste des
> mots clés pour chercher. COmment cet état des chose s'appelle? "double
> SSH"?...

J'arrive à faire ce genre de chose avec Emacs pour éditer de fichiers
distants; dans la doc on parle de « ssh multihop ». Je pense que c'est
le mot qui te manquait.
--
Sébastien Kirche

Michel Talon wrote:

>> La machine de rebond est sous FreeBSD. Et il me dit que pour que le
>> forwarding prenne effet, il doit redemmarer la machine. Il n'a pas envie.
>
>
> C'est un sacré clown!

un bouffon !!

> sysctl -w net.inet.ip.forwarding=1
> fait ce qu'il faut sans rebooter.

suivi de l'ajout de la ligne dans /etc/sysctl.conf

Nicolas George wrote:

>> sysctl -w net.inet.ip.forwarding=1
>> fait ce qu'il faut sans rebooter.

> S'il y a du masquerading dans l'histoire, ce qui m'a l'air assez clair en
> l'occurrence, ça va être un poil plus complexe, quand même.

ké masquerading ?
oh !!!, BSD c'est pas Linux

il me semble bien que cela ne peut fonctionner que si une option
de compile du noyo est validée.

c'était le cas sur une FreeBSD 4.5

linuxkiller@linuxfucker.ici.org wrote:
> Nicolas George wrote:
>
> >> sysctl -w net.inet.ip.forwarding=1
> >> fait ce qu'il faut sans rebooter.
>
> > S'il y a du masquerading dans l'histoire, ce qui m'a l'air assez clair en
> > l'occurrence, ça va être un poil plus complexe, quand même.
>
> ké masquerading ?
> oh !!!, BSD c'est pas Linux
>
> il me semble bien que cela ne peut fonctionner que si une option
> de compile du noyo est validée.

Non, tous les firewalls sont en module maintenant, qui plus est on n'a
jamais été obligé d'utiliser le firewall débile qui nécessitait de faire
un aller retour en userland pour faire le nat.

>
> c'était le cas sur une FreeBSD 4.5

Non, il suffisait d'utiliser ipfilter au lieu de cette bouse de ipfw qui
ressemble à cette autre bouse encore plus sombre de iptables.

>
>
>

--

Michel TALON

Bonjour,

le 10/03/2007 à 09:27, Michel Talon a écrit dans le message
<estq5f$28jd$1@asmodee.lpthe.jussieu.fr> :

> Non, il suffisait d'utiliser ipfilter au lieu de cette bouse de ipfw
> qui ressemble à cette autre bouse encore plus sombre de iptables.

On ne peut pas dire que netfilter soit une bouze mais il est vrai que la
syntaxe de son outil de configuration, en l'occurrence iptables, est
relativement lourde par rapport à un bijou comme pf. Le gros avantage de
netfilter est, à mon avis, tous les modules de conntrack que n'a pas pf
et qui sont vraiment utile pour des personnes comme moi qui n'ont qu'une
adresse IP et sont donc obligés de passer par du NAT pour que tout le
petit monde derrière soit content.

And welcome to the troll ! ;-)

--
Benoit Izac

OoO La nuit ayant déjà recouvert d'encre ce jour du vendredi 09 mars
2007, vers 23:50, lhabert@clipper.ens.fr (Luc Habert) disait:

> Et pour de l'interactif:

> ssh -t machine-connectee 'ssh machine-derriere-firewall'

On peut automatiser :
ssh -o ProxyCommand="ssh machine-connectee nc %h %p" machine-derriere-firewall

Le ProxyCommand pouvant se mettre dans le .ssh/config, on arrive alors
à :

ssh machine-derriere-firewall.

Et par rapport au tunnel, cela évite de faire du ssh over ssh (donc du
tcp over tcp).
--
Take care to branch the right way on equality.
- The Elements of Programming Style (Kernighan & Plauger)

linuxkiller@LinuxFucker.ici.org wrote in message
<estkbv$p8k$1@gyptis.org>:
> ké masquerading ?

http://en.wikipedia.org/wiki/IP-masquerading

> oh !!!, BSD c'est pas Linux

Je n'ai pas parlé de Linux. Retourne dormir.

Vincent Bernat wrote in message <m3fy8dh0f0.fsf@neo.luffy.cx>:
> Et par rapport au tunnel, cela évite de faire du ssh over ssh (donc du
> tcp over tcp).

ssh-over-ssh ne fait pas de TCP-over-TCP.

OoO Peu avant le début de l'après-midi du samedi 10 mars 2007, vers
13:23, Nicolas George <nicolas$george@salle-s.org> disait:

>> Et par rapport au tunnel, cela évite de faire du ssh over ssh (donc du
>> tcp over tcp).

> ssh-over-ssh ne fait pas de TCP-over-TCP.

Exact.
--
BEWITCHED, DOES NOT PROMOTE SATANISM
BEWITCHED, DOES NOT PROMOTE SATANISM
BEWITCHED, DOES NOT PROMOTE SATANISM
-+- Bart Simpson on chalkboard in episode 2F17

Michel Talon wrote:

>> c'était le cas sur une FreeBSD 4.5
>
> Non, il suffisait d'utiliser ipfilter au lieu de cette bouse de ipfw qui
> ressemble à cette autre bouse encore plus sombre de iptables.

Non, c'était le cas puisque j'utilisais ipfw )

Nicolas George wrote:
> linuxkiller@LinuxFucker.ici.org wrote in message
> <estkbv$p8k$1@gyptis.org>:
>> ké masquerading ?
>
> http://en.wikipedia.org/wiki/IP-masquerading
>
>> oh !!!, BSD c'est pas Linux
>
> Je n'ai pas parlé de Linux. Retourne dormir.

Généralement ce terme est utilisé par les Linuxiens

linuxkiller@LinuxFucker.ici.org wrote in message
<et1mg7$bo5$1@gyptis.org>:
> Généralement ce terme est utilisé par les Linuxiens

C'est un terme tout à fait standard pour désigner une certaine forme de
traduction d'adresse.

De toutes manières, un linuxien n'est pas obligé de parler de linux en
permanence.

Nicolas George <nicolas$george@salle-s.org> wrote:
> linuxkiller@LinuxFucker.ici.org wrote in message
> <et1mg7$bo5$1@gyptis.org>:
> > Généralement ce terme est utilisé par les Linuxiens
>
> C'est un terme tout à fait standard pour désigner une certaine forme de
> traduction d'adresse.

Non, c'est un terme qui n'est standard que chez les linuxiens.
En pratique on peut vouloir soit modifier l'adresse de destination, soit
l'adresse d'origine, le premier est la redirection, je suppose que le
deuxième est le "masquerading".


--

Michel TALON

Michel Talon wrote in message <et366e$nel$1@asmodee.lpthe.jussieu.fr>:
> Non, c'est un terme qui n'est standard que chez les linuxiens.

Tu as une preuve de ce que tu avances?

> En pratique on peut vouloir soit modifier l'adresse de destination, soit
> l'adresse d'origine, le premier est la redirection, je suppose que le
> deuxième est le "masquerading".

Le masquerading désigne le cas où l'adresse n'est pas simplement traduite
suivant une règle simple, mais sur la base d'heuristiques assez complexes,
et avec le port également, de manière à ce que plusieurs machines
différentes aient la même adresse apparente, et que les connexions soient
établies néanmoins.

D'ailleurs, l'emploi de «NAT» tout court pour désigner ça est tout à fait
impropre, dans la mesure où du NAT seul ne peut pas assurer un partage de
connexion.