Une mauvaise configuration du serveur ssh peut amener à perdre la main sur une machine. La résolution d'un tel problème ne peut alors passer que par un accès physique à la machine. Pour éviter d'en arriver là, il vaut mieux respecter quelques règles de prudence, même si elles semblent un peu contraignantes.
Préliminaires
La première chose à faire avant de se lancer dans la reconfiguration, même minime, d'un programme vital, est de se demander si c'est le bon moment : évaluer son propre état de fatigue, d'alcoolémie, le temps qu'on a devant soi dans le cas où tout ne se passerait pas comme prévu, l'urgence réelle ou supposée de la tâche, etc.
Ensuite, si le moment est jugé opportun, alors commencer par lire ou relire la documentation :
- les pages de manuel relatives au programme et à ses fichiers de configuration;
- les pages du wiki-admin relatives au programme et à sa configuration courante, les raisons des choix précédents;
- éventuellement, des pages web traitant du même sujet.
Ensuite, on peut y aller posément, mais pas sans filet…
Procédure
La configuration du serveur est dans /etc/ssh/sshd_config. L'édition
de ce fichier ne pose pas de problème particulier, dans la mesure où
les changements ne sont pas pris en compte avant le redémarrage du
serveur, qui se fait avec la commande :
sudo service ssh restart
Non seulement cette commande n'interrompt pas les connexions en cours, mais celles-ci continuent d'hériter de la configuration qu'avait le serveur au moment de l'établissement de la connexion.
À ce moment là, c'est à dire quand le serveur a été redémarré, il est impératif de :
- garder ouverte la connexion en cours;
- ouvrir une autre connexion pour s'assurer qu'on a toujours un accès shell à la machine avec les nouveaux paramètres.
NOTE : Pour être sûr de ne pas réutiliser la même session ssh (par exemple
si on utilise le multiplexing), on peut préférer utiliser
ssh -o ControlMaster=no -o ControlPath=/var/empty
Évidemment, si le deuxième point échoue, recommencer le cycle :
- édition du fichier de configuration
- redémarrage du serveur
- établir une nouvelle connexion
S'il n'y a pas de problème, on peut se contenter de
sudo etckeeper commit
et couper les connexions; la suite est optionnelle.
Si les modifications sont relatives à la création d'un espace de stockage
de fichiers, on peut vérifier le
résultat en établissant une connexion supplémentaire par sftp pour accéder
à cet espace de stockage en se faisant passer pour son propriétaire (c'est
à dire en copiant sa propre clef publique en tant que .ssh/authorized_keys2
du compte qu'on vient de créer - sans oublier de l'enlever ensuite, hein).
En revanche, si les modifications portent sur la directive Match relative à la
reconfiguration d'un espace de stockage
déjà peuplé, les règles élémentaires de bienséance et de déontologie imposent de
ne pas y mettre le nez avant de recevoir un e-mail de mécontentement.