Configurer des clés SSH sans perte d'accès

Génération et identification locale de la clé

Sur un client OpenSSH récent, création d'une clé dédiée ssh-keygen -t ed25519 -a 100 -f ~/.ssh/vpseverywhere_admin. Saisissez une phrase secrète robuste lorsque vous y êtes invité. La commande crée un fichier privé nommé vpseverywhere_admin et un fichier public nommé vpseverywhere_admin.pub. Si Ed25519 est indisponible en raison d'une contrainte de compatibilité ou de politique spécifique, choisissez une configuration RSA approuvée pour cet environnement plutôt que de copier une ancienne clé.

Affichez l'empreinte de la clé publique avec ssh-keygen -lf ~/.ssh/vpseverywhere_admin.pub. Enregistrez l'empreinte dans un enregistrement de confiance. N'imprimez ni ne transmettez le fichier privé et ne le collez pas dans un champ du tableau de bord intitulé « Clé SSH » ; ce champ doit accepter la clé publique sur une seule ligne commençant par ssh-ed25519.

• Utilisez une clé distincte pour l'administration plutôt qu'une clé partagée pour l'équipe.
• Protégez le périphérique local avec le chiffrement du disque et les mises à jour.
• Sauvegardez la clé privée uniquement dans un espace de stockage chiffré et à accès contrôlé.

Installez la clé publique.

Lorsqu'un accès par mot de passe est temporairement disponible, installez la clé publique avec ssh-copy-id -i ~/.ssh/vpseverywhere_admin.pub USER@SERVER_IP, en remplaçant les deux espaces réservés. Vous pouvez également ajouter la ligne de clé publique exacte via l'interface de configuration de votre fournisseur. Si vous effectuez une modification manuelle sur le VPS, le répertoire ~/.ssh de l'utilisateur cible doit lui appartenir et avoir les permissions 700 ; le répertoire authorized_keys doit avoir les permissions 600.

Connectez-vous explicitement avec ssh -i ~/.ssh/vpseverywhere_admin USER@SERVER_IP. Lors de la première connexion, vérifiez l'empreinte de la clé hôte du serveur auprès d'une source indépendante et fiable avant de l'accepter. Une clé hôte modifiée peut être légitime après une réinstallation, mais elle peut également indiquer une interception ou que l'adresse appartient désormais à un autre serveur.

• Ne résolvez jamais un avertissement de clé hôte en supprimant aveuglément l'ancien enregistrement.
• Utilisez un administrateur non root nommé lorsque cela est possible.
• Conservez la clé de chaque utilisateur sur une ligne distincte pour une révocation propre.

Fiabilitéez l'utilisation quotidienne.

Créez un alias de client SSH local dans ~/.ssh/config avec un nom d'hôte, une adresse du nom d'hôte, un compte utilisateur et IdentityFile ~/.ssh/vpseverywhere_admin. Configurez le fichier de configuration pour qu'il ne soit accessible en lecture que par votre compte lorsque le système d'exploitation l'exige. Un agent SSH peut réduire la saisie répétée de la phrase de passe, mais déverrouillez les clés uniquement sur les appareils de confiance et évitez de transférer l'agent vers des hôtes non fiables.

Pour les équipes, attribuez des clés publiques individuelles via la gestion de la configuration et supprimez-les rapidement une fois l'accès terminé. Ne diffusez pas une seule clé privée via les systèmes de messagerie instantanée ou de tickets. Les clés matérielles peuvent renforcer l'administration des ressources sensibles lorsque le client et le serveur prennent en charge le type choisi.

• Nommez les clés en fonction du rôle et de l'environnement sans y intégrer de secret.
• Vérifiez les clés autorisées après chaque changement de personnel ou d'automatisation.
• Utilisez des durées de vie courtes et contrôlées pour les agents sur les postes de travail partagés.

Désactivez les chemins d'accès les plus faibles uniquement après les avoir testés.

Gardez la session actuelle ouverte, ouvrez un second terminal et vérifiez que la nouvelle clé permet de se connecter et d'exécuter la commande d'administration souhaitée. Validez ensuite toute modification du serveur SSH avec sudo sshd -t avant sudo systemctl reload ssh. L'authentification par mot de passe et la connexion root directe peuvent être désactivées lorsqu'aucun utilisateur ou automatisation n'en dépend.

Conservez une procédure de récupération via la console du fournisseur et documentez la procédure de restauration d'accès. Le retrait d'une clé perdue est urgent ; la perte de la seule clé fonctionnelle sans accès à la console entraîne une interruption de service.