web-dev-qa-db-fra.com

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

Je souhaite accéder au port ssh de mon bureau Linux Host depuis mon domicile. Malheureusement, l'hôte est situé derrière un routeur NAT. Donc, l'adresse IP n'est pas publiquement disponible. Il existe cependant un accès à un autre hôte Internet (serveur) qui, malheureusement, n’est qu’un accès non root. Après un moment de recherche, je ne trouve pas de solution appropriée.

Après la configuration:

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

Connexions possibles: PC Office -> Serveur <- PC domestique

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

Ni le PC domestique, ni le serveur ne peuvent initier un accès au PC Office. Cependant, le PC Office et le PC domestique peuvent établir des connexions au serveur.

Inverser le tunnel SSH impossible: j'ai essayé une méthode appelée reverse ssh-tunnel. Malheureusement, GatewayPorts on Server doit être défini sur "yes" 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 utilisateur qui écoute sur 2 ports (1 entrant, 1 sortant)

1) Sur mon ordinateur de bureau, je lance un autre programme qui maintient une connexion TCP ouverte sur le port sortant du 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

linuxsshfirewallnatssh-tunnel
31
ritter
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

Voici ce que vous pouvez faire: à l’étape 1, transmettez un port distant du PC de bureau au serveur (12345 est utilisé à titre d’exemple, tout port supérieur à 1024 devrait suffire). Maintenant, vous connecter à 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 transmis à officepc: 22, comme indiqué à l'étape 1).

À l'étape 3, vous vous connectez au port local 23456 avec le login de votre ordinateur de bureau . Cette étape est transmise par l’étape 2 au port 12345 de votre serveur et par l’étape 1 à votre ordinateur de bureau.

Notez que j'utilise autossh pour les redirections, car c'est un wrapper ssh qui reconnecte automatiquement le tunnel s'il devait être déconnecté; Cependant, ssh normal fonctionnerait aussi bien, tant que la connexion ne sera pas abandonnée.

Il existe une vulnérabilité possible: toute personne pouvant se connecter à localhost: 12345 sur serverpc peut désormais se connecter à officepc: 22 et tenter de la pirater. (Notez que si vous utilisez un serveur SSH, vous devez quand même le sécuriser au-dessus des protections de base activées par défaut; je recommande au moins de désactiver le login root et l’authentification par mot de passe - voir par exemple ceci )

Edit : J'ai vérifié cela avec la même configuration, et ça marche. GatewayPorts no n'affecte que les ports ouverts au monde entier, pas les tunnels locaux. Voici ce que sont les ports transféré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

Ainsi, en ce qui concerne la pile réseau, il s’agit de tout le trafic local sur les interfaces de bouclage respectives (plus les connexions ssh à serverpc); donc, GatewayPorts n'est pas coché du tout.

Cependant, il existe la directive AllowTcpForwarding: si c'est no, cette configuration échouera car aucun transfert n'est autorisé, pas même à travers l'interface de bouclage.

Mises en garde :

  • si vous utilisez autossh et ssh récent, vous pouvez utiliser les variables ServerAliveInterval et ServerAliveCountMax de ssh pour maintenir le tunnel ouvert. Autossh a un chèque intégré, mais apparemment, il a des problèmes avec Fedora. -M0 le désactive, et -oServerAliveInterval=20 -oServerAliveCountMax=3 vérifie si la connexion est établie - tente toutes les 20 secondes, si elle é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 pourrait être utile de redémarrer le tunnel ssh si le transfert échoue, 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 est conseillé d'utiliser ~/.ssh/config pour les options (et les ports), sinon les lignes de commande deviennent trop prolifiques. 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
29
Piskvor

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

  • Cela vous permettra d'accéder à SSH à partir d'applications de Google Talk Client n'importe où.
  • Il n'est pas nécessaire de disposer d'une adresse IP publique ou d'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 (protégez votre ordinateur).
  • Pas besoin d'ouvrir de 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 créé un script (testé sur mon système d'exploitation Raspbian sous Raspberry Pi) afin que vous puissiez facilement installer Robo-TiTO sur Raspberry Pi, Debian ou Ubuntu Box (distribution de paquets Debian). Voici les étapes à suivre pour obtenir votre machine Linux à distance:

  1. Ouvrez Shell Command ou appelez-le Terminal, allez dans votre dossier personnel, téléchargez le script d'installation à l'aide de la commande suivante:

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

  2. après cela, lancez le script en entrant la commande:

    $ Sudo ./robotito

  3. et vous pouvez ensuite éditer le fichier credentials.rb à partir du dossier de configuration de Robo-TiTO en utilisant votre compte GTalk et l’enregistrer en appuyant sur Ctrl+X et Y. La valeur par défaut utilise nano editor.

  4. exécuter le dossier Robo-TiTO à partir de Robo-TiTO par commande

    $ cd robotito
$ ./jabbershd start

  5. Ceci 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 de le tester en discutant avant d'utiliser le compte.

4
Rolly Maulana Awangga

Si vous pouvez utiliser ssh sur le serveur interne depuis votre domicile et depuis le serveur interne sur votre machine Linux au bureau, vous pouvez utiliser ssh ProxyCommand pour retourner en mode silencieux via le serveur à 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 de ssh user@internalpc et vous êtes transféré en mode silencieux via la machine du serveur, aucune ouverture de ports ou de tunnels n’est requise de part et d’autre.

4
Michael

La solution de Piskvor fonctionne et c'est Nice. Cependant, il garde les terminaux ouverts pendants avec les coques de connexion suspendues. Pas très cool.

J'ai toujours utilisé ce petit script que j'ai écrit pour se 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 réparer la solution de Piskvor en utilisant le plus élégant autossh, éventuellement avec un écran séparé, ou en utilisant les arguments -NT ssh pour simplement garder la connexion en arrière-plan.

3
odinho - Velmont

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

2
djangofan