Résoudre les erreurs de permission SSH au sein de votre application
Les nouveaux utilisateurs de SSH se heurtent souvent à un obstacle. Ils voient cette erreur :
WARNING: UNPROTECTED PRIVATE KEY FILE!
Permissions 0644 for 'id_rsa.pem' are too open.
La solution est une simple commande de terminal : chmod 600 id_rsa.pem. Pour les ingénieurs, c'est facile. Pour le personnel d'agence ou les opérateurs informatiques qui n'utilisent pas de terminaux, c'est un obstacle majeur. Cela entraîne une multiplication des tickets de support.
Nous avons décidé de résoudre ce problème directement dans notre application. Nous avons conçu un système pour diagnostiquer et corriger les permissions automatiquement.
Le Problème
OpenSSH refuse de charger une clé privée si les permissions sont trop permissives. Si d'autres personnes peuvent lire votre clé, votre sécurité est compromise. La plupart des clés sont par défaut en 0644, ce qui les rend lisibles par tous. OpenSSH exige le mode 0600.
Notre Solution
Nous utilisons une approche en deux phases pour gérer cela.
Phase 1 : Récupération après échec Si une connexion échoue en raison des permissions, l'interface utilisateur affiche un bouton « Corriger et réessayer ». Cliquer dessus exécute la correction et tente de rétablir la connexion.
Phase 2 : Prévention avant la connexion L'application inspecte le chemin de la clé avant que l'utilisateur ne clique sur « se connecter ». Si les permissions sont incorrectes, nous affichons un avertissement. L'utilisateur choisit de les corriger ou de se connecter en l'état.
Nous gérons également Windows différemment. Windows utilise des ACL au lieu des permissions Unix. Notre code détecte la plateforme et exécute la commande appropriée, comme icacls, pour corriger l'accès.
Pourquoi nous ne corrigeons pas automatiquement et en silence
Nous avons envisagé de corriger les clés automatiquement au démarrage. Nous avons rejeté cette idée. Certains flux de travail nécessitent des permissions spécifiques pour les clés partagées. Si nous les modifions sans demander, nous perturbons le flux de travail de l'utilisateur.
Notre règle est simple : nous diagnostiquons tout, mais nous ne modifions les fichiers que lorsque l'utilisateur clique sur un bouton.
Le Résultat
Créer une expérience utilisateur (UX) qui absorbe les obstacles techniques réduit le volume de support. Nous montrons à l'utilisateur ce qui ne va pas et proposons une correction en un clic. Cela lève la barrière psychologique liée à l'utilisation d'un terminal.