De nombreuses entreprises utilisent des serveurs de saut accessibles Secure Shell (SSH) pour accéder aux systèmes critiques de l'entreprise. Les administrateurs se connectent d'abord à un serveur de saut à l'aide de SSH, éventuellement via un VPN, avant de se connecter au système cible. Cette méthode fonctionne généralement très bien tant qu'un administrateur s'en tient à l'administration en ligne de commande. Cela devient un peu plus délicat lorsqu'un administrateur souhaite sortir du domaine de la ligne de commande et utiliser une interface Web à la place.
Examinons le scénario suivant :Bob est administrateur système chez Securecorp, et il vient de recevoir une alerte indiquant qu'un cluster de bases de données composé de sirius.securecorp.io et orion.securecorp.io fonctionne mal. Pour une première analyse, il utilise généralement la console Web RHEL8. Le pare-feu ne lui permet pas de se connecter directement à ce système depuis son poste de travail, mais il peut passer par un serveur de saut appelé bastion.securecorp.io .
[ Vous pourriez également apprécier : 6 guides SSH essentiels pour les administrateurs système ]
L'accès en ligne de commande SSH au cluster de bases de données est simple :
[bob@workstation ~]$ ssh bastion.securecorp.io
[bob@bastion ~]$ ssh sirius.securecorp.io
[bob@sirius ~]$
[bob@workstation ~]$ ssh bastion.securecorp.io
[bob@bastion ~]$ ssh orion.securecorp.io
[bob@orion ~]$ Mais que se passe-t-il si Bob veut accéder à la console Web RHEL8 de sirius.securecorp.io et orion.securecorp.io ? Il existe plusieurs façons d'atteindre cet objectif en utilisant SSH, toutes impliquant une redirection de port quelconque.
Avis de non-responsabilité :Dans certaines organisations, les politiques de sécurité n'autorisent pas la redirection de port. Pour vous assurer que vous n'enfreignez aucune règle, veuillez consulter votre représentant en sécurité informatique.
Transfert de port SSH
À l'aide de SSH, Bob ouvre un tunnel TCP pour les deux systèmes, pointant vers le port de la console Web (9090) pour sirius.securecorp.io et le port 9091 pour orion.securecorp.io .
[bob@workstation ~]$ ssh -L 9090:sirius.securecorp.io:9090 bastion.securecorp.io
[bob@bastion ~]$
[bob@workstation ~]$ ssh -L 9091:orion.securecorp.io:9090 bastion.securecorp.io
[bob@bastion ~]$ Bob peut maintenant pointer le navigateur de son poste de travail local vers https://localhost:9090 pour accéder à la console Web de sirius.securecorp.io , et https://localhost:9091 pour accéder à la console Web pour orion.securecorp.io .
Cette approche peut bien fonctionner dans certains cas, mais a ses limites :
- Validation du certificat TLS :le navigateur local n'est pas satisfait car, dans la plupart des cas, le nom commun du certificat ne correspond pas au nom d'hôte dans la barre d'adresse (localhost), de sorte que la validation du certificat échoue.
- Redirections :lorsque le site Web auquel vous accédez vous redirige vers une autre URL, la connexion échoue car la redirection de port n'est valide que pour exactement ce serveur Web. Cette situation peut poser problème lors de l'utilisation de l'authentification unique (SSO), par exemple.
Démarrer un navigateur sur le serveur de saut
Bob serait également chargé de démarrer un navigateur tel que Firefox sur le serveur de saut et de l'afficher localement sur son poste de travail. SSH fournit une fonctionnalité appelée transfert X, qui peut être utilisée dans cette situation.
[bob@workstation ~]$ ssh -X bastion.securecorp.io
[bob@bastion ~]$ firefox https://sirius.securecorp.io:9090 &
[bob@bastion ~]$ firefox https://orion.securecorp.io:9090 & En utilisant cette méthode, le processus du navigateur s'exécute sur le serveur de saut et les connexions aux consoles Web de sirius.securecorp.io et orion.securecorp.io sont autorisés. Seul le rendu de la fenêtre du navigateur se produit sur le poste de travail de Bob.
Bien que cette approche résolve certains problèmes de transfert de port SSH simple, elle présente également des limites :
- Performance :cette méthode fonctionne généralement assez mal car la sortie graphique doit être transférée du serveur de saut au poste de travail via le réseau, ce qui est très inefficace.
- Prérequis :un navigateur tel que Firefox doit être installé sur le serveur de saut et un serveur X doit être en cours d'exécution sur le poste de travail.
Entrez dans le transfert de port dynamique
Après avoir exploré les deux approches précédentes et appris leurs inconvénients, ce serait formidable d'avoir une troisième option, qui nous apporte le meilleur des deux mondes :
- Le navigateur du poste de travail peut être utilisé.
- La connectivité et la résolution des noms DNS doivent être les mêmes que sur le serveur de saut.
Pour ce faire, SSH fournit une fonctionnalité appelée transfert de port dynamique , qui exploite le protocole SOCKS. Dans cette configuration, SSH agit comme un proxy SOCKS, relayant tout le trafic pertinent via la connexion SSH. Pour que cela se produise, le client (dans notre exemple, il s'agit du navigateur) doit être conscient de SOCKS.
Bob peut initier une session SSH avec un transfert de port dynamique comme suit :
[bob@workstation ~]$ ssh -D 1080 bastion.securecorp.io
[bob@bastion ~]$ Après cela, le navigateur sur le poste de travail de Bob doit être rendu compatible SOCKS. La configuration de Firefox peut être réalisée comme ceci :
- Pointez le navigateur vers about:preferences.
- Dans le Général onglet, faites défiler vers le bas et cliquez sur Paramètres... dans les Paramètres réseau section.
- Dans les Paramètres de connexion fenêtre, choisissez Configuration manuelle du proxy , spécifiez localhost pour l'hôte SOCKS , 1080 comme Port, et sélectionnez SOCKS v5 .
- Dans la même fenêtre, sélectionnez Proxy DNS lors de l'utilisation de SOCKS v5 .
Bob peut maintenant diriger le navigateur vers https://sirius.securecorp.io:9090 et https://orion.securecorp.io:9090 pour analyser les problèmes de performances de ses deux serveurs de base de données à l'aide de la console Web RHEL8. Il peut également accéder à toutes les autres ressources internes comme si le navigateur fonctionnait sur bastion.securecorp.io .
Remarque :Le port 1080 est le port enregistré auprès de l'IANA pour SOCKS, mais la connexion peut utiliser n'importe quel autre port. Les chiffres de la configuration SSH et du navigateur doivent correspondre.
Personnellement, j'ai trouvé utile de créer un profil de navigateur séparé afin qu'il ne soit pas nécessaire de basculer constamment entre les configurations de proxy. Un nouveau profil peut être créé en passant le -P passer à firefox commande, en lançant le Gestionnaire de profils . J'ai appelé mon profil Jump . Après avoir créé un nouveau profil, une configuration vide est créée. Dans ce profil, j'ai appliqué la configuration comme décrit ci-dessus tout en laissant mon profil par défaut intact.
Après avoir créé le profil, Firefox peut être lancé avec la commande suivante :
[bob@workstation ~]$ firefox -P Jump
Une autre astuce utile consiste à créer une configuration spécifique à l'hôte pour le transfert de port dynamique dans votre ~/.ssh/config dossier. Par exemple :
[bob@workstation ~]$ cat ~/.ssh/config
Host bastion
Hostname bastion.securecorp.io
User bob
DynamicForward 1080 [ Un cours gratuit pour vous :présentation technique de la virtualisation et de la migration d'infrastructure. ]
Récapitulez
Il existe de nombreuses façons de se connecter aux systèmes internes à l'aide d'un serveur de saut et les possibilités décrites ci-dessus ne sont en aucun cas exhaustives. D'après mon expérience, cependant, SSH vous fournit un kit d'outils très puissant, qui dans la plupart des cas est disponible et prêt à l'emploi sans trop d'obstacles. Le transfert de port dynamique est l'un de ces outils et il m'a aidé à être plus productif dans des situations spécifiques, alors essayez-le vous-même.