Votre première session SSH, avec un moyen de revenir en arrière.

Rassemblez les détails d'accès et le chemin de récupération

Vous avez besoin de l'adresse réelle du serveur, du port SSH, du nom d'utilisateur de connexion, de la méthode d'authentification initiale et d'une source fiable pour l'empreinte de la clé d'hôte du serveur. Un nom d'hôte choisi dans un configurateur n'établit pas le DNS et ne crée pas de compte. Obtenez ces détails à partir de la configuration réelle du service, et non à partir d'hypothèses sur une image Linux.

Confirmez comment accéder à une console ou à un environnement de secours et qui peut rétablir l'accès. Vérifiez que vous pouvez emprunter cette voie de récupération dès maintenant ; ne découvrez pas lors d'un verrouillage que vous n'avez pas les autorisations ou les identifiants de récupération. Si aucune voie de récupération indépendante n'est disponible, laissez les paramètres d'accès inchangés jusqu'à ce qu'une solution soit mise en place.

Les exemples utilisent un terminal client Bash sur votre propre ordinateur et un serveur Ubuntu/Debian. Remplacez par vos informations réelles builder, port 22 et 192.0.2.10, qui est une adresse d'exemple réservée. Les commandes sont des instructions à examiner pour votre environnement ; ce guide ne s'est pas connecté à un serveur OffVPS ni ne l'a configuré.

Créez une clé cliente sans remplacer une clé existante

Votre clé privée reste sur l'ordinateur client. La clé publique correspondante peut être installée dans les clés autorisées du compte du serveur. Ni l'une ni l'autre n'est la clé d'hôte du serveur : cette clé distincte aide à identifier la machine que vous contactez. Gardez la clé privée et sa phrase secrète en dehors des messages d'assistance, des dépôts et des téléversements vers le serveur.

ssh -V
ls -ld "$HOME/.ssh"
ls "$HOME/.ssh/offvps_first_vps" "$HOME/.ssh/offvps_first_vps.pub"

Inspectez d'abord les chemins. Si le répertoire SSH n'existe pas, créez-le avec la permission 700. Si l'un des fichiers de clé nommés existe déjà, choisissez un autre nom ou réutilisez délibérément votre clé existante ; ne l'écrasez pas. Générez une clé dédiée avec une phrase secrète :

ssh-keygen -t ed25519 -f "$HOME/.ssh/offvps_first_vps" -C "first-vps"
ssh-keygen -lf "$HOME/.ssh/offvps_first_vps.pub" -E sha256

La seconde commande affiche l'empreinte de la clé publique, et non des éléments de clé privée. La page de manuel de ssh-keygen documente les types de clés, les fichiers de sortie et les empreintes. Lorsqu'un appareil géré impose une politique de clés différente, suivez cette politique et vérifiez la prise en charge par le serveur. Conservez une copie de récupération de la clé privée dûment protégée si votre plan de récupération en dépend.

Vérifiez le serveur avant de vous authentifier

Via la console de confiance ou un autre canal de configuration authentifié, obtenez l'empreinte de la clé d'hôte Ed25519 du serveur. Sur un serveur utilisant le chemin standard OpenSSH, un administrateur peut inspecter le fichier public avec :

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub -E sha256

Comparez l'empreinte complète SHA256 et l'algorithme avec la première invite de connexion SSH. Une empreinte récupérée uniquement via la même connexion réseau non vérifiée ne constitue pas une vérification indépendante. Si le serveur propose un autre algorithme de clé d'hôte, obtenez l'empreinte de cette clé plutôt que de comparer des valeurs dissemblables. les recommandations de vérification des clés d'hôte de OpenSSH expliquent cette comparaison.

Si la clé change de façon inattendue lors d'une visite ultérieure, arrêtez-vous. Une reconstruction peut légitimement remplacer les clés d'hôte, mais vérifiez cet événement et la nouvelle empreinte via le canal de récupération. Ne faites pas taire l'avertissement et ne supprimez pas l'ancienne entrée d'hôte connu simplement pour que la connexion aboutisse.

Installez uniquement la clé publique et ouvrez la première session

Si votre clé publique a déjà été installée via le processus de configuration autorisé, connectez-vous directement. Sinon, utilisez la méthode d'accès vérifiée existante pour ajouter la clé publique au compte prévu. Sur un client avec ssh-copy-id, et uniquement lorsque cette méthode de connexion initiale fonctionne, cette commande ajoute la clé publique sélectionnée :

ssh-copy-id -i "$HOME/.ssh/offvps_first_vps.pub" -p 22 [email protected]

Ubuntu’s OpenSSH guide décrit l'installation des clés publiques et les exigences de permissions. Ne remplacez pas un fichier entier authorized_keys ni ne modifiez les entrées d'un autre administrateur. Ouvrez ensuite la session basée sur clé :

ssh -o IdentitiesOnly=yes -i "$HOME/.ssh/offvps_first_vps" \
  -p 22 [email protected]

Après connexion, vérifiez id et hostname. Confirmez que le compte correspond aux détails de configuration ; un nom d'hôte seul ne constitue pas une vérification de clé d'hôte. Si vos tâches nécessitent une administration, exécutez sudo -v et établissez que ce compte dispose du chemin de privilège prévu. Gardez cette première session ouverte.

Prouvez une seconde connexion véritablement distincte

Ouvrez un autre terminal client et demandez une nouvelle connexion qui ne peut pas réutiliser un socket de partage de connexion SSH. Limitez ce test à l'authentification par clé publique afin qu'un repli par mot de passe ne masque pas une configuration de clé défectueuse :

ssh -o ControlMaster=no -o ControlPath=none \
  -o IdentitiesOnly=yes -o PreferredAuthentications=publickey \
  -i "$HOME/.ssh/offvps_first_vps" -p 22 [email protected]

Vérification id, hostname et, si nécessaire, sudo -v dans cette seconde session également. Un nouveau terminal seul est insuffisant si le client réutilise une connexion existante. ControlPath=none désactive ce partage ; voir OpenSSH client configuration. Ne fermez la session d'origine qu'après la réussite de cette connexion indépendante et tant que le chemin de récupération reste disponible.

Avant toute modification d'accès ultérieure

Pour cette première session, laissez le port SSH, les méthodes d'authentification et les règles de pare-feu tels quels. Avant de les modifier ultérieurement, enregistrez la configuration actuelle et documentez comment la restaurer via la console de confiance. Confirmez une connexion par clé fonctionnelle avant de désactiver une autre méthode. Gardez la première session ouverte en effectuant une modification révisée à la fois.

sudo /usr/sbin/sshd -t
sudo /usr/sbin/sshd -T

Sur les systèmes avec ce chemin d'exécutable OpenSSH, -t vérifie la syntaxe de configuration et la cohérence des clés d'hôte ; -T signale également les paramètres effectifs. Les règles Match propres à la connexion peuvent nécessiter des -C paramètres pour le compte et l'adresse testés. Ces vérifications ne testent pas l'accessibilité du pare-feu et ne prouvent pas qu'une nouvelle connexion fonctionne. Voir sshd test modes. Résolvez les erreurs avant d'appliquer ou de recharger une configuration de service, puis répétez la vérification de connexion indépendante.

Utilisez l'échec pour choisir la vérification suivante

• Délai d'attente : confirmez l'adresse, le port, les règles du fournisseur et le pare-feu de l'hôte via le chemin de récupération.
• Connexion refusée : vérifiez si SSH écoute sur l'adresse et le port attendus.
• Permission refusée : vérifiez le nom d'utilisateur, la clé publique sélectionnée et les permissions du fichier de clés du compte depuis la session encore ouverte.
• Identification de l'hôte modifiée : vérifiez indépendamment la machine et la nouvelle empreinte avant de continuer.

Consignez l'empreinte de clé d'hôte vérifiée, le compte, le port et la procédure de récupération dans vos notes d'exploitation. Gardez le matériel de clé privé. Une fois l'accès reproductible, passez à your first API release ou un budget de ressources pour l'application.