tunnel ssh vers chez moi

On 29 Apr 2004, Kevin DENIS wrote:

iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 22

J'ai essayé ça pour dérouter le port entrant 80 de la passerelle vers le
port 22 et j'ai obtenu ça depuis le boulot :

,----
| [goudurix:~] seki% ssh -v -2 -p 80 seki@80.170.xx.xx
| OpenSSH_3.7.1p1, SSH protocols 1.5/2.0, OpenSSL 0.9.7c 30 Sep 2003
| debug1: Reading configuration data /Users/seki/.ssh/config
| debug1: Applying options for 80.170.xx.xx
| debug1: Reading configuration data /sw/etc/ssh/ssh_config
| debug1: Connecting to 80.170.xx.xx [80.170.xx.xx] port 80.
| debug1: Connection established.
| debug1: identity file /Users/seki/.ssh/id_rsa type -1
| debug1: identity file /Users/seki/.ssh/id_dsa type -1
| ssh_exchange_identification: Connection closed by remote host
| debug1: Calling cleanup 0x184d8(0x0)
`----

Vu que j'ai par ailleurs des règles iptables qui me droppent les paquets
tcp qui ne correspondent pas à une connexion ESTABLISHED ou RELATED, je
suppose que ça pourrait expliquer l'echec de la connexion ?

Sébastien Kirche

Le Thu, 29 Apr 2004 16:41:30 +0200, Sebastien Kirche a ecrit:
|
|> > Est-ce que je peux dans l'état actuel établir un tunnel à travers le
|> > firewall via par exemple le port 80 et faire que le ssh se connecte sur
|> > le port 22 chez moi via le port 80 du firewall ?
|>
|> iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 22
|
| Oui mais non, je me suis mal exprimé dans ma question, ici le firewall
| designe celui du boulot et pas le mien :)
|
Ou est le probleme? Ton client ssh sort par le port 80 (on considere qu'il
est autorise par le fw de ta boite) arrive sur le port 80 de ta machine
linux situe n'importe ou, et le flux est redirige vers le port 22 donc
ton client ssh se connecte sur le serveur ssh de ta machine. Honnetement,
ca me parait plus simple de changer le port d'ecoute de ton sshd.

--
Kevin
Tiens, c'est marrant que tu me demandes ca... parceque je ne sais pas non plus.
-+- Les 100 choses que vous n'aimez pas entendre de la part du sysadmin -+-

Le Thu, 29 Apr 2004 16:41:30 +0200, Sebastien Kirche a ecrit:
|
|> > Est-ce que je peux dans l'état actuel établir un tunnel à travers le
|> > firewall via par exemple le port 80 et faire que le ssh se connecte sur
|> > le port 22 chez moi via le port 80 du firewall ?
|>
|> iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 22
|
| Oui mais non, je me suis mal exprimé dans ma question, ici le firewall
| designe celui du boulot et pas le mien :)
|
Ou est le probleme? Ton client ssh sort par le port 80 (on considere qu'il
est autorise par le fw de ta boite) arrive sur le port 80 de ta machine
linux situe n'importe ou, et le flux est redirige vers le port 22 donc
ton client ssh se connecte sur le serveur ssh de ta machine. Honnetement,
ca me parait plus simple de changer le port d'ecoute de ton sshd.

heuuuu ? dans /etc/ssh/sshd_config ajouter:

Port 22
Port 80
Port 443

et c'est tout.

Michel.

Bonjour,

je viens de passer pas mal de temps à rtfm iptables et j'ai maintenant une
config qui tient (j'espère) la route pour me permettre de laisser tourner
ma passerelle pour quelques tests.

J'ai laissé possible un accès par ssh en pensant pouvoir faire quelques
essais depuis le boulot, mais c'était sans compter sur le firewall de la
boîte qui m'interdit le port 22.

Sébastien Kirche

Facile:

tu configure ssh pour écouter aussi sur le port https : 443.

et tu passes par le proxy sur ce port (via utty)

Bonjour,

bon ça ne marche toujours pas (snif).

État des lieux :
- pour contourner les restrictions du firewall boulot, je NATe le port 80
de ma passerelle vers le 22 suivant le conseil qui m'avait été donné :
iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 22
- j'ai autorisé dans /etc/sshd.conf l'identification par mot de passe
- j'ai oublié de vérifier le /etc/hosts.deny (zut !) mais le «connection
established» me laisse penser qu'il n'y a pas de problème

Voilà le résultat en tentant une connexion depuis le boulot avec un mode
bavard et sans préciser de méthode d'authentification :

,----[ ssh -vvv -p 80 seki@80.170.xx.xx ]
| OpenSSH_3.7.1p1, SSH protocols 1.5/2.0, OpenSSL 0.9.7c 30 Sep 2003
| debug1: Reading configuration data /Users/seki/.ssh/config
| debug1: Reading configuration data /sw/etc/ssh/ssh_config
| debug2: ssh_connect: needpriv 0
| debug1: Connecting to 80.170.xx.xx [80.170.xx.xx] port 80.
| debug1: Connection established.
| debug1: identity file /Users/seki/.ssh/identity type -1
| debug1: identity file /Users/seki/.ssh/id_rsa type -1
| debug1: identity file /Users/seki/.ssh/id_dsa type -1
| ssh_exchange_identification: Connection closed by remote host
| debug1: Calling cleanup 0x184d8(0x0)
`----

Je n'ai pas échangé de clé avec le serveur, je comptais passer par
authentification mot de passe.
Est-ce que ça explique les «type -1» affichés.

Qu'est-ce que je n'ai pas encore vu qui me bloque ?

Sébastien Kirche

On 3 May 2004, Sebastien Kirche wrote:

Bonjour,

bon ça ne marche toujours pas (snif).

État des lieux :
- pour contourner les restrictions du firewall boulot, je NATe le port 80
de ma passerelle vers le 22 suivant le conseil qui m'avait été donné :
iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 22
- j'ai autorisé dans /etc/sshd.conf l'identification par mot de passe
- j'ai oublié de vérifier le /etc/hosts.deny (zut !) mais le «connection
established» me laisse penser qu'il n'y a pas de problème

[...]

Je n'ai pas échangé de clé avec le serveur, je comptais passer par
authentification mot de passe. Est-ce que ça explique les «type -1»
affichés.

Qu'est-ce que je n'ai pas encore vu qui me bloque ?

J'ai oublié de préciser que depuis une machine du réseau local ça marche
parfaitement sur le port 22 ou sur le port 80 avec authentification par mot
de passe.

Dans le message <news:m2fzahkgjs.fsf@free.fr>,
*Sebastien Kirche* tapota sur f.c.o.l.configuration :

Bonjour,

Bonjour et désolé de ma réponse tardive.

bon ça ne marche toujours pas (snif).

État des lieux :
- pour contourner les restrictions du firewall boulot, je NATe le port 80
de ma passerelle vers le 22 suivant le conseil qui m'avait été donné :
iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 22

A peu de chose près c'est la règle Nat que je devais vous proposer l'autre
jour. Je vous avais demandé si l'adresse IP depuis laquelle vous vous
connectiez, était fixe afin de limiter cette redirection de port à cette
seule adresse IP.
L'intérêt est le suivant, en espérant être suffisamment clair. Si par
exemple votre box héberge une multitude de service, web, ftp, pop, imap,
smtp, etc, on se retrouve avec une machine où, d'une part, tous les ports
standards sont déjà utilisés et ne permettant donc pas de rediriger un de
ces ports sur le service ssh car l'accès au service du port redirigé serait
alors inaccessible à tous les utilisateurs qui devront accéder à celui-ci,
et, d'autre part, une machine où vous avez peut être besoin d'accéder depuis
votre boulot aux principaux services sauf à un ou deux dont nous pourrons
alors utiliser le port pour le rediriger vers le port ssh.
De cette manière on minimise la condamnation du service qui sera utilisé
pour la redirection de port, le rendant, malgré tout, accessible aux autres.

Maintenant reste à choisir le port à utiliser pour la redirection.
Dans votre post initial, vous nous parlez de proxy transparent pour les
accès http et https. Donc il est clair qu'il ne faut pas utiliser le port 80
ou 443 pour votre redirection, car lors de l'établissement de la connexion
ssh, le proxy, ne reconnaissant pas le protocole, coupera la connexion
aussitôt.
Il faut donc choisir le port d'un service dont le protocole reste assez
basique et qui ne sera pas filtré par le proxy ou firewall. Je conseillerai
donc le port pop ou imap du fait qu'on utilise rarement ces deux services à
la fois depuis une même machine.

Au final, la règle Nat ressemblerai à ceci :

iptables -t nat -A PREROUTING -p tcp --dport 143 -s 195.25.216.129
-j REDIRECT --to-ports 22

et éventuellement la règle qui autorise en entrée les connexions sur le port
143.

Quant à la solution de faire écouter le service sshd sur un autre port que
le port 22, je la trouve personnellement impropre, tout du moins quand il
s'agit de faire écouter le service ssh sur le port d'un service standard, ce
qui était le cas ici. Je préfère privilégier les solutions qui respectent au
mieux les standards et RFC.

- j'ai autorisé dans /etc/sshd.conf l'identification par mot de passe

- j'ai oublié de vérifier le /etc/hosts.deny (zut !)

Le daemon sshd de OpenSSH n'utilise pas ce fichier sauf s'il a été compilé
avec le support tcpwrapper ou s'il est utilisé via le wrapper tcpd, ce qui
est très rarement le cas.

mais le «connection established» me laisse penser qu'il n'y a pas
de problème

Sauf celui que j'ai évoqué concernant le proxy et qui à mon avis est bien
celui là qui coupe la connexion.

[...] Je n'ai pas échangé de clé avec le serveur,
je comptais passer par authentification mot de passe. Est-ce que
ça explique les «type -1» affichés. Qu'est-ce que je n'ai pas encore
vu qui me bloque ?

J'ai oublié de préciser que depuis une machine du réseau local ça
marche parfaitement sur le port 22 ou sur le port 80 avec
authentification par mot de passe.

Le type d'authentification ne changera rien à votre problème. Utilisé le
type d'authentification qui vous convient le mieux.

PS : J'ai bien reçu par mail la discussion au sujet de l'évolution de la FAQ
de fcolc et je vous répondrai à tous dans la journée.

--
TiChou

On 3 May 2004, TiChou wrote:

[...Snip l'explication *claire* sur le routage de port sélectif...]


Maintenant reste à choisir le port à utiliser pour la redirection. Dans
votre post initial, vous nous parlez de proxy transparent pour les accès
http et https. Donc il est clair qu'il ne faut pas utiliser le port 80 ou
443 pour votre redirection, car lors de l'établissement de la connexion
ssh, le proxy, ne reconnaissant pas le protocole, coupera la connexion
aussitôt.

Ahaa ? Vous m'éclairez la situation d'un jour nouveau. J'avoue que je
n'avais pas (plus) pensé à ce fichu ;) proxy. Ni au fait qu'il pouvait
shunter une connexion non http sur le port 80.

Il faut donc choisir le port d'un service dont le protocole
reste assez basique et qui ne sera pas filtré par le proxy ou firewall. Je
conseillerai donc le port pop ou imap du fait qu'on utilise rarement ces
deux services à la fois depuis une même machine.

Moui, j'ai pour habitude de laisser mes messages perso sur leurs serveurs
lorsque je consulte mes boîtes perso debpuis le boulot par imap. Donc
condamner pop entre chez moi et le boulot est tout à fait envisageable.

Au final, la règle Nat ressemblerai à ceci :

iptables -t nat -A PREROUTING -p tcp --dport 143 -s 195.25.216.129
-j REDIRECT --to-ports 22

et éventuellement la règle qui autorise en entrée les connexions sur le
port 143.

Ok, je note et je testerai ça dès demain mais avec le port 110.
Et en modifiant la règle qui autorise l'entrée http vu que je n'ai plus de
raison de laisser ce port ouvert si je n'ai rien à servir :)

Soit dit en passant je ne fais pas dans la paranoïa, et j'ai par contre
laissé quelques services standards ouverts comme ident, icmp echo, etc.

Il faudra que je publie mes règles iptables pour relecture :)

D'ailleurs j'ouvrirai bien un fil aussi pour des questions de topologie
réseau, à voir...

Quant à la solution de faire écouter le service sshd sur un autre port que
le port 22, je la trouve personnellement impropre, tout du moins quand il
s'agit de faire écouter le service ssh sur le port d'un service standard,
ce qui était le cas ici. Je préfère privilégier les solutions qui
respectent au mieux les standards et RFC.

J'adhère :)

- j'ai oublié de vérifier le /etc/hosts.deny (zut !)

Le daemon sshd de OpenSSH n'utilise pas ce fichier sauf s'il a été compilé
avec le support tcpwrapper ou s'il est utilisé via le wrapper tcpd, ce qui
est très rarement le cas.

Intéressant. C'est fou le nombre de pages [web] qui indiquent des solutions
du type «rustine» ou «sparadrap sur jambe de bois» tout azimut pour corriger
des problèmes.
Alors qu'il suffit souvent de changer un seul réglage. Tout l'art est de
trouver où...
(tiens, de l'eau au moulin de ne nouvelle «faq» ;)

mais le «connection established» me laisse penser qu'il n'y a pas
de problème

Sauf celui que j'ai évoqué concernant le proxy et qui à mon avis est bien
celui là qui coupe la connexion.

Effectivement je ne m'étais pas posé la question de savoir avec *qui* la
connexion était établie.

[...] Je n'ai pas échangé de clé avec le serveur,
je comptais passer par authentification mot de passe. Est-ce que
ça explique les «type -1» affichés. Qu'est-ce que je n'ai pas encore
vu qui me bloque ?

J'ai oublié de préciser que depuis une machine du réseau local ça
marche parfaitement sur le port 22 ou sur le port 80 avec
authentification par mot de passe.

Le type d'authentification ne changera rien à votre problème. Utilisé le
type d'authentification qui vous convient le mieux.

Vu. Les 2 sans doute d'ailleurs.
- les clés pour établir une connexion usuelle sécurisée mais simple du boulot
- les mots de passe pour un usage nomade

PS : J'ai bien reçu par mail la discussion au sujet de l'évolution de la
FAQ de fcolc et je vous répondrai à tous dans la journée.

Super :)
(pour ma part, mes machines tournent et me rapatrient mes mails perso sans
que je puisse les consulter... faute de ssh :) aussi je lirai tout ça ce
soir.)

Sébastien Kirche

Dans le message <news:m23c6ha9na.fsf@free.fr>,
*Sebastien Kirche* tapota sur f.c.o.l.configuration :

[...]

J'ai oublié de dire une chose. Pour tester que la connexion s'établit bien
ou non, il suffit d'utiliser un client telnet ou l'utilitaire netcat. Si la
connexion s'établit alors on devrait voir s'afficher le banner «
SSH-X.X-OpenSSH_X.X ». C'est d'ailleurs aussi un moyen de voir si la
connexion au port 80 s'établit via le proxy , ce dernier devrait alors
renvoyer des informations de type http reconnaissables.

--
TiChou

On 3 May 2004, TiChou wrote:

Dans le message <news:m23c6ha9na.fsf@free.fr>,
*Sebastien Kirche* tapota sur f.c.o.l.configuration :

[...]

J'ai oublié de dire une chose. Pour tester que la connexion s'établit bien
ou non, il suffit d'utiliser un client telnet ou l'utilitaire netcat. Si
la connexion s'établit alors on devrait voir s'afficher le banner
« SSH-X.X-OpenSSH_X.X ». C'est d'ailleurs aussi un moyen de voir si la
connexion au port 80 s'établit via le proxy , ce dernier devrait alors
renvoyer des informations de type http reconnaissables.

Bingo !

Je ne maîtrise pas netcat, par contre un telnet chez moi me retourne ceci :

[goudurix:~/] seki% telnet 80.170.xx.xx 80
Trying 80.170.xx.xx...
Connected to d80-170-xx-xx.cust.tele2.fr.
Escape character is '^]'.

Plutôt bon au premier abord (?), mais ensuite plus rien...

Et si je saisis par exemple «seki» présumant qu'il pourrait y avoir un
prompt non affiché (mmmh), j'obtiens... du html :) Dont le début indique
«HTTP/1.1 400 Bad Request»

J'en conclus qu'effectivement le proxy a intercepté ma connexion.
De plus je suis sûr qu'il n'y a pas de serveur web installé sur ma
passerelle, et je doute fortement que sshd retourne des messages formatés
en html :)

Sébastien Kirche