Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

[RESOLU] reverse SSH configuration

thierryR

Bonjour. J'ai un petit souci de configuration en reverse SSH. Je vous joins un dessin. J'espère qu'il sera explicite. La connexion ne fonctionne pas en reverse. Je me mélange un peu les pinceaux. (C'est ma 1ere)

réseau thierry.pdf

23.134kB

réseau thierry.pdf

23.134kB

dupratpierre11

bonjour Thierry,

Dur de répondre avec les infos fournies...

Pourquoi veux tu faire du "reverse ssh" ?

tu n'as pas possibilité de configurer du "port forwarding" sur la BOX-Fibre ?

Attention chez certain opérateur (Free par exemple) :

Sur le cœur de réseau 4g les PDN gateways n'allouent pas aux équipements mobiles (ton routeur 4g) d'adresse IP publique (redoutable sur Internet). Tu ne pourras donc pas initier de conversation IP (depuis ton rasberry derrière la box-fibre) vers ta machine "PC thierry" (qui est derrière ta box 4G).Si c'est ton cas de figure, tu seras obligé de configurer de la redirection de port sur ta box-fibre pour que ton rasberry soit accessible en ssh depuis Internet (est donc ne plus faire de "reverse ssh")...

dupratpierre11

Ci-après, un complément d’information essayant d’expliquer pourquoi ta construction réseau actuelle ne peut fonctionner (si ta Box-4G n'a pas d'@IP publique sur sa patte WAN) :

Sur le cœur de réseau 4G, la fonction de NAT de type NAPT (suivant la terminologie RFC 2663 : le NAT présent sur nos box Internet en somme) est soit portée par la passerelle PGW ou soit par un équipement en aval (c.à.d. plus près du réseau public) : un CGN (carrier Grade NAT)

Cet équipement Nattant (PGW ou CGN), portant ton adresse IP publique sur son interface publique, lorsqu’il va recevoir le paquet IP que lui adresse ton rasberry (paquet qui a bien sûr au préalable été source-natté par ta box-fibre à la traversé de celle-ci), ne sera pas quoi faire de ce paquet.

Il aurait fallu pour qu’il en soit autrement, qu’une règle de NAT unidirectionnelle de type 1 pour 1 avec éventuellement translation de port (l’équivalent du port forwarding de nos box) soit spécifiquement implémentée pour toi sur l’équipement opérateur (ce qui n’est pas le cas bien sûr !)

Conclusion : tout paquet IP initiant un nouvel échange et envoyé par ton rasberry à destination de ton réseau (celui qui est derrière ta box 4G) sera stoppé par cet équipement Nattant.

thierryR

Bonjour et merci de vos indications. Je vais essayer d'en dire plus. (Je ne suis pas informaticien) L'IP externe de ma box 4G est aujourd'hui 37.171.84.94%. Cette adresse n'est pas public. Pour contourner ce problème il y a 2 solutions. Soit faire un VPN, soit faire du reverse SSH. Étant plus à l'aise dans le SSH j'ai tenté la 2e solution. Du simple SSH (en jaune dans la diapo4) fonctionne parfaitement. Je partais du principe que si j'ouvre une liaison dans un sens, on peut l'utiliser dans l'autre. Là vous me mettez le doute... Serais je dans l'erreur ? Pour en arriver là je me suis servi d'un tuto d'ici. Ce tuto utilise des IP qui ne sont pas celles indiquées sur les illustrations.J'ai donc pleins d'hésitations, mais j'aimerais quand même essayer.

https://routeur4g.fr/discussions/discussion/1882/tuto-acceder-a-son-lan-derriere-un-routeur-4g-depuis-lexterieur-avec-ssh Ce que j'ai fait au niveau fonctionnement:Le tout commence dans le crontab au boot:

@reboot    root    export AUTOSSH_POLL=30; /usr/lib/autossh/autossh -M 20000 -C -N -f -n -T -p 1957 -R \*:1922:192.168.8.57:22 revssh@sauvegarde:1957

Là je ne sais pas si la communication est établie. Comment la vérifier ?
Si je refais une 2e liaison SSH vers le "raspi thierry" sur le port 1957, est ce que je ne vais pas faire disjoncter ma 1ere connexion? Dans ce schéma, je demande au "PC isabelle" de se connecter sur le "raspi thierry" sur le port 1922. Normalement, je devrais passer le tunnel, mais encore une fois: Comment vérifier ?

oga83

@dupratpierre11 C'est certainement la raison pour laquelle il veut faire du reverse-ssh

@thierryR Tu as déjà lu ce tuto, mais tu n'as pas répondu à cette question. Difficile de t'aider sans plus de précisions...

[EDIT] Nos posts ont été faits quasiment en même temps et je n'avais pas vu le tien...

oga83

@thierryR

Tu as bien compris le principe. L'idée est d'effectuer une connexion sortante ssh et de créer un tunnel 'reverse' pour pouvoir effectuer des connexions entrantes (et contourner la restriction du réseau privé).

Ta commande crontab effectue une connexion ssh vers le serveur 'sauvegarde' et crée un tunnel (sur le port 1922) vers ton serveur local (port 22).

Comment le vérifier ?

- Vérifie d'abord que le serveur ssh local fonctionne bien avec ton user revssh avec "ssh revssh@serveurlocal"

- Si tu fais un "ps -ef | grep ssh", tu dois trouver ta commande ssh (lancée par autossh)

- Si tu fais un "nmap -sT -p 1922 sauvegarde", il doit te dire que le port est ouvert.

- Si tu fais un "ssh -p 1922 sauvegarde", tu dois être capable de te connecter en ssh au serveur local (celui où tu as configuré autossh) : le port 1922 est routé vers le port 22 du serveur local

Supprime le :1957 à la fin de ta commande crontab. Le port est déjà indiqué avec l'option -p.

oga83

Par ailleurs, il est fortement recommandé de configurer le serveur ssh pour qu'il n'accepte que les connexions par clef privée. Il y a plein de tutos sur le net. En résumé :

- créer une clef sur le client : ssh-keygen -t rsa

- copier la clef publique sur le serveur dans authorized_keys

- ajuster sshd_config sur le serveur avec "RSAAuthentication yes", "PubkeyAuthentication yes" et "StrictModes yes"

thierryR

Merci oga83. Je traîne depuis longtemps dans les liaisons SSH et je limite, les user ( AllowUser) puis je fonctionne uniquement par clé. Toutes les clés fonctionnent. Je vais me servir de tes indications pour faire des vérifications. Je reviens.

thierryR

1) J'ai corrigé le crontab comme indiqué.

ssh revssh@sauvegarde -p1957
revssh@sauvegarde: Permission denied (publickey).

Serait ce du au fait que revssh ne peut pas se loguer ( Modif du passwd) ? pourtant une clé lui a été fournie. Elle est dans son /home, mais du fait de sa configuration, il me semble qu'il n'accède à aucun /home/

thierryR

Je crois avoir une bonne nouvelle

 sudo nmap -sT -p 1922 sauvegarde
Starting Nmap 7.70 ( https://nmap.org ) at 2020-02-21 14:09 CET
Nmap scan report for sauvegarde (93.9.196.72)
Host is up (0.062s latency).

PORT     STATE    SERVICE
1922/tcp filtered tapestry

thierryR

Et ça doit être là que ça coince

 ssh -p 1922 sauvegarde
ssh: Could not resolve hostname sauvegarde: No address associated with hostname

oga83

thierryR a dit :
ssh revssh@sauvegarde -p1957
revssh@sauvegarde: Permission denied (publickey).

Pour la clef, le mieux est d'ajouter l'option -i dans la ligne autossh du crontab (du style "-i /home/user/.ssh/clef.privee"). Comme ça, tu sais exactement quelle clef il va chercher.

thierryR a dit :

Et ça doit être là que ça coince
 ssh -p 1922 sauvegarde
ssh: Could not resolve hostname sauvegarde: No address associated with hostname

Pour la résolution du nom, soit tu utilises un nom dns, soit, si tu es en local, une ligne dans /etc/hosts, soit directement l'adresse ip. Pour essayer, essaye directement avec l'adresse ip.

thierryR a dit :

Je crois avoir une bonne nouvelle
 sudo nmap -sT -p 1922 sauvegarde
Starting Nmap 7.70 ( https://nmap.org ) at 2020-02-21 14:09 CET
Nmap scan report for sauvegarde (93.9.196.72)
Host is up (0.062s latency).

PORT     STATE    SERVICE
1922/tcp filtered tapestry

Pas vraiment une bonne nouvelle... le port devrait être en "open", pas "filtered" :

# nmap -sT -p 22 127.0.0.1
Starting Nmap 6.47 ( http://nmap.org ) at 2020-02-21 17:13 CET
Nmap scan report for localhost (127.0.0.1)
Host is up (0.0027s latency).
PORT   STATE SERVICE
22/tcp open  ssh

thierryR

A force de creuser, je vais trouver du pétrole. Voici en détail ce que j'ai fait.

Depuis "raspi isabelle"

autossh -M 20000 -C -N -f -n -T -R \*:1922:192.168.8.56:22 revssh@sauvegarde -p1957

J'ai vérifié la commande:

ps -ef | grep ssh
root       348     1  0 14:43 ?        00:00:00 /usr/sbin/sshd -D
pi         507   466  0 14:44 ?        00:00:00 /usr/bin/ssh-agent x-session-manager
pi         553     1  0 14:44 ?        00:00:00 /usr/bin/ssh-agent -s
root       848   348  0 14:45 ?        00:00:00 sshd: thierry [priv]
thierry    850   848  0 14:45 ?        00:00:00 sshd: thierry@pts/0
thierry   1211     1  0 17:23 ?        00:00:00 /usr/lib/autossh/autossh -M 20000 -C -N    -n -T -R *:1922:192.168.8.56:22 revssh@sauvegarde -p1957
thierry   1240   852  0 17:29 pts/0    00:00:00 grep --color=auto ssh

Puis je suis allé sur "PC isabelle"

nmap -sT -p 1922 192.168.1.57
Starting Nmap 7.80 ( https://nmap.org ) at 2020-02-21 17:30 CET
Nmap scan report for sauvegarde (192.168.1.57)
Host is up (0.00078s latency).

PORT     STATE SERVICE
1922/tcp open  tapestry

Nmap done: 1 IP address (1 host up) scanned in 0.07 seconds

Apparemment tout semble bon jusque là. Alors je me suis lancé du PC isabelle

ssh -p 1922 sauvegarde
Linux raspi-thierry 4.19.75+ #1270 Tue Sep 24 18:38:54 BST 2019 armv6l

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Fri Feb 21 17:24:27 2020 from 192.168.1.205
isabelle@raspi-thierry:~ $

Raté, je n'ai pas passé le tunnel.

Serait ce du au fait que j'ai ouvert le port 1922 dans sshd_config ?

dupratpierre11

Je n’ai jamais pratiqué l’option –R de SSH, mais je me lance qd même dans quelques explications :) Sommes-nous d’accord avec celles-ci ? Vos remarques et corrections sont les biens venues.

@ip RASPI-isa = 192.168.8.57 (et pas .56 comme sur ton schéma…) Non ?

@ip RASPI-thierry = 192.168.1.57

autossh -M 20000 -C -N -f -n -T -p 1957 –R *:1922:192.168.8.57:22 revssh@sauvegarde Cette commande crée une connexion SSH sur la machine « rapi-thierry » sur le port 22. (« sauvegarde » est résolu en l’adresse IP publique fixe de la box-fibre). La box fibre réalise du « port forwarding » pour le trafic venant du WAN comme cela :

@ip public de la box fibre:1957 -> 192.168.1.57:22

Cette connexion SSH va par la suite servir de tunnel (SSH) pour encapsuler une autre connexion TCP (initié, celle-là, depuis le site derrière la box-fibre).

Ainsi toutes connections TCP, d’un hôte du réseau derrière la box-fibre, sur le port 1922 de « raspi-thierry» est forwardé au travers du tunnel ssh, monté préalablement, jusqu’à l’hôte 192.168.8.57 sur le port 22.

Tant que le tunnel reste UP et en se situant sur le site derrière la box fibre, pour se connecter en TCP sur le "raspi isa" (192.168.8.57:22) il suffit de se connecter au port 1957 du rasberry local au site (le rapi-thierry)

et bien sur un démon SSH est à l’écoute sur le port 22 de "raspi isa"

Ainsi en étant sur le "Raspi-Thierry" pour ouvrir un shell distant sur le "Raspi-isa" il suffit de lancer la commande :

ssh -p 1922 localhost ou bien ssh -p 1922 192.168.1.57

on est d'accord ?

PS : ton serveur local pourrait dans l'absolu être n'importe que serveur sur le site derrière la box 4G. Mais dans ton cas de figure tu as choisi serveur local = "raspi isa"

Finalement ton besoin est donc bien de pouvoir ouvrir un shell distant vers "raspi isa" depuis "raspi thierry" ou bien depuis "PC isabelle"?

oga83

dupratpierre11 a dit :

Finalement ton besoin est donc bien de pouvoir ouvrir un shell distant vers "raspi isa" depuis "raspi thierry" ?

La finalité est d'ouvrir des ports accessibles de l'extérieur via un serveur tiers public.

On peut s'en servir pour ouvrir un shell mais c'est juste un cas particulier.

Ici, ssh est principalement utilisé pour créer des reverse-tunnels (c'est à dire un tunnel extérieur->intérieur qui est initiée de l'intérieur).

Voir le tuto sur reverse-ssh.

Pour une utilisation en partage de port sans shell, il est généralement conseillé de paramétrer l'utilisateur utilisé en nologin, ou encore mieux, en rssh (cela permet de faire du scp, rsync, sftp, ... sans shell).

oga83

thierryR a dit :

Serait ce du au fait que j'ai ouvert le port 1922 dans sshd_config ?

Tu as certainement répondu toi même à ta question :)

Un paquet qui arrive sur le port 1922 ne peut aller qu'à un seul endroit : sshd ou ton tunnel.

Si le port 1922 est pris par sshd, ton reverse tunnel ne peut pas être créé.

Tu devrais avoir un warning si tu lances "ssh -R" pour créer le tunnel à la main (au lieu de crontab).

Un petit schéma serait le bienvenu, car mélanger les noms ("raspi-xxx"), hostname ("sauvegarde") et adresse ip n'est pas facile à suivre

oga83

@thierryR

Tu as bien compris que pour que tes reverse-tunnels fonctionnent de l'extérieur, il faut que le serveur utilisé en relais soit accessible de l'extérieur ?

Comme "Serveur externe" sur ce schéma :

thierryR

dupratpierre11 a dit :

Je n’ai jamais pratiqué l’option –R de SSH, mais je me lance qd même dans quelques explications :) Sommes-nous d’accord avec celles-ci ? Vos remarques et corrections sont les biens venues.

@ip RASPI-isa = 192.168.8.57 (et pas .56 comme sur ton schéma…) Non ? La bonne

@ip RASPI-thierry = 192.168.1.57

autossh -M 20000 -C -N -f -n -T -p 1957 –R *:1922:192.168.8.57:22 revssh@sauvegarde Cette commande crée une connexion SSH sur la machine « rapi-thierry » sur le port 22. (« sauvegarde » est résolu en l’adresse IP publique fixe de la box-fibre). La box fibre réalise du « port forwarding » pour le trafic venant du WAN comme cela :

@ip public de la box fibre:1957 -> 192.168.1.57:22

Cette connexion SSH va par la suite servir de tunnel (SSH) pour encapsuler une autre connexion TCP (initié, celle-là, depuis le site derrière la box-fibre).

Ainsi toutes connections TCP, d’un hôte du réseau derrière la box-fibre, sur le port 1922 de « raspi-thierry» est forwardé au travers du tunnel ssh, monté préalablement, jusqu’à l’hôte 192.168.8.57 sur le port 22.

Tant que le tunnel reste UP et en se situant sur le site derrière la box fibre, pour se connecter en TCP sur le "raspi isa" (192.168.8.57:22) il suffit de se connecter au port 1957 du rasberry local au site (le rapi-thierry)

et bien sur un démon SSH est à l’écoute sur le port 22 de "raspi isa"

Ainsi en étant sur le "Raspi-Thierry" pour ouvrir un shell distant sur le "Raspi-isa" il suffit de lancer la commande :

ssh -p 1922 localhost ou bien ssh -p 1922 192.168.1.57

on est d'accord ?

PS : ton serveur local pourrait dans l'absolu être n'importe que serveur sur le site derrière la box 4G. Mais dans ton cas de figure tu as choisi serveur local = "raspi isa"

Finalement ton besoin est donc bien de pouvoir ouvrir un shell distant vers "raspi isa" depuis "raspi thierry" ou bien depuis "PC isabelle"?

Bonjour Pierre. Je vois que tu es quelqu'un de pointu. J'espère que tu me pardonnera mon inexpérience, compensée par ma curiosité....

Je te confirme quelques paramètres.

@ip RASPI-isa = 192.168.8.56

@ip RASPI-thierry = 192.168.1.57

/usr/lib/autossh/autossh -M 20000 -C -N -n -T -R *:1922:192.168.8.56:22 revssh@sauvegarde -p1957
@ip public de la box fibre:1957 -> 192.168.1.57:22

Ainsi en étant sur le "Raspi-Thierry" pour ouvrir un shell distant sur le "Raspi-isa" il suffit de lancer la commande :

ssh -p 1922 localhost ou bien ssh -p 1922 192.168.1.57

OK en théorie. Dans la pratique ça coince, et je trouve pas l'erreur. Comme c'est compliqué à expliquer j'ai fait un dessin.

La même commande depuis PC isabelle serait

ssh isabelle@192.168.1.57 -p1922

On est d'accord ?

Pour @oga83, je retire le port 1922 de sshd.

Sur RASPI-thierry

ssh -p 1922 localhost
ssh: connect to host localhost port 1922: Connection refused

diapo4.pdf

16.015kB

diapo4.pdf

16.015kB

oga83

@thierryR

Ton schéma est assez clair.

Ta commande reverse-ssh semble correcte : tu crée un tunnel entre raspi-thierry:1922 et Raspi-Isa:22

Le fait que la connexion sur sauvegarde à partir du PC isabelle ne passe pas le tunnel montrait bien que le sshd sur Raspi-Isa interceptait le port. Si tu l'as supprimé du sshd_config, ça devrait maintenant marcher.

Pour trouver où ça coince, utilise netstat sur raspi-thierry pour voir qui ouvre le port 1922.

Vérifie également que la redirection de port sur la box fibre est correcte (1957 -> raspi-thierry:1922, c'est à dire le port sshd de raspi_thierry).

As-tu essayer de lancer le "ssh -R ..." à la main depuis Raspi-Isa pour vérifier que le tunnel est créé ?

Juste un détail mais qui n'explique pas le non-fonctionnement : tu peux simplifier ta commande autossh avec -R *:127.0.0.1:22 puisque tu pointes vers localhost (127.0.0.1 <=> 192.168.8.56 sur Raspi-Isa).

thierryR

Je suis obligé d'arrêter pour ce soir. Mon cerveau est en train de s'endormir. Bonne nuit.

Page suivante »