[email protected]$ autossh -R 12345:localhost:22 [email protected]
Plus tard :
[email protected]$ autossh -L 23456:localhost:12345 [email protected]
[email protected]$ ssh [email protected] -p 23456
Voici ce que vous pouvez faire :à l'étape 1, transférez un port distant du PC de bureau vers le serveur (12345
est utilisé comme exemple, n'importe quel port>1024 devrait faire l'affaire). Maintenant, la connexion au 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 configuré à l'étape 1)
À l'étape 3, vous vous connectez au port local 23456 avec votre login PC de bureau . Celui-ci est transmis à l'étape 2 sur le port 12345 de votre serveur et à l'étape 1 sur 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, tant que la connexion ne tombe pas.
Il existe une vulnérabilité possible :quiconque peut se connecter à localhost:12345 sur serverpc peut désormais 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 de désactiver l'authentification par mot de passe - voir par exemple ceci)
Modifier :J'ai vérifié cela avec la même config, et ça marche. GatewayPorts no
n'affecte que les ports ouverts au monde entier, pas les tunnels locaux. Voici ce que sont 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 vers serveurpc); donc, GatewayPorts
n'est pas coché du tout.
Il existe cependant la directive AllowTcpForwarding
:si c'est no
, cette configuration échouera car aucun transfert n'est autorisé, pas même via l'interface de bouclage.
Mises en garde :
-
si vous utilisez autossh et ssh récent, vous pouvez utiliser le
ServerAliveInterval
de ssh etServerAliveCountMax
pour maintenir le tunnel en place. Autossh a une vérification intégrée, mais apparemment, il a quelques problèmes sur Fedora.-M0
désactive cela, et-oServerAliveInterval=20 -oServerAliveCountMax=3
vérifie si la connexion est établie - essaie 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 [email protected] autossh -M0 -L 23456:localhost:12345 -oServerAliveInterval=20 -oServerAliveCountMax=3 [email protected]
-
il peut ê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é. -
en utilisant
~/.ssh/config
pour les options (et les ports) est conseillé, sinon les lignes de commande deviennent trop détaillées. 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 vous connecter en ssh au serveur interne depuis chez vous et depuis le serveur interne vers votre machine Linux de bureau, alors depuis chez vous, vous pouvez utiliser le ssh ProxyCommand
pour rebondir silencieusement à travers 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 de ssh [email protected]
et vous êtes silencieusement transféré via la machine serveur, aucune ouverture de ports ou de tunnels n'est requise à chaque extrémité.
Installez Robo-TiTO sur l'ordinateur sur lequel vous souhaitez accéder à SSH à distance.
- Cela vous permettra d'accéder à SSH à partir des applications clientes Google Talk, où que vous soyez.
- 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 (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 dans Raspberry Pi) pour que vous puissiez facilement installer Robo-TiTO sur Raspberry Pi, Debian ou Ubuntu Box (distribution du paquet Debian). voici les étapes pour obtenir votre Linux boîtier télécommandable :
Ouvrez la commande Shell ou vous pouvez l'appeler Terminal, accédez à votre dossier personnel, téléchargez le script d'installation par commande :
$ wget https://opengateway.googlecode.com/files/robotito
après cela, exécutez le script en entrant la commande :
$ sudo ./robotito
et ensuite vous pouvez éditer le fichier
credentials.rb
depuis le dossier de configuration de Robo-TiTO à l'aide de votre compte GTalk et enregistrez-le en appuyant sur Ctrl +X et O . La valeur par défaut utilise l'éditeur nano.exécuter le Robo-TiTO à partir du dossier Robo-TiTO par commande
$ cd robotito $ ./jabbershd start
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 entre vous avant d'utiliser le compte.