Le rôle d’un hôte de rebond
Un hôte de rebond, aussi appelé bastion, est un serveur auquel vous pouvez accéder directement et qui peut accéder à vos serveurs internes. Seul le port SSH du bastion est exposé ; les serveurs internes n’acceptent SSH que depuis le réseau interne. Avec ProxyJump, votre client ouvre une connexion SSH au bastion et une seconde connexion chiffrée de bout en bout qui le traverse pour atteindre la cible. Le bastion relaie le trafic, mais ne voit pas le contenu de la session, et votre clé privée reste sur votre ordinateur.
Se connecter en ligne de commande
L’option -J désigne l’hôte de rebond. Séparez plusieurs sauts par des virgules ; ils sont utilisés dans l’ordre indiqué. Ajoutez les paramètres à ~/.ssh/config si vous empruntez régulièrement le même chemin, afin qu’un alias court suffise.
ssh -J admin@bastion.example admin@app.internal
ssh -J admin@bastion.example,ops@hop2.example admin@app.internal
# ~/.ssh/config
Host app-internal
HostName app.internal
User admin
ProxyJump admin@bastion.exampleVérifier chaque clé d’hôte
Chaque saut est un serveur SSH distinct possédant sa propre clé d’hôte. Confirmez donc l’empreinte du bastion et celle de la cible par un autre canal fiable. Une clé modifiée à n’importe quel saut mérite la même attention que lors d’une connexion directe. Comparez l’empreinte proposée à la première connexion avec la valeur qu’un administrateur relève sur le serveur.
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub -E sha256Préférer ProxyJump au transfert d’agent
Le transfert d’agent (ssh -A) permet à toute personne disposant de droits suffisants sur le bastion d’utiliser vos clés chargées tant que vous êtes connecté. ProxyJump n’en a pas besoin, car l’authentification auprès de la cible s’effectue depuis votre propre ordinateur. Évitez aussi de stocker des clés privées sur le bastion et limitez les personnes autorisées à s’y connecter.
Échecs courants
Déterminez d’abord quel saut échoue : connectez-vous au bastion seul, puis lancez ssh -vvv avec -J pour voir où la connexion s’arrête. Si le bastion fonctionne mais pas la cible, la cause est généralement un pare-feu entre les deux, un nom interne incorrect ou une cible qui n’accepte pas votre clé. Un serveur configuré avec AllowTcpForwarding no refuse de servir d’hôte de rebond.
Les hôtes de rebond dans CH-J Server Manager
Alpha 0.1.1 se connecte via un hôte de rebond enregistré ou saisi manuellement, et les hôtes enregistrés peuvent former une chaîne de trois hôtes de rebond au maximum. La clé d’hôte est vérifiée à chaque saut. Le moniteur de disponibilité ne vérifie un serveur situé derrière un hôte de rebond qu’au travers d’une session ouverte vers cet hôte de rebond ; sinon, il affiche le serveur comme non vérifié, jamais comme en ligne. Beta 0.1.0 ne dispose pas de cette fonction.