Accueil Divers
routeur4g.fr est financé par ses lecteurs. Quand vous achetez en passant par les liens du site, nous pouvons toucher une commission d’affiliation.

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

2»

Réponses

  • Marco44Marco44 Membre Messages: 5
    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 ?
  • Marco44Marco44 Membre Messages: 5
    est-ce qu'il existe un auto avec OpenVPN ?
  • Marco44Marco44 Membre Messages: 5
    Après quelques ajustement la solution rssh fonctionne à merveille, merci. 
  • vbr42vbr42 Membre Messages: 33
    Modifié (juillet 2021)
    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  :s
    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 :smiley:

  • ludovickludovick Membre Messages: 8188
    oui c'est bien crontab -e
  • oga83oga83 Membre Messages: 1121
    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
  • vbr42vbr42 Membre Messages: 33
    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 ?
  • vbr42vbr42 Membre Messages: 33
    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
  • oga83oga83 Membre Messages: 1121
    ç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



  • vbr42vbr42 Membre Messages: 33
    Modifié (juillet 2021)
    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




    Message edité par vbr42 on
  • vbr42vbr42 Membre Messages: 33
    Modifié (juillet 2021)
    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 :smiley:

    Message edité par vbr42 on
  • oga83oga83 Membre Messages: 1121
    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.

  • vbr42vbr42 Membre Messages: 33
    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...
  • vbr42vbr42 Membre Messages: 33
    alors je confirme, ça fonctionne. meme quand je coupe le server SSH après avoir établi la connexion... donc je ne comprends pas.
  • oga83oga83 Membre Messages: 1121
    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).
  • vbr42vbr42 Membre Messages: 33
    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
  • vbr42vbr42 Membre Messages: 33
    Modifié (juillet 2021)
    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
    Message edité par vbr42 on
  • oga83oga83 Membre Messages: 1121
    Modifié (mars 2023)
    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.


    Message edité par pioc34 on
  • vbr42vbr42 Membre Messages: 33
    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 ?
  • oga83oga83 Membre Messages: 1121
    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. 




  • vbr42vbr42 Membre Messages: 33
    ok je regarde merci. Je n’ai pas encore installé le rpi à la campagne donc pas de test possible. Je fais ça bientôt 
  • vbr42vbr42 Membre Messages: 33
    Modifié (juillet 2021)
    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"...

     :# 

  • oga83oga83 Membre Messages: 1121
    ç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.

  • vbr42vbr42 Membre Messages: 33
    Modifié (juillet 2021)
    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 ?
  • oga83oga83 Membre Messages: 1121
    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.
  • vbr42vbr42 Membre Messages: 33
    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
  • oga83oga83 Membre Messages: 1121
    ç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.


Connectez-vous ou Inscrivez-vous pour répondre.