Comment feriez-vous pour accéder à votre serveur en ssh en utilisant un réseau wifi qui bloque quasiment tous les ports?

Pause Café
#1

Bonjour,

imaginons que vous utilisez le wifi publique (comme le wifi d’une bibliothèque, d’un café, ou d’un restaurant), et vous souhaitez accéder à votre serveur distant via ssh pour faire quelques opérations de maintenance.

Mais vous vous rendez-compte que le wifi publique n’autorise que les ports usuels tels que 80, 443, 25, 143, 110, 53, mais pas le port 22, ni les autres ports.

Est-ce qu’il y a des astuces de configuration du serveur ssh (ou par iptables du serveur) pour qu’on puisse accéder en ssh via par exemple le port 80, sans compromettre la sécurité du serveur, ni interférer sur le fonctionnement d’apache ?

#2

Je ne recommande en générale pas de laisser un accès SSH en écoute vers le monde entier (je recommande en générale de passer par un bastion via un vpn) mais avec Haproxy c’est facilement faisable :

Une ACL check la requête et oriente soit vers le backend SSH soit vers le backend web.

#3

utilisation de HTTPS et haproxy pour détourner.
Après accéder à son SSH avec un wifi publique il faut avoir envie de se faire trouer le cul. Mieux vaut utiliser un VPN.

#4

Utilise le paquet sslh qui permet de mettre un ssh et un serveur https sur le même port 443, j’ai utilisé ça des années. Pour le reste, privilégies un accès par clef, les regards indiscrets vers ton clavier ne sont pas si rares. Enfin je n’ai réussi à déchiffrer une session SSH qu’une seule fois et parce que j’avais un dump de la mémoire avec les clefs dedans. Donc pour moi, c’est sûr surtout si tu n’autorises qu’une authentification par clef

2 J'aime
#5

En effet, l’utilisation de SSLH est simple et rapidement fonctionnelle.

#6

Hello,
Et utiliser un port personnalisé pour le ssh sur ton serveur? genre 8022. Ca répond à ta question même si comme le disait Clochette c’est loin d’être une bonne pratique. VPN+Bastion :+1:t3:

Edit: Zargos a raison dans le message ci-après, j’ai lu un peu trop vite et ma réponse n’est pas du tout pertinente. Toutes mes excuses.

#7

Ça ne marche pas plus car le choix du ports n’est pas permis.

1 J'aime
#8

Merci pour vos réponses.

Si le ssh est sensé chiffrer les données, pourquoi il est quand même risqué d’utiliser le ssh à partir d’un réseau wifi publique ? Justement le ssh n’a t-il pas été conçu pour ça à l’instar du ssl ?

Sslh est tentant, car ça a l’air simple à mettre en place.

Si je devais utiliser un vpn, j’aimerais essayer de l’installer moi-même plutôt que d’acheter un abonnement (j’évite aussi les vpn gratuits) chez un fournisseur (comme nordVPN, etc).
Pour cela, je voulais commander un serveur dédié ks-a chez ovh, mais c’est toujours en rupture de stock (car le prix n’est que de 6 euros par mois, et c’est du matériel reconditionné).

Donc j’ai une autre solution qui est le VPS pour aussi 5 euros (voire 3.50 euros) par mois chez ovh. Mais est-ce que le VPS, vu que son cpu est partagé avec d’autres VPS du système, sera suffisant pour y installer un vpn (comme openVPN) ?

Le VPS à 3.50 euros/mois : cpu 1 vCore, ram 2go, disque dur 20go en sdd, bande passante 100 Mb/s.

Le VPS à 5 euros/mois : cpu 2vCore, ram 2 go, disque dur 40 go en ssd, bande passante 500 Mb/s.

Lequel me conseillerez-vous ? Voici ce que je souhaiterais faire avec le vps :

-me connecter en ssh sur le port 80 ou 443 du vps pour que ce dernier me redirige vers le port 22 d’un serveur dédié (port forwarding avec rebond), et comme ça je pourrais avoir accès au serveur ssh de mon serveur dédié à partir d’un réseau wifi publique qui bloque tous les ports sauf le 80, 443, 25, 143, 110.

-utiliser le vps comme proxy pour naviguer sur internet de façon anonyme.

-et plus tard, installer un vpn comme openVPN.

J’ai commencé à regarder quelque tutos sur le tunneling ssh (port forwarding avec ou sans rebond), et je voudrais savoir si le vpn pour « navigateur » proposé par les fournisseurs de vpn payant n’est-il rien d’autres que du ssh en « proxy socks » (càd ssh avec l’option -D) ?

#9

Le goulot d’étranglement c’est la bande passante.

OpenVPN ne consomme pas trop de CPU vu qu’au final il ne fait que le chiffrement des données de retour et le maintien du lien (le chiffrement de l('envoi c’est le client qui le fait).

Le problème du port 22 c’est que celui-ci est un port root (comme tous les ports inférieur à 1024. C’est pour ça qu’il est recommandé de ne pas l’utiliser en public.
De fait tu peux faire du one to one avec ta box, utilisant le port 22 avec un NAT vers un port > 1024 (exemple: 22022) avec une règle dans ta box:

IP Source : *
Destination port: 22
IP destination: ta box
NAT IP: ton serveur
NAT Port: 22022

Après si tu veux faire du VPN pour aller sur d’autres sites, n’importe quel VPN fait l’affaire. Dans tous les cas les accès vers ta machine ne seront jamais vraiment anonymes (mais on s’en fout en fait, vu qu’il n’y a que toi qui est sensé y aller).

Et pour ce qui est de l’anonymat, je vais le redire, si vous utilisez un VPN pour aller sur un site avec authentification, par définition il n’y a aucun anonymat.

#10

Merci zargos, pour la bande passante tu conseillerez combien ? Car ce que je veux comme bande passante est l’équivalent de celle de ma freebox, càd que si je veux télécharger une image iso debian par exemple, je voudrais que le débit de téléchargement en passant par le vps soit au moins égal (et si c’est supérieur tant mieux) à celui de ma freebox sans vps.

Pour le choix de la localisation géographique du vps, que me conseillerais-tu ? Y a t-il des continents ou des pays en particulier à éviter ? Et pourquoi ?

#11

A partir d’où veux-tu download une iso? si c’est de ton serveur, c’est la bande passante de ton FAI, si c’est à partir du wifi public, c’est celle du wifi public qui sera le goulot d’étranglement.
Télécharger une iso à partir d’un wifi public pourquoi pas, mais le vpn ne sert pas à grand chose dans ce cas.
De toute façon quelque soit la géolocalisation de ton vpn, ça sera visible sur le wifi public (i.e.e: il sera facile de savoir que tu as utilisé un vpn).
Le choix du pays est simple: éviter tous les pays qui sont dans le top 5 des surveillance internet, donc pas de chine, pas la france (;)) etc…
Et si tu utilise un VPS, vu que tu vas payer avec une carte bleue on saura donc que c’est toi qui l’utilise.

1 J'aime
#12

C’est « marrant » parce-que ce n’est pas ce que disent les personnes du projet OpenVPN :
https://blog.openvpn.net/openvpn-data-channel-offload/

Avec un CPU plutôt puissant, ils arrivent à 370 Mb/s . C’est à dire moins que les 500 Mb/s du VPS à 5 €.

Et installer DCO, ce n’est pas forcément donné à tout le monde.

–
AnonymousCoward

#13

Désolé mais le lien donne des données dont le protocole d’obtention n’est pas clair; tout particulièrement sur la configuration tunnel.
C’est le genre de page sur laquelle on peut quasiment mettre ce qu’on veut pour prouver son propos.
Déjà on ne sait pas si c’est du transport en TCP ou en UDP; ce qui change beaucoup les performance.
C’est plus une page marketing qu’une page technique.

#14

Bon, après avoir acheté le vps à 5 euros par mois, et configuré le serveur ssh dessus pour qu’il écoute le port 443 au lieu du port 22, et en faire un proxy, j’ai réussi à me connecter à un serveur dédié depuis mon pc personnel qui utilise un réseau wifi public, et ce en utilisant le local port forwarding avec rebond. En tapant juste 2 commandes ssh sur mon pc personnel :

$ ssh -L port_local:ip_serveur_dédié:port_ssh_du_serveur_dedié ip_vps -p 443

Puis :

$ ssh utilisateur_serveur_dédié@localhost -p port_local

Voici le tuto que j’ai utilisé : https://www.youtube.com/watch?v=xb2duWYFOyo

Donc je voudrais savoir si la technique du local port forwarding avec rebond est aussi sécurisé qu’un VPN classique ?

J’ai aussi réussi à activer le proxy socks pour créer un tunnel ssh que je vais par la suite utiliser dans mon navigateur, en tapant une commande ssh :

$ ssh -D port_local ip_vps -p 443

Voici le tuto que j’ai utilisé : https://www.youtube.com/watch?v=8SlovOndKKg

Puis j’ouvre chromium en ligne de commande avec utilisation du proxy socks v5, comme ceci :

$ chromium --proxy-server="socks5://127.0.0.1:port_local"

Doc : Configuring a SOCKS proxy server in Chrome

#15

C’est un tunnel que tu as créé :slight_smile:
Quand tu te connecte à un bout tu finis à l’autre bout. Si quelque chose écoute tu te connecte.

1 J'aime
#16

Bonjour,

S’il s’agit juste de se connecter à une machine en ssh, on peut rebondir en utilisant la fonctionnalité de « jump host ».

Par exemple, avec ce fichier de configuration utilisateur ssh ( ~/.ssh/config ) :

HashKnownHosts No
CheckHostIP No

Host vps
        HostKeyAlias vps
        HostName 54.18.204.2
        Port 443
        User toto

Host dedie
        HostKeyAlias dedie
        HostName 54.25.107.78
        User toto

(exemple fictif)

A ce moment, on peut se connecter à « dedie » en faisant :

ssh -J vps dedie

On peut aussi utiliser la directive ProxyJump dans le fichier de configuration ssh pour éviter d’avoir à préciser l’option -J .

–
AnonymousCoward

2 J'aime
#17

J’ai une question à propos du sens de l’acronyme VPN.

Quand on me dit que VPN est l’acronyme de Virtual Private Network, je pensais que c’est tout bêtement un réseau privé constitué de machines « virtuelles », mais j’ai l’impression que ça ne veut pas dire ça, car on peut utiliser une machine « réelle » comme un serveur dédié pour en faire un vpn.

Donc finalement, pourquoi VPN est un réseau « virtuel » ???

#18

Un réseau existe normalement sur la base d’un infrastructure physique.
Ensuite on a créé les VLAN, qui permettent, au sein d’un réseau physique, de créer des réseaux logiques sur un réseau physique, liés à des configurations réalisées sur les équipements physiques du réseau.
Ensuite on a créé les VPN qui sont des tunnels créés entre deux interfaces de deux équipements. Il est virtuel dans le sens où il n’y a aucune intervention au niveau des matériels réseaux qu’il traverse.
Les deux équipements échangent via des protocoles spécifiques avec un système de chiffrement qui permet de sécuriser et de garantir la connexion.

On parle souvent de tunnel car les premiers ont été les tunnels IPSEC, il me semble.

1 J'aime
#19

La définition de Wikipédia est pourtant bien foutu je trouve pour expliquer :wink:

VLAN (virtual local area network) Réseau local virtuel — Wikipédia, c’est de la séparation, segmentation et de la sécurisation :wink: ça n’a rien à voir avec un VPN …

Non ce dont tu parles est un LAN (local Area Network) Réseau local — Wikipédia

Nope à tout point de vue le premier c’est AT&T avec un truc dont je ne me rappel plus le nom genre Swap ou Swip quelque chose, ensuite ce doit être le PPTP et ensuite sur la base du premier IPSEC est arrivé

#20

Ah oui je l’avais oublié celui là :slight_smile:

je ne suis pas d’accord pour la sécurisation en fait :slight_smile:
Car sur un réseau, une machine qui ne fait pas partie du VLAN (i.e.: n’a pas son interface taguée sur le VLAN) peut tout de même voir les paquets des autres VLAN qui transitent sur le même segment, via le mode promiscuité par exemple et les sniffer.
Autant la segmentation je suis d’accord, autant coté sécurité non.
Si plusieurs VLAN transitent sur une même interface, alors toute autre interface connectée avec celle-ci pourra sniffer les paquets de tous les VLAN. Je sais que c’est possible pour l’avoir déjà fait avec mon FAI justement.
Suffit de faire le montage ci-dessous:
image

L’ONT est branché à la fibre de l’opérateur et est normalement relié à la box par un câble RJ45. Il suffit d’interposer un simple Switch de niveau 2, qui ne gère pas les VLAN et se contente de retransmettre les paquets sur ses interfaces.
Sur l’ordinateur, sans aucune adresse IP allouée à l’interface connectée, on peut sniffer une interface en mode promiscuité. Toutes les paquets entre l’ONT et la BOX seront sniffés.
C’est ainsi que j’ai récupéré les informations nécessaires (paquets DHCP en particulier) pour faire en sorte que mon MiniPC mis à la place de la BOX puisse se connecter au réseau Orange comme la BOX qui est dans un tiroir depuis (depuis 2018/2019 en fait). Sachant que sur Orange, ils utilisent/utilisaient deux VLAN: un pour l’internet, un pour la TV (respectivement tagués 832 et 840).
Donc si tu ne peux pas voir les paquets, c’est parce qu’au niveau de la machine en bout de chaîne, le port du switch auquel il est connecté ne diffuse qu’un seul VLAN. Mais c’est tout.
Donc pour la sécurité c’est non. Tu ne peux pas avoir une visu sur un VLAN qui n’est pas le tien uniquement parce que le port auquel tu es relié ne diffuse pas l’autre VLAN, c’est tout.

Et la page Wikipedia n’est pas bonne car il(s) dit(sent) que, je cite :

Par conséquent, les VLAN permettent aussi d’améliorer la gestion du réseau et d’optimiser la bande passante.

Sauf qu’un VLAN ne permet pas d’optimiser la bande passante c’est totalement faux. Le seul moyen d’optimiser la bande passante c’est la QOS (Quality Of Service). Mais ça permet bien d’optimiser la gestion des réseaux.

Autre erreur:

Ceci est accompli en encapsulant chaque trame de façon à conserver son numéro de VLAN. L’IEEE a développé la norme 802.1Q (dot1q).

Non c e n’est pas encapsulé, c’est un champ supplémentaire (inséré) dans l’en-tête, comme le dit la norme citée:
image

Mais à leur décharge, comme c’est indiqué:
image

La page anglaise est meilleure: VLAN - Wikipedia
Mais il y a la même erreur pour ce qui est de la sécurité, qui en fait n’est à aucun moment détaillée dans aucune des deux pages.
De fait, des milliers d’admin réseau croient faire de la sécurité en faisant du VLAN alors que ce n’est pas le cas. Dans le schéma d ela page anglaise, il suffit d’avoir accès à n’importe quel traffic concernant les paquets issus des interfaces entre les switches de distribution et le switch central pour avoir accès à tout.