Le blog de Laurent - unix

Ubuntu, ssh et PermitRootLogin...

Laurent — Sat, 06 Oct 2007 00:29:00 +0200

Ca pourrait être le titre d'une sitcom comme "Amour, Gloire et Beauté" ^[1] mais c'est plutôt quelque chose qui m'a déçu légèrement auprès d'Ubuntu : "par défaut" le serveur ssh est configuré avec PermitRootLogin à on. Pour ceux qui ne parlent pas le ssh couramment, cela veut dire que ssh autorise un utilisateur externe à se connecter à la machine directement en superutilisateur (avec tous les droits) à condition bien sûr qu'il donne le bon mot de passe. Mais comme Ubuntu n'active pas le mot de passe root -"par défaut"- c'est donc quelque chose d'impossible (sauf si l'administrateur de la machine a installé un mot de passe pour root). L'honneur est donc sauf ?

Pour moi, clairement non: deux précautions valent mieux qu'une et quand on voit le nombre de tentatives faites directement sur le compte root^[2], je pense franchement que c'est un peu tirer le diable par la queue. Malheureusement ce n'est pour l'instant pas l'avis des mainteneurs Ubuntu de ssh (et manifestement de ceux d'OpenBSD).

Moralité: être parano en matière de sécurité, ne pas faire aveuglement confiance dans les réglages faits par d'autres (fussent-ils les mainteneurs de ma distribution préférée).

PS: PermitRootLogin ne prend pas uniquement "on" et "off" comme valeurs, il prend aussi "without-password" qui autorise l'authentification par clef publique uniquement et "forced-commands-only" qui autorise uniquement l'authentification par clef publique et l'execution d'une commande précise (à préciser dans le fichier authorized_keys, potentiellement utile pour lancer un backup par exemple)

Notes

[1] Je viens d'ailleurs de comprendre que "Amour, Gloire et Beauté" sur France 2 et "Top Models" sur RTL9 sont en fait la même série

[2] ne pensez pas que votre compte "toto" soit à l'abri, il est juste essayé moins frequemment

Lancer un script mysql sans donner ni l'utilisateur ni le mot de passe sur la ligne de commande

Laurent — Wed, 03 Oct 2007 23:43:00 +0200

Voici mon problème du jour : Comment lancer un script (de maintenance par exemple) qui fait appel à mysql, sans stocker en dur le nom de l'utilisateur et le mot de passe (ce qui est mal, très très mal). Le but est que seul un utilisateur privilégié (je n'ai pas forcément dit root ! je pense plutôt à un compte système comme mysql par exemple) puisse lancer ce script.

C'est plutôt facile, et je fournis trois solutions pour la peine :

Avoir un fichier de configuration pour le script accessible seulement par l'utilisateur privilégié
On définit dans le fichier de configuration des variables d'environnement, une pour le user, une autre pour le mot de passe. Dans le script il ne reste qu'à utiliser la commande source pour récuperer ses variables (seul l'utilisateur privilégié pourra lire le fichier). Simple et efficace.
Avoir un fichier de configuration pour mysql accessible seulement par l'utilisateur privilégié
Variante de la précédente : on crée un fichier de configuration spécifique pour mysql (que l'on pourra mettre par exemple dans /etc/mysql mais il n'y a aucune obligation). Et on utilise l'option --defaults-file pour que mysql lise le contenu du fichier (il lit notamment les sections [client] et [mysql]). Exemple de fichier:
```
[client]
host     = localhost
user     = votre_user
password = votre_mot_de_passe
socket   = /var/run/mysqld/mysqld.sock
```
Bonus : on peut spécifier d'autres options pour influer sur mysql (en vrac, le nom de serveur, le jeu de caractères...).
Pour ceux qui ont plusieurs scripts mais qui ont des options qui diffèrent légèrement
Vous avez des scripts quasiment identiques mais les options diffèrent légèrement (ou vous voulez centraliser tout en un seul fichier) : c'est possible. C'est une variante du cas précedent : on écrit un fichier de configuration mysql que l'on découpe en plusieurs sections. Ensuite, on fait appel au programme my_print_defaults ! my_print_defaults examine le fichier de configuration (option -c pour spécifier le votre...) et donne en sortie les paramètres à passer à mysql sous forme d'argument. Exemple :
```
$ my_print_defaults -c /etc/mysql/maconf.cnf client 
--host=localhost
--user=votre_user
--password=votre_mot_de_passe
--socket=/var/run/mysqld/mysqld.sock
```
Il ne reste plus qu'à passer cela à mysql en récuperant la sortie dans une variable (ou en utilisant cette petite merveille de xargs).

Petit truc en vrac

Laurent — Tue, 02 Oct 2007 23:15:00 +0200

Je suis souvent confronté à des petits problèmes dont je ne trouve pas immédiatement la solution (ce qui n'engendre chez moi que frustration et désespoir, et chez certains de mes collègues une perte de leur capacité auditive). Et parfois, après, alors que j'étais sur totalement autre chose, je découvre ce que je cherchais désespérement. Si, si.

Dans le principe que "Si j'ai ce problème, il y a de fortes chances que d'autres soient dans le même cas de figure", voici le premier billet d'une probablement longue série.

Problème: Comment executer un script au démarrage d'une machine quand on n'est pas root !
Quelques précisions: l'un de mes amis et colocataires de notre serveur dédié utilise fetchmail. Mais à chaque fois qu'il y a reboot du serveur (ce qui est arrivé une ou deux fois), adieu fetchmail... Donc pour parer à cela, il a ajouté un script dans sa crontab pour vérifier toutes les heures si fetchmail est démarré, et dans le cas contraire, le script lance fetchmail. Pas mal mais peut on faire mieux ?

La réponse est oui, du moins si on utilise Vixie cron (le cron par défaut d'ubuntu et de tant d'autres) dans sa version 3 (qui date de 1993). Oui, ce bon vieux cron que l'on croit seulement capable de lancer des tâches périodiquement. En faisant un simple man 5 crontab, on tombe sur ce paragraphe:

À la place des cinq premiers champs peut apparaître l’une des huit chaînes spéciales :

              chaîne         signification
              ------         -------
              @reboot        Exécuter une fois au démarrage.
              @yearly        Exécuter une fois par an, « 0 0 1 1 * ».
              @annually      (idem que @yearly)
              @monthly       Exécuter une fois par mois, « 0 0 1 * * ».
              @weekly        Exécuter une fois par semaine, « 0 0 * * 0 ».
              @daily         Exécuter une fois par jour, « 0 0 * * * ».
              @midnight      (idem que @daily)
              @hourly        Exécuter une fois par heure, « 0 * * * * ».

et oui un simple @reboot et le tour est joué...