Johan: Oui, la directive « PermitRootLogin » est commentée par défaut ; l’accès root via ssh est donc autorisé par défaut.

Damned ! Tu veux dire que si on ne met pas « PermitRootLogin No » explicitement, c’est Yes qui est pris par défaut !!!!

Si c’est ça c’est une énorme erreur de conception de sshd.

Marcet: J’y avais pensé aussi. Mais dans ce cas, ça veut dire que l’on doit saisir deux mots de passe à chaque démarrage de sa machine : celui de la session et celui de la partition chiffrée, et ce, même si on ne se connecte pas en SSH lors de la session. Ce point me semble parfaitement évident. D’ailleurs, il me semble que sous Fedora, la configuration par défaut du daemon ssh ne permet pas la connexion root.

Malheureusement, non :/ En tous cas sous F-11, j’ai encore du éditer le sshd_config pour interdire la connexion ssh en root, et par la même occasion définir mon AllowedUsers..
C’est vrai que je ne l’avais pas spécifié, mais pas d’accès root via ssh chez moi non plus (sur aucune de mes machines), et utilisation de sudo au besoin.
@ peluche

shnoulle: Pour un bon équilibre entre sécurité et le coté pratique, on peut utiliser l’agent ssh pour se souvenir de la passphrase ssh ET chiffrer son disque dur ( Qui a dit luks ?). Même en cas de vol du PC avec les clés, l’agent ssh ne pourra pas être activé.

J’y avais pensé aussi. Mais dans ce cas, ça veut dire que l’on doit saisir deux mots de passe à chaque démarrage de sa machine : celui de la session et celui de la partition chiffrée, et ce, même si on ne se connecte pas en SSH lors de la session.

shnoulle: Autre chose concernant la sécurité, je n’utilise les clés ssh que sur des utilisateurs non root, qui peuvent passer root via un su ou un sudo. root n’a pas le droit de se connecter en ssh sur certaines de mes machines.

Ce point me semble parfaitement évident. D’ailleurs, il me semble que sous Fedora, la configuration par défaut du daemon ssh ne permet pas la connexion root.

Marcet: Je suis bien d’accord que si une machine à accès à d’autres sans mot de passe, et que quelqu’un s’empare de la dite machine, il y a un problème de sécurité.Mais ça reviens à peu près au même si la clé de chaque accès ssh est stockée dans le porte-clé de la session, non ?

Si la clé ne possède pas de mot de passe, il suffit de la choper elle, la solution de l’agent ne stocke pas le passe, il faudrait donc avoir accès à l’instance de l’agent pour laquelle le passe a été saisi pour s’en servir (un poil plus compliqué que d’accéder à un simple fichier).  En plus, si je prend ta clé sans mot de passe, je peux m’en servir quand je veux ; alors que je ne pourrai pas te piquer ton l’instance de ton agent (enfin, je ne crois pas).
Bien entendu, en termes de sécurité, la meilleure solution reste d’entrer le mot de passe de la clé à tous les coups (et que le dit mot de passe soit bien barbare, au passage :p).
La solution de l’agent est plus ou moins entre le mot de passe à tous les coups et pas de mot de passe du tout
Après, il peut être possible de ne pas conserver le passe pendant toute la durée de la session, ça renforcerait un peu plus la sécurité,  mais j’avoue n’avoir jamais cherché à faire ça
@ peluche

Johan: D’utiliser l’agent SSH ?

Je suis bien d’accord que si une machine à accès à d’autres sans mot de passe, et que quelqu’un s’empare de la dite machine, il y a un problème de sécurité.

Mais ça reviens à peu près au même si la clé de chaque accès ssh est stockée dans le porte-clé de la session, non ?

Johan: Anéfé J’avais publié un billet sur mon blog – pour faire le miroir d’un dépôt SVN – qui utilise cette technique de limitation à une commande particuilière : http://blog.ulysses.fr/index.php/post/16/10/2008/Subversion-:-comment-creer-un-miroir-de-facon-securisee Le plus dur, c’est encore de trouver sur quelle commande restreindre @ peluche

Merci. Super intéressant !