Accès SSH à l'hôte de bureau derrière le routeur NAT

Je voudrais accéder au port ssh de mon hôte Linux Office depuis mon domicile. Malheureusement, l'hôte est situé derrière un routeur NAT. Ainsi, l'adresse IP n'est pas accessible au public. Il y a cependant un accès à un autre hôte Internet (serveur) qui n'est malheureusement qu'un accès non root. Après un certain temps de recherche, je ne trouve pas de solution appropriée.

Configuration suivante:

• Office PC (linux, accès root) derrière NAT (IP non public) mais accès complet à Internet.
• Serveur PC (Linux, pas d'accès root) IP statique et publique et accès Internet complet.
• PC domestique (linux, accès root) derrière NAT (IP non public) mais accès complet à Internet.

Connexions possibles: PC de bureau -> Serveur <- PC domestique

Impossible: Office PC <-X- Server -X-> Home PC

Ni le PC domestique, ni le serveur ne peuvent initier l'accès au PC Office. Mais le PC de bureau et le PC domestique peuvent établir des connexions au serveur.

Tunnel SSH inverse impossible: j'ai essayé une méthode appelée tunnel ssh inverse. Malheureusement, cela nécessite que GatewayPorts sur le serveur soit défini sur "oui" dans / etc / ssh / sshd_config, où je n'ai pas d'accès root.

En principe, il devrait être possible:

0) Sur le serveur, je lance un programme d'espace utilisateur qui écoute sur 2 ports (1 entrant, 1 sortant)

1) Sur mon PC de bureau, j'exécute un autre programme qui maintient une connexion TCP ouverte au port sortant sur le serveur.

2) De chez moi, je me connecte au port entrant du serveur.

Il devrait y avoir une solution standard pour cela.

Quelle est la solution la plus rapide et la plus propre pour résoudre ce problème?

Franc

youatwork@officepc$ autossh -R 12345:localhost:22 notroot@serverpc

Plus tard:

you@homepc$ autossh -L 23456:localhost:12345 notroot@serverpc

you@homepc$ ssh youatwork@localhost -p 23456

Ce que vous pouvez faire est le suivant: à l'étape 1, transférez un port distant du PC de bureau au serveur ( 12345est utilisé comme exemple, tout port> 1024 devrait le faire). La connexion à 12345 sur le serveur devrait vous connecter au port 22 sur officepc.

À l'étape 2, transférez le port 23456 de votre ordinateur personnel vers 12345 sur le serveur (d'où il est transféré à officepc: 22, comme configuré à l'étape 1)

À l'étape 3, vous vous connectez au port local 23456 avec la connexion de votre ordinateur de bureau . Ceci est transmis à l'étape 2 au port 12345 de votre serveur et à l'étape 1 à votre PC de bureau.

Notez que j'utilise autossh pour les transferts, car c'est un wrapper ssh qui reconnecte automatiquement le tunnel s'il est déconnecté; cependant ssh normal fonctionnerait aussi bien, tant que la connexion ne tombe pas.

Il existe une vulnérabilité possible: toute personne qui peut se connecter à localhost: 12345 sur serverpc peut maintenant se connecter à officepc: 22 et essayer de le pirater. (Notez que si vous utilisez un serveur SSH, vous devez de toute façon le sécuriser au-dessus des protections de base qui sont activées par défaut; je recommande au moins de désactiver la connexion root et la désactivation de l'authentification par mot de passe - voir par exemple ceci )

Edit : j'ai vérifié cela avec la même config, et ça marche. GatewayPorts noaffecte uniquement les ports ouverts sur le monde dans son ensemble, pas les tunnels locaux. Voici les ports redirigés:

homepc:
  outgoing ssh to serverpc:22
  listening localhost:23456 forwarded through ssh tunnel
serverpc:
  listening ssh at *:22
  incoming localhost ssh tunnel (from homepc) forwarded to localhost:12345
  listening localhost ssh tunnel (from officepc) forwarded from localhost:12345
officepc:
  outgoing ssh to serverpc:22
  incoming localhost through ssh tunnel (from serverpc) forwarded to localhost:22

Donc, en ce qui concerne la pile réseau, c'est tout le trafic local sur les interfaces de bouclage respectives (plus les connexions ssh à serverpc); par conséquent, GatewayPortsn'est pas vérifié du tout.

Il y a cependant la directive AllowTcpForwarding: si c'est le cas no, cette configuration échouera car aucun transfert n'est autorisé du tout, pas même à travers l'interface de bouclage.

Mises en garde :

• si vous utilisez autossh et ssh récent, vous voudrez peut-être utiliser ssh ServerAliveIntervalet ServerAliveCountMaxpour garder le tunnel en place. Autossh a une vérification intégrée, mais apparemment, il y a des problèmes sur Fedora. -M0le désactive et -oServerAliveInterval=20 -oServerAliveCountMax=3vérifie si la connexion est active - essaie toutes les 20 secondes, s'il échoue 3 fois de suite, arrête ssh (et autossh en crée une nouvelle):

  autossh -M0 -R 12345:localhost:22 -oServerAliveInterval=20 -oServerAliveCountMax=3 notroot@serverpc
  
  autossh -M0 -L 23456:localhost:12345 -oServerAliveInterval=20 -oServerAliveCountMax=3 notroot@serverpc
  

• il peut être utile de redémarrer le tunnel ssh en cas d'échec du transfert, en utilisant -oExitOnForwardFailure=yes- si le port est déjà lié, vous pouvez obtenir une connexion SSH fonctionnelle, mais pas de tunnel transféré.

• il ~/.ssh/configest conseillé d' utiliser les options (et les ports), sinon les lignes de commande deviennent trop verbeuses. Par exemple:

  Host fwdserverpc
      Hostname serverpc
      User notroot
      ServerAliveInterval 20
      ServerAliveCountMax 3
      ExitOnForwardFailure yes
      LocalForward 23456 localhost:12345
  

Ensuite, vous pouvez utiliser uniquement l'alias du serveur:

    autossh -M0 fwdserverpc

Si vous pouvez ssh vers le serveur interne depuis votre domicile et du serveur interne vers votre machine Linux de bureau, vous pouvez utiliser le ssh ProxyCommandpour rebondir silencieusement via le serveur vers la machine interne via nc(netcat)

# ~/.ssh/config on your home machine:
Host internalpc 
   ForwardAgent yes 
   ProxyCommand ssh [email protected] exec nc internal.pc.example.com %p

Ensuite, vous venez ssh user@internalpcet vous êtes silencieusement transféré via la machine serveur, aucune ouverture de ports ou de tunnels requise à chaque extrémité.

Installez Robo-TiTO sur l'ordinateur auquel vous souhaitez accéder à distance à SSH.

• Cela vous permettra d'accéder à SSH à l'aide des applications clientes Google Talk n'importe où.
• Il n'est pas nécessaire d'avoir une adresse IP publique ou un paramètre spécial.
• C'est gratuit et open source, ne payant plus aucun service d'application.
• Pas besoin d'ouvrir le port SSH (gardez votre ordinateur en sécurité).
• Pas besoin d'ouvrir un tunnel (par exemple, VPN ou quelque chose comme ça)

Les instructions d'installation suivantes sont obsolètes, car le site a été déplacé. La nouvelle URL est https://github.com/formigarafa/robotito

J'ai fait un script (testé sur mon système d'exploitation Raspbian dans Raspberry Pi) afin que vous puissiez facilement installer Robo-TiTO sur Raspberry Pi, Debian ou Ubuntu Box (distribution de paquets Debian). voici les étapes pour obtenir votre box Linux à distance:

1. Ouvrez la commande Shell ou vous pouvez l'appeler Terminal, accédez à votre dossier de départ, téléchargez le script d'installation par commande:

   $ wget https://opengateway.googlecode.com/files/robotito
   

2. après cela, exécutez le script en entrant la commande:

   $ sudo ./robotito
   

3. puis vous pouvez modifier le fichier à credentials.rbpartir du dossier de configuration de Robo-TiTO en utilisant votre compte GTalk et l'enregistrer en appuyant sur Ctrl+ Xet Y. La valeur par défaut utilise l'éditeur nano.

4. exécution du Robo-TiTO à partir du dossier Robo-TiTO par commande

   $ cd robotito
   $ ./jabbershd start
   

5. Maintenant que cela est fait, vous pouvez utiliser SSH à partir de n'importe quel client Google Talk. N'oubliez pas d'ajouter le compte Robo-TiTO GTalk à votre compte Google Talk et testez-le en discutant avant d'utiliser le compte.

La solution de Piskvor fonctionne et est agréable. Cependant, il garde les terminaux ouverts et les coquilles de connexion suspendues. Pas très cool.

J'ai toujours utilisé ce petit script que j'ai écrit pour me connecter à un serveur et le garder connecté en l'exécutant dans cron:

#!/bin/bash
TARGET_HOST=${1:-myserver.example.com}
TARGET_PORT=${2:-7777}
TUNNEL_PORT=${3:-22}
T_USER="odin"

#Check that we have an active connection to the remote system
ACTIVE_PROCESS=`ps -ef | \
    grep "ssh $TARGET_HOST -l $T_USER -R $TARGET_PORT:127.0.0.1:$TUNNEL_PORT" | \
    grep -v grep | \
    wc -l`
if [ $ACTIVE_PROCESS -lt 1 ]; then
    echo "`date` : establishing connection to $TARGET_HOST on port $TARGET_PORT"
    screen -m -d ssh $TARGET_HOST -l $T_USER -R $TARGET_PORT:127.0.0.1:$TUNNEL_PORT > /dev/null
fi

Je parie que nous pourrions corriger la solution de Piskvor en utilisant l'autossh plus élégant à côté peut-être d'un écran détaché ou utiliser les arguments -NT ssh pour simplement maintenir la connexion en arrière-plan.

Pour moi, il semble que, au lieu d'un tunnel SSH, vous devriez essayer un VPN: le type qui fonctionne en utilisant un serveur à l'extérieur pour proxy, comme Hamachi . Il existe d'autres logiciels gratuits comme celui-ci, mais Hamachi est mon préféré.