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

33

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

ritter
la source
1
le PC de travail peut-il se connecter à la maison en configurant un tunnel ssh? en.gentoo-wiki.com/wiki/Autossh
Vous pouvez utiliser FileZilla avec sftp et la redirection de port. Départ: superuser.com/a/1286681/141314
Noam Manos

Réponses:

31
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
Piskvor
la source
Je crois que cette méthode que vous supposez s'appelle "reverse ssh-tunnel". Malheureusement, cela nécessite que GatewayPorts sur le serveur soit défini sur "oui" dans / etc / ssh / sshd_config. Ce serveur n'a pas de ports de passerelle activés et je n'y ai pas d'accès root.
3
@Frank: En fait, je ne pense pas: GatewayPorts norestreint les ports ouverts pour qu'ils ne soient accessibles que sur l'interface de bouclage; notez qu'à l'étape 2 vous transférez sur l'interface de bouclage (en fait, les deux vers l'avant sont "localhost seulement"), donc cela pourrait fonctionner ( AllowTcpForwarding nodans la configuration sshd, cela casserait cela).
Piskvor
3
@Frank: Oui, confirmé. Cela fonctionne même avec GatewayPorts no; modifié la réponse. Notez qu'il existe d'autres directives (telles que PermitOpenet AllowTcpForwarding) qui peuvent casser cette configuration: manpagez.com/man/5/sshd_config
Piskvor
1
Excellente réponse! Ça marche, tu as sauvé mon week-end! Merci beaucoup!!
1
ma version autossh (Fedora Core) ne pouvait pas fonctionner à partir du terminal sans -M. J'ai également lié à une autre personne qui a vécu cela. Vous avez raison de dire que dans le manuel, il est marqué comme argument facultatif. Bon si ça marche pour beaucoup de gens, dommage que pas pour tous.
Yaroslav Nikitenko
4

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é.

Michael
la source
1
Merci pour votre réponse. Malheureusement, 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.
4

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.

Rolly Maulana Awangga
la source
5
J'ai un sérieux problème avec "Pas besoin d'ouvrir le port SSH (garder votre ordinateur en mémoire )" - le bot shell-over-jabber que vous proposez est sécurisé avec, citation CLIENT_PASSPHRASE = "logmein", en texte clair . C'est littéralement une sécurité zéro - vous faites un trou de la taille d'un camion pour que n'importe qui puisse y entrer. Contrairement à l'authentification par clé publique SSH: je m'authentifie sur un canal sécurisé , en utilisant des informations d'identification qui ne traversent jamais le fil. Qui garde son ordinateur en sécurité maintenant?
Piskvor
@Piskvor, robotito exécutera uniquement les commandes des contacts sur liste blanche. github.com/formigarafa/robotito/blob/master/config/…
formigarafa
Je n'ai jamais rencontré de problème à cause de l'authentification basée sur la liste blanche. Si je ne me trompe pas, le transfert des messages est crypté lors de l'utilisation avec GTalk. D'une manière ou d'une autre, je l'ai changé récemment et maintenant il utilise un mot de passe unique à partir d'un outil comme Google Authenticator ou similaire pour permettre l'accès.
formigarafa
1
@formigarafa: (1) Si vous êtes ou avez été impliqué dans le développement de ce produit, vous devez le dire explicitement. Utiliser le même nom ne suffit pas; la plupart des gens ne le remarqueront pas. (Vous pouvez le mentionner dans votre profil .) (2) Lorsque vous modifiez un article, vous devez le corriger autant que vous le pouvez. Par exemple, essayez d'attraper des fautes de frappe comme «I'ts». Et, si un lien est tombé en panne, ne vous contentez pas de l'étiqueter comme un lien mort; mettre la nouvelle URL dans le message . Les gens ne devraient pas avoir à fouiller dans les commentaires pour trouver les bonnes informations.
G-Man dit `` Réintègre Monica '' le
@ G-Man, la réponse et l'édition originales n'étaient pas les miennes. Et je n'ai jamais eu l'intention de la faire ressembler à la mienne. J'ai remarqué un lien mort sur la réponse, je n'ai pas non plus créé le lien. J'étais vraiment impatient de voir son contenu et j'ai essayé de le suivre. Malheureusement, je n'ai pas pu trouver la ressource. J'ai marqué comme un lien mort sur l'espoir que celui qui a écrit la réponse serait averti par le changement et tenterait de le corriger.
formigarafa
3

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.

odinho - Velmont
la source
Merci pour les compliments :) Pour mes cas d'utilisation, j'ai régulièrement besoin de l'accès shell, ainsi que des renvois; De plus, j'ai essayé de montrer le cas minimal ici (il est possible de simplifier ce qui précède en deux commandes avec un saut d'hôte SSH transparent, mais cela nécessiterait une configuration supplémentaire sur l' homepcordinateur).
Piskvor
2

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é.

djangofan
la source
1
Maintenant que le 5.0.0.0/8réseau a réellement des adresses IPv4 publiques attribuées, Hamachi est en difficulté (si Hamachi est en cours d'exécution, vous ne pouvez pas accéder à une partie quelque peu aléatoire d'Internet). De plus, Hamachi n'est plus gratuit.
Piskvor