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

Marco44

Bonjour, merci pour la réponse. J'avais d'autre questions du coup !
- Si je veux utiliser un VPN il faut que j'installe quoi ?
- Sinon dans le sshd_config si je change le port 22, ça veut dire que lorsque je voudrais me connecter sur le VPS en ssh pour l'administrer il faudra aussi que j'utilise ce nouveau port ?

Marco44

est-ce qu'il existe un auto avec OpenVPN ?

Marco44

Après quelques ajustement la solution rssh fonctionne à merveille, merci. 

vbr42

Bonjour

J'y suis presque mais je bloque sur la mise à jour de la crontab sur le Raspberry. Je ne suis pas sur d'avoir la bonne syntaxe avec cette commande, car je tombe sur une crontab qui a un champ user.

sudo nano /etc/crontab

J'ai quand meme mis à jour cette crontab avec

@reboot root export AUTOSSH_POLL; /usr/..............

Mais quand je tape

systemctl status cron

j'obtiens les erreurs suivantes 

ERROR: bad user name; while reading etc/crontab

D'ailleurs si je supprime le "root" de la ligne, j'obtiens la meme erreur...

Pourriez vous svp m'aider ? je pense que je n'édite pas le bon fichier. La bonne commande pour éditer le fichier serait elle ??

crontab -e

Merci

ludovick

oui c'est bien crontab -e

oga83

@vbr42

Normalement, cela devrait fonctionner.

Il y a 3 possibilités pour crontab :

1- Créer un fichier crontab spécifique à l'utilisateur avec "crontab -e":

Dans ce cas, il ne faut pas préciser l'utilisateur "root" :

@reboot export AUTOSSH_POLL; /usr/..............

2- Utiliser le crontab global au système en modifiant /etc/crontab.

Il faut bien préciser l'utilisateur :

@reboot root export AUTOSSH_POLL; /usr/..............

3- Sur une Debian ou similaire, plutôt que modifier /etc/crontab, il est préférable d'ajouter un nouveau fichier dans /etc/cron.d

Syntaxe identique à /etc/crontab

vbr42

Merci je vais continuer les tests. Sur le RPI je suis loggé avec le user « pi » et pas « root ». Le pb peut il venir de la ?

vbr42

J'ai continué mais sans succès. Je pense que la crontab est bien à jour mais me retourne une erreur 255 lorsque autossh essaye de se connecter. Alors qu'en dehors de la crontab, la connexion SSH avec la clé se fait bien... je suis un peu largué. 
Je vais recommencer le tuto mais si ça vous dit qqe chose je veux bien des infos. Notamment comment activer les logs SSH sur mon server. 
Merci

oga83

@vbr42

ça peut venir de l'environnement du crontab qui n'a pas un PATH complet (elles dépendent de l'utilisateur qui fait tourner le crontab).

Il faut essayer en indiquant les chemins en absolu comme '/usr/bin/autossh' et pas simplement 'autossh'.

Tu peux aussi rediriger stdin et stderr (dans ta commande autossh) vers un fichier pour voir ce qu'il se passe;

Pour les logs ssh, par défaut, tu les as dans /var/log/auth.log

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 

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

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. 

Merci

Vincent

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

AllowTcpForwarding yes

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

Merci

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 

sudo ssh -p 4003 -L 80:192.168.0.1:80 pi@mondomaineperso

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.