Comment puis-je configurer de telle sorte que je puisse toujours SSH sur mon système via Internet sur une IP dynamique?

11

Fondamentalement, je veux pouvoir faire quelque chose comme TeamViewer, où quelle que soit la configuration du réseau, tant que mon serveur ssh (Machine A) et mon client ssh (Machine B) ont un accès Internet (et un troisième serveur, Machine C) ), Je peux y accéder - la raison en est que je veux pouvoir déplacer la machine A, la brancher pour l'alimenter, la connecter automatiquement à l'un des nombreux réseaux wifi préconfigurés (chacun unique / différent) , sans avoir configuré de redirection de port ou similaire sur les réseaux, et pouvoir vous y connecter via Internet depuis la Machine B

Comment puis-je accomplir cela? Cela ne me dérange pas de configurer quelque chose sur un serveur avec une adresse IP statique pour aider à la prise de contact, mais cela ne me dérange pas non plus d'un serveur tiers si quelque chose existe déjà (comme c'est le cas pour, par exemple, TeamViewer)

modifier pour plus de clarté: j'ai 3 machines, AB et C

A est un Raspberry Pi sans tête qui sera mis sous / hors tension dans des emplacements aléatoires, connectez-vous à un réseau wifi pré-configuré

B est la machine avec un moniteur, un clavier, etc. approprié auquel je veux me connecter

C est un serveur AWS loué que j'ai avec une adresse IP statique, peut SSH de manière fiable à partir de B, et peut installer tout ce qui est nécessaire pour aider B à se connecter à A

networking ssh

— user2813274
source

Pouvez-vous passer à la 3ème machine?

— Anthon

@Anthon Je pense que oui, je les ai renommés AB et C et ajouté des descriptions pour eux, j'espère que cela clarifie les choses

— user2813274

toux no-ip.com toux

— Joshua

1

no-ip.com n'aidera pas si le pare-feu de périmètre de votre emplacement ne permet pas le trafic de retour!

— bobstro

J'ai utilisé des sshtunnels très brièvement. Je ne pourrais jamais les faire rester debout, même avec autossh; si la liaison montante a chuté pour une raison quelconque, ils devraient toujours être redémarrés à la main. Finalement, je me suis installé un petit VPN avec OpenVPN, et il a bien fait le travail.

— Blacklight Shining du

11

Comme vous avez la machine C sur Internet, créez un compte spécial nommé sesameet, sur A, vous créez un compte avec une clé publique / privée à partir de laquelle vous avez copié la clé publique dans le sesamecompte sur C.

Vous pouvez maintenant vous connecter de A à C, mais au lieu de cela, vous le faites:

ssh -N -R 19930:localhost:22 sesame@yourserverC

(vous voudrez peut-être combiner cela avec une instruction de sommeil ou, par exemple, 10 secondes et envelopper cela dans une boucle sans fin afin que la connexion soit rétablie si le WiFi est tombé en panne.)

Depuis la machine B, connectez-vous normalement à n'importe quel compte que vous avez sur C (peut être mais ne doit pas être le sesamecompte, différents comptes sont ce que j'utilise). Et une fois que vous êtes sur C, connectez-vous à A en utilisant:

ssh localhost -p 19930

Vous pouvez bien sûr utiliser un numéro différent de 19930.

Il est possible d'exécuter le ssh -N -R ...depuis /etc/rc.localsi votre clé privée sur A n'est pas protégée par un mot de passe. Dans ce cas, assurez-vous de créer sesameun compte séparé avec des fonctionnalités limitées, de sorte que lorsque votre machine A est compromise / volée, le risque pour votre serveur C est limité. C'est aussi pourquoi je recommande d'utiliser un compte séparé pour passer de B à C.

Vous pouvez réellement définir le shell de connexion pour sesamedans /etc/passwdà /bin/false, de sorte que vous ne pouvez plus utiliser le compte pour se connecter.

— Anthon
source

Cette solution est différente de l'utilisation de TeamViewer, là le serveur est utilisé pour ouvrir les ports qui sont ensuite redirigés pour communiquer directement. Tout comme des programmes comme BitTorrent communiquent directement après avoir trouvé des machines à télécharger (sans avoir à ouvrir les ports à l'avance non plus).

— Anthon

Donc, la principale différence est que de cette façon, TOUT le trafic passe par le serveur C, vs C étant utilisé uniquement pour établir un lien, puis non utilisé pour le reste de la connexion - je suis d'accord avec cela. Vous avez un bon point en ce qui concerne la sécurité, y a-t-il quelque chose que je devrais faire en particulier pour empêcher le sésame de faire quoi que ce soit sur C en dehors du strict minimum de connexion? (Système RHEL)

— user2813274

1

@ user2813274 En effet, tout le trafic passe par C dans ce scénario (ce qui enlèverait l'utilité de BitTorrent). Je ne sais pas jusqu'où vous pouvez limiter le sesamecompte sur C, il se peut que vous puissiez le faire fonctionner en /bin/falsetant que shell de connexion (car ssh ne se connecte jamais vraiment), ou le limiter autrement en ajoutant un command=paramètre dans~/.ssh/authorized_keys

— Anthon

@ user2813274 Au cas où vous ne l'auriez pas essayé vous-même: si vous avez un compte spécial pour configurer le proxy inverse, vous pouvez désactiver les connexions à ce compte en changeant le shell de connexion en /bin/false.

— Anthon

1

@ user2813274 Oui, j'ai essayé et cela me permettrait de configurer le tunnel inverse (vous avez besoin d'un autre compte pour vous rendre sur le serveur C pour le faire ssh localhost -p portnumbien sûr)

— Anthon

7

Installez un tunnel IPv6 (tel que Sixxs ) sur votre Raspberry Pi. Vous aurez maintenant une adresse IPv6 statique permanente qui sera mise en ligne chaque fois que votre Pi est en ligne. Assurez-vous de sécuriser votre Pi car il est connecté au monde maintenant.

Si votre B est connecté à un réseau IPv6, connectez-vous directement au Pi. Si B n'est pas connecté à un réseau IPv6, utilisez C comme serveur de saut, où vous vous connectez via IPv4 à C, puis ssh via IPv6 de C à votre Pi.

— garethTheRed
source

J'aime cela car il ne nécessite même pas C si les réseaux prennent en charge IPV6, je devrai cependant l'essayer - des problèmes de pare-feu bloquant cela par défaut?

— user2813274

1

Sixxs fournit plusieurs protocoles pour le tunneling IPv6. Si vous utilisez Anything In Anything (AYIYA), vous aurez besoin du port TCP 3874 et du port UDP 5072 ouverts du Pi à Internet. Sur les réseaux domestiques, cela devrait être bien; les réseaux d'entreprise ou de campus peuvent être différents.

— garethTheRed

L'installation du tunnel semblait faisable, mais il semble que je devrais m'inscrire au service Sixxs, attendre qu'ils me reviennent avec une adresse IP, etc. - plus tout à fait aussi simple - toujours potentiellement une bonne solution, mais je ne pense pas que ce soit la route que je vais emprunter pour l'instant.

— user2813274

1

Jetez également un œil à ceci:

La technologie utilisée est la même que celle décrite dans la réponse acceptée, mais elle utilise certains scripts pour automatiser les choses et rendre la solution plus générique. Il fait également toutes les configurations à l'intérieur d'un conteneur Docker, de sorte que le système principal est sûr au cas où quelque chose serait compromis.

Cependant, il ne fournit pas de connexion automatique de A à C, il doit être lancé manuellement. Vous pouvez peut-être personnaliser un peu la solution pour qu'elle fasse exactement ce que vous voulez.

— dashohoxha
source

0

Peut-être que vous devez utiliser un concept autre que ssh ou tunneling .. Je vous suggère d'utiliser un concept de messagerie comme WhatsApp ou télégramme .. Mais je pense que si vous voulez utiliser quelque chose comme vim, ce n'est pas aussi bon que ssh ..

Telegram a un client telegram-cli que vous pouvez modifier pour accepter et exécuter certaines commandes et l'implémenter dans le raspi.

Si vous utilisez Telegram, vous pouvez simplifier votre réseau et au moins réduire la machine C pour faire le Hub parce que le serveur C est sous-titré avec le serveur de messagerie télégramme. Machine aussi, vous pouvez installer le client de télégramme pour un système d'exploitation spécifique si vous voulez .. la sécurité? le message du télégramme est inscrit. Si quelqu'un veut ddos votre raspi? ils ddos le serveur de télégramme d'abord ..

Donc, tant que votre raspi peut se connecter au serveur de télégramme (simplement votre raspi se connecte à Internet) même le raspi est derrière le pare-feu / proxy / IP privée / IP dynamique, vous pouvez toujours faire la télécommande.

Avec ce concept, vous pouvez faire la télécommande n'importe où, n'importe quand.

— Wicaksono Trihatmaja
source

Wat. Ce n'est pas sûr, vous faites confiance à une application de messagerie aléatoire, vous dites que OP devrait aller modifier ladite application de messagerie aléatoire pour qu'elle fonctionne. Ce n'est même pas en train de réaliser que l'application de messagerie aléatoire romprait entièrement avec quelque chose comme vim et aurait une latence horrible.

— Pourtant, un autre utilisateur

Eh bien, si vous l'utilisez juste pour envoyer une commande, je pense que c'est ok .. si vous l'utilisez pour quelque chose comme vim, je ne pense pas que ce soit bon .. bon conseil .. je vais modifier ma réponse

— Wicaksono Trihatmaja

Je ne pense pas que c'est ce que je veux, je veux un accès complet au shell, rien de moins que cela - en ce qui concerne le dosage du Pi .. Je ne suis pas vraiment inquiet, tout d'abord parce que je dois faire une configuration spéciale pour même y connecter moi-même, deuxièmement parce que ses connexions seront intermittentes et

— changeront de

0

Je pense que vous devriez jeter un oeil à la redirection de port ssh inverse. En un mot, vous lancez d'abord un ssh de A à C en utilisant la syntaxe ci-dessous, puis utilisez ce port pour tunneler de C à A. Vous ne frapperez pas le pare-feu domestique de A lorsque vous le faites parce que le R-Pi a déjà un tunnel.

ssh -R 2210: localhost: 22 myCoolAwsSite.com

Veuillez considérer les ramifications de sécurité lorsque vous le faites. Vous pouvez ajouter un cron jujitsu afin que la connexion soit rétablie après un redémarrage.

— Hopping Bunny
source

Euh ... en quoi est-ce différent de la réponse d'Anthon?

— user2813274