SSH Secure Shell
Le protocole de shell distant chiffré sur lequel chaque machine Linux de la planète écoute par défaut — et la porte d'entrée de chaque VPS que nous livrons.
Un protocole réseau chiffré pour opérer une machine distante comme si vous étiez assis devant sa console : accès au shell, transfert de fichiers (SCP, SFTP), forwarding TCP arbitraire et proxy SOCKS. A remplacé le trio en clair telnet/rlogin/rsh à partir de 1995. L'implémentation moderne dominante est OpenSSH, livrée par chaque distribution majeure Linux et BSD et par macOS.
SSH est l'intégralité du plan de contrôle de votre VPS.
Il n'y a pas de panneau de contrôle propriétaire entre vous et le système d'exploitation — pas de « gestionnaire de serveur » graphique, pas de navigateur de fichiers abstrait, pas de web shell style portail captif. Chaque VPS NordBastion atterrit dans vos mains comme une machine Linux stock écoutant sur le port 22 pour SSH, avec un identifiant root unique délivré via le panneau. SSH est l'intégralité du plan de contrôle, point.
Cette décision repose sur la même logique que le reste du produit : SSH est ouvert, bien audité, rapide et fonctionne de manière identique depuis un laptop à Berlin, un smartphone avec Termius et un CI runner dans un autre data-center. Un panneau web sur mesure serait plus lent, plus faible, et nous obligerait à maintenir du code que le projet OpenSSH maintient déjà mieux que nous ne pourrions jamais le faire.
Les recommandations opsec de la première heure sont les mêmes sur un VPS NordBastion que sur toute machine Linux de production : générez une clé Ed25519, copiez la moitié publique sur le serveur, désactivez l'authentification par mot de passe et la connexion root si elle n'est pas nécessaire, installez fail2ban ou un équivalent, et envisagez de restreindre les IP source au firewall. Le guide de durcissement détaille chaque commande.
Les pages qui s'appuient sur ce terme.
Les questions que les gens posent réellement.
Comment me connecter à mon VPS via SSH ?
Depuis un terminal : `ssh [email protected]`. La première connexion vous invite à vérifier l'empreinte de l'hôte — comparez-la à la valeur affichée dans le panneau client avant d'accepter. Ensuite, l'authentification par clé est la configuration recommandée : générez localement une paire de clés Ed25519, collez la moitié publique dans ~/.ssh/authorized_keys sur le VPS, et désactivez la connexion par mot de passe dans /etc/ssh/sshd_config. Le guide de durcissement de la première heure détaille chaque étape.
L'authentification par mot de passe est-elle sûre ?
Assez sûre si le mot de passe est long et aléatoire, mais l'authentification par clé est significativement meilleure. Une clé forte ne peut pas être brute-forcée par les scanners drive-by (et il y en a beaucoup qui frappent chaque IP publique sur le port 22 chaque jour), et désactiver l'auth par mot de passe entièrement élimine toute une classe de bruit de credential-stuffing de vos logs. Le guide de durcissement recommande l'authentification par clé uniquement comme défaut.
Qu'est-ce que le port forwarding SSH ?
Une manière de tunnéliser du trafic TCP arbitraire sur une connexion SSH chiffrée. Le forwarding local (`-L`) expose un service distant sur un port local — par exemple, ouvrir le PostgreSQL du VPS sur localhost:5432 de votre laptop. Le forwarding distant (`-R`) est l'inverse. Le forwarding dynamique (`-D`) monte un proxy SOCKS qui route toute application configurée pour l'utiliser à travers le VPS. Les trois sont extrêmement utiles et valent la peine d'être appris.
Devrais-je changer le port SSH par défaut depuis 22 ?
Surtout cosmétique. Déplacer SSH vers un port aléatoire élevé réduit le volume de bruit de scanners drive-by dans vos logs mais ne fait rien contre un attaquant ciblé qui scannera simplement l'hôte. Les vraies défenses sont l'authentification par clé uniquement, un rate-limiter style fail2ban et la limitation des IP source au niveau firewall si votre schéma d'accès le permet. Le guide détaille les trois.