Le chemin par défaut du fichier de clés du répertoire personnel n’était pas accessible en écriture
La question initiale sur ZimaOS, publiée en décembre 2024, concernait la procédure habituelle avec ~/.ssh/authorized_keys. La disposition en lecture seule du système empêchait l’auteur de créer ce fichier normalement. Les premières expérimentations du sujet n’ont pas abouti à une solution durable confirmée et ne doivent donc pas être présentées comme une solution définitive.
Un rapport ultérieur sur ZimaOS 1.7 utilisait un fichier de clés dans /etc
En août 2026, un autre membre de la communauté a signalé une méthode fonctionnelle sur ZimaOS 1.7. Il a placé les clés publiques dans /etc/ssh/authorized_keys et indiqué ce fichier au démon SSH. La configuration essentielle était la suivante :
AuthorizedKeysFile /etc/ssh/authorized_keysCréez le fichier avec les privilèges administrateur, ajoutez une clé publique complète par ligne et définissez des autorisations empêchant les autres utilisateurs de le modifier. Mettez ensuite à jour la configuration du serveur SSH et redémarrez le démon SSH. Comme cette méthode provient d’un résultat communautaire et non d’une déclaration officielle de compatibilité, vérifiez le fichier de configuration et le nom du service réellement utilisés par la version de ZimaOS installée avant de les modifier.
Testez la connexion par clé avant de désactiver l’authentification par mot de passe
Gardez la session SSH actuelle ouverte et conservez l’accès au terminal web de ZimaOS pendant les tests. Ouvrez un deuxième terminal et vérifiez que la clé publique permet d’établir une nouvelle session avec succès. Ce n’est qu’après ce test qu’il convient d’envisager d’éventuels paramètres de renforcement de la sécurité.
PasswordAuthentication no
KbdInteractiveAuthentication no
UsePAM no
PermitRootLogin no
PermitEmptyPasswords noCes paramètres ont des effets plus étendus que la simple modification du chemin des clés. Les appliquer avant d’avoir vérifié une connexion réussie par clé peut vous empêcher d’administrer le système à distance. Ils peuvent également ne pas convenir à tous les déploiements, notamment si le système dépend volontairement de PAM ou d’une procédure contrôlée de connexion root.
Considérez cette procédure comme spécifique à la version
La discussion s’étend sur près de deux ans, et le rapport confirmé mentionne spécifiquement ZimaOS 1.7. Il ne démontre pas que les mêmes fichiers subsistent après les mises à niveau ou se comportent de manière identique dans les versions antérieures. Consignez la modification et retestez l’accès SSH après une mise à jour du système d’exploitation.
FAQ
Pourquoi ne puis-je pas créer ~/.ssh/authorized_keys sur ZimaOS ?
Dans le cas initial, cette partie du système de fichiers était en lecture seule. La solution ultérieure a modifié l’emplacement des clés utilisé par le démon au lieu d’essayer de rendre accessible en écriture le chemin habituel du répertoire personnel.
Où la méthode fonctionnelle de ZimaOS 1.7 stockait-elle les clés publiques ?
Elle les plaçait dans /etc/ssh/authorized_keys et configurait AuthorizedKeysFile pour pointer vers cet emplacement.
Faut-il désactiver immédiatement l’authentification par mot de passe ?
Non. Conservez d’abord une session de récupération disponible et vérifiez une nouvelle connexion authentifiée par clé. Désactivez les autres méthodes d’authentification uniquement après ce test et seulement si elles correspondent à la politique d’accès du système.
