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

[TUTO] Accéder à son LAN derrière un routeur 4G, depuis l'extérieur, avec SSH

oga83 · 2019-08-15T13:36:05+00:00

Suite :B- Sur le client Raspberry 4G1- Modifier /etc/ssh/ssh_config (attention, pas sshd_config !) pour faciliter la récupération de la connexion en cas de c...

vbr42

Salut oga83.

J'espère que tu traînes encore un peu par la : pour le moment je fais mes tests en dehors de la crontab en ligne de commande direct (sachant que la commande "ssh revssh@host" fonctionne bien sans mot de passe). Si ça a une importance le NAS et le RPI sont pour le moment sur le meme réseau local...

Donc, dans auth.log sur mon NAS Synology je vois que je me fais jeter tout de suite :#

2021-07-10T14:58:52+02:00 DS216 sshd[21454]: pam_unix(sshd:session): session opened for user revssh by (uid=0) 2021-07-10T14:58:52+02:00 DS216 sshd[21454]: pam_unix(sshd:session): session closed for user revssh 2021-07-10T14:59:08+02:00 DS216 sshd[21484]: pam_unix(sshd:session): session opened for user revssh by (uid=0) 2021-07-10T14:59:08+02:00 DS216 sshd[21484]: pam_unix(sshd:session): session closed for user revssh 2021-07-10T14:59:23+02:00 DS216 sshd[21540]: pam_unix(sshd:session): session opened for user revssh by (uid=0) 2021-07-10T14:59:23+02:00 DS216 sshd[21540]: pam_unix(sshd:session): session closed for user revssh 2021-07-10T14:59:38+02:00 DS216 sshd[21553]: pam_unix(sshd:session): session opened for user revssh by (uid=0) 2021-07-10T14:59:38+02:00 DS216 sshd[21553]: pam_unix(sshd:session): session closed for user revssh 2021-07-10T14:59:53+02:00 DS216 sshd[21581]: pam_unix(sshd:session): session opened for user revssh by (uid=0) 2021-07-10T14:59:53+02:00 DS216 sshd[21581]: pam_unix(sshd:session): session closed for user revssh 2021-07-10T15:00:08+02:00 DS216 sshd[21595]: pam_unix(sshd:session): session opened for user revssh by (uid=0) 2021-07-10T15:00:08+02:00 DS216 sshd[21595]: pam_unix(sshd:session): session closed for user revssh 2021-07-10T15:00:23+02:00 DS216 sshd[21632]: pam_unix(sshd:session): session opened for user revssh by (uid=0) 2021-07-10T15:00:23+02:00 DS216 sshd[21632]: pam_unix(sshd:session): session closed for user revssh

Les tentatives de connexion à répétition, c'est le comportement de autossh ? Ensuite, quand je lis sur le raspberry ce que j'ai redirigé (stderr je crois) je vois ça. je ne sais pas ou ce port 91 doit être ouvert, alors dans le doute je l'ai ouvert sur le routeur (Freebox) et dans le firewall du NAS.

Error : remote port forwarding failed for listen port 91

Et dans ce meme fichier j'ai aussi parfois (!) l'erreur

Error : remote port forwarding failed for listen port 20000

Pour finir, dans autossh.log j'ai des milliers de

ssh exited with error status 255; restarting ssh

ou plus rarement

ssh exited prematurely with status 255; autossh exiting

Si une âme charitable passe par la... j'aimerais vraiment venir à bout de ce truc. MerciVincent

vbr42

Alors je pense avoir trouvé car j'arrive à faire des redirections sur le réseau local. Le truc qui a tout changé c'est d'ajouter dans ssh_config
<pre class="CodeBlock">AllowTcpForwarding yes</pre>Je veux bien un avis car c'est un truc qui n'apparait pas dans le tutorial. Pourquoi ai je besoin de ça ?Merci :smiley:

oga83

vbr42 a dit :

J'espère que tu traînes encore un peu par la

Oui, bien-sûr. Sinon, je n'aurais pas répondu à ta question précédente 37 minutes après ton message ;)

vbr42 a dit :

Les tentatives de connexion à répétition, c'est le comportement de autossh ?

Le principe d'autossh est de maintenir la connexion. D'où les tentatives de connexion à répétition.

vbr42 a dit :

Je veux bien un avis car c'est un truc qui n'apparait pas dans le tutorial. Pourquoi ai je besoin de ça ?

La valeur par défaut de AllowTcpForwarding est 'yes' ('man sshd_config' pour le vérifier).

C'est la raison pour laquelle il n'apparait pas dans le tutoriel.

vbr42

Ahhhhh top merci. je continue les tests. sur le Synology la valeur par défaut semble être à "no".
Hier j'ai eu l'impression que la redirection fonctionnait toujours alors que j'avais coupé le server SSH du NAS...

vbr42

alors je confirme, ça fonctionne. meme quand je coupe le server SSH après avoir établi la connexion... donc je ne comprends pas.

oga83

C'est normal. Arrêter le service n'arrête pas les processus sshd en cours. Seules les nouvelles connexions sont bloquées. Pour interrompre les connexions existantes, il faut tuer les processus sshd (par exemple, avec un pkill).

vbr42

alors écoute, c’est tout simplement génial ! Tout marche nickel. Y compris après reboot du NAS ou du Rpi.

Je suis enchanté. Je n’aurais jamais pensé y arriver !!!!

Merci beaucoup

vbr42

Cela dit je veux bien un indice pour l’accès à la console d’admin du routeur HUAWEI. je pense que j’aurai le même problème pour l’accès à l’interface de ma camera AXIS 😇

J’imagine qu’il faut suivre la 2ème partie du tuto et faire un SSL -L xxxx sur le serveur ami… mais c’est apparemment insuffisant ?

merciii

oga83

vbr42 a dit :

J’imagine qu’il faut suivre la 2ème partie du tuto et faire un SSL -L xxxx sur le serveur ami… mais c’est apparemment insuffisant ?

Oui, un -L 80:192.168.1.1:80 devrait faire l'affaire.

sauf qu'il y a un piège...

oga83 a dit :

Pour avoir accès à l'interface wb d'un routeur Huawei, il y a un petit piège lié à une redirection html vers une url absolue. Si vous avez suivi jusque ici, vous saurez certainement le résoudre ;)

Les routeurs Huawei comportent, à mon sens, une erreur de conception dans leur site web embarqué.

Normalement, les liens locaux d'un site web sont toujours exprimés en relatif (par exemple /page.html et pas http://nomdedomainOuAdresse/page.html).

Ce n'est pas le cas des routeurs Huawei qui retournent les liens en absolu avec leur adresse IP (LAN) en dur (par exemple http://192.168.1.1/html/index.html). Ce n'est pas gênant en local mais cela ne fonctionne pas en distant (où l'adresse apparente du routeur est différente)

Du coup, en invoquant http://127.0.0.1:80 avec ssh, le routeur redirige vers http://192.168.1.1... qui n'est pas sur le même LAN.

2 solutions :

- Utiliser un plugin (comme Requestly) pour modifier les url retournées par le routeur (192.168.1.1 modifié en 127.0.0.1)

- ou plus simple, mais pas toujours possible en fonction de sa topologie réseau : utiliser la même adresse réseau que le LAN distant (192.168.1.0/24) et forcer l'adresse IP de son PC à 192.168.1.1 (identique à celle du routeur distant). De cette manière, en invoquant 192.168.1.1:80 sur son PC, on est redirigé par ssh sur 192.168.1.1:80 sur le site distant où se trouve le routeur. Et les liens en durs retournés par le routeur fonctionnent :) C'est la solution que j'utilise pour tous mes sites distants équipés de routeur Huawei.

vbr42

Génial merci. Je vais mettre le LAN de la maison de campagne sur les mêmes adresse que chez moi. Mais il faut qd même faire un -L 80:192.168.1.1:80 sur le serveur ami ? Donc dans ton exemple le routeur HUAWEI doit être sur 192.168.1.1 et mon NAS également ?

oga83

vbr42 a dit :

Mais il faut qd même faire un -L 80:192.168.1.1:80 sur le serveur ami ?

Non. Le serveur ami ne sert qu'à avoir un point d'entrée : un PC à l'extérieur peut faire un ssh et avoir accès à des équipements sur le LAN du Rpi avec des redirections de ports (-L).

Le -L 80:192.168.1.1:80 sur un PC externe (dont l'adresse IP est 192.168.1.1) redirige les requêtes http locales vers le routeur distant.

vbr42 a dit :

Donc dans ton exemple le routeur HUAWEI doit être sur 192.168.1.1 et mon NAS également ?

Non. Regarde les schémas du tuto pour bien comprendre comment ça marche.

vbr42

ok je regarde merci. Je n’ai pas encore installé le rpi à la campagne donc pas de test possible. Je fais ça bientôt

vbr42

Hello

J'abdique.

Un Mac de mon réseau local est configuré en 192.168.0.1. C'est également l'IP de mon routeur 4G sur le réseau distant.

Sur ce Mac local je fais un <pre class="CodeBlock">sudo ssh -p 4003 -L 80:192.168.0.1:80 pi@mondomaineperso</pre>ce qui ouvre un shell SSH sur le raspberry derriere le routeur 4G. Je mets le "sudo" car sans, j'ai un message d'erreur sur le port 80.

et qd je tape 127.0.0.1:80 sur le Mac local, il me redirige sur "http://192.168.0.1/html/index.html?origin=aHR0cDovLzEyNy4wLjAuMS8= " avec un message d'erreur "ce site est inaccessible"

et qd je tape 192.168.0.1:80 j'ai simplement "site inacessible"...

:#

oga83

ça devrait marcher, sauf si un autre process a déjà fait un bind sur le port 80 de l'adresse locale 192.168.0.1 du mac. Dans ce cas, l'appel à 127.0.0.1 passerait par le tunnel ssh, mais pas celui à 192.168.0.1

Tu peux tenter un -L *:80:192.168.0.1:80 pour forcer un bind sur toutes les interfaces et voir s'il y a une erreur.

Sinon, voir les logs et la console dev du browser pour voir ce qui se passe.

vbr42

Merci.
Alors en remplaçant mon -L 80:192.168.0.1:80 par ton -L *:80:192.168.0.1:80, ça marche :) je n'ai pas d'erreur et je vois l'interface du routeur sur 192.168.0.1:80 et aussi sur 127.0.0.1:80
dois je creuser pour comprendre ou on s'en fout ?

oga83

Pour des raisons de sécurité, ssh -L 80:192.168.0.1:80 ne fait un bind que sur l'interface loopback 127.0.0.1.
L'ajout du * le fait également sur l'interface réseau 192.168.0.1.
Ce n'est pas le cas de tous les clients ssh : la version de Putty que j'utilise avec Windows fait le bind sur toutes les interfaces.

vbr42

Salut.

J'ai eu pas mal le temps de tester le tunnel et ça marche bien, c'est robuste. mais dernièrement ça rame sec et je n'arrive presque plus à accéder à mon LAN distant.
Y a t t il des opérations de maintenance, des process à killer pour repartir à 0 ? Sur mon NAS en root il y a les process SSH suivants

root 6054 0.2 0.2 198592 9176 ? Ss 18:44 0:00 sshd: revssh [priv]

root 6057 0.0 0.0 198592 2708 ? S 18:44 0:00 sshd: revssh@pts/0

revssh 6058 0.0 0.0 26472 2444 pts/0 Ss 18:44 0:00 -sh

root 6074 0.3 0.2 198592 9176 ? Ss 18:45 0:00 sshd: vbr_adm [priv]

root 6077 0.0 0.0 198592 2696 ? S 18:45 0:00 sshd: vbr_adm@pts/1

revssh 6091 0.0 0.0 25380 1320 pts/0 R+ 18:45 0:00 ps aux

revssh 6092 0.0 0.0 23220 964 pts/0 S+ 18:45 0:00 grep --color=auto ssh

root 17023 0.0 0.1 151804 6372 ? Ss Aug26 0:00 sshd: /usr/bin/sshd -D [listener] 0 of 10-100 startups

root 31793 0.0 0.2 198520 8632 ? Ss 16:37 0:00 sshd: revssh [priv]

root 31796 1.6 0.0 199272 3596 ? S 16:37 2:06 sshd: revssh

Je trouve qu'il y bcp de trucs avec le user REVSSH. Est ce normal ?

Merci

oga83

ça dépend du nombre de clients connectés, héhé.

Pour chaque couple sshd [priv]/sshd, il y a 1 connexion.

Le [priv] montre que la séparation des privilèges est bien active (UsePrivilegeSeparation dans sshd_config).

Ici, il y a 2 connexions actives.

« Page précédente