Discussion :

[jfbee]

Bonjour,


J'ai envie de faire un serveur SSH qui n'autorise que les identifications par clef DSA ou RSA et donc empêcher les connexions par mot de passe (pour éviter le brute forcing). Je sais comment mettre en place ceci mais j'ai une question : comment les utilisateurs vont pouvoir mettre leur clef publique dans leur "authorized_keys" s'il n'ont plus accès à leur compte de l'extérieur.

Faut-il qu'ils demandent à un admin de mettre leur clef publique dans leur "authorized_keys"? ou alors c'est l'admin qui génère le couple de clefs, les transmets à l'utilisateur et fait les modifications nécessaire dans le "authorized_keys".


Merci par avance

[lennelei]

En aucun cas tu ne peux demander à l'admin de générer le couple de clés ! C'est contraire aux bases même de la sécurisation.

Ca reviendrait à demander à l'admin de générer un mot de passe de 20 caractères comportant des chiffres, des lettres et des symboles, de le mettre en mot de passe des utilisateurs et d'empêcher ces derniers de le modifier Ca évitera le brut forcing... mais niveau sécurité, c'est nul, car tes utilisateurs vont être obligé de noter quelque chose quelque part... de plus, ils n'ont pas la main mise dessus, et l'admin connaît donc forcément leur clé.

Donc c'est forcément à l'utilisateur de générer ses propres clés.

A partir de ce moment là, je ne vois que 3 solutions:

1. autoriser le login par user/mdp classique pendant une certaine durée (par exemple une semaine), en indiquant à chaque connexion que l'utilisateur DOIT mettre une clé dans authorized_keys pour pouvoir se connecter après cette durée. A la fin de la période, désactiver l'accès par mdp.
2. réaliser un script quelconque (perl, php, ksh...) qui permettent de mettre à jour une clé à distance d'une manière ou d'une autre.
3. laisser un accès ftp ouvert quelque part (avec un user bidon). Les utilisateurs y déposent un fichier <login>_authorized_keys et un script balaye ce dossier, et met à jour les fichiers de chaque user en fonction

[jfbee]

Merci pour tes réponses.

Par contre je ne comprend pas en quoi le fait que l'administrateur génère la clef lui même force l'utilisateur a noter quoi que ce soit. Une clef c'est un simple fichier qu'il met dans son .ssh/ . Par contre je suis d'accord que ce n'est pas une super méthode par normalement les utilisateurs ont leur propre clef personnelle (unique ou en nombre restreint).

[lennelei]

En général, une clé est associée à une passphrase pour plus de sécurité.

[JeitEmgie]

En général, une clé est associée à une passphrase pour plus de sécurité.

sécurité toute relative…

en général ce que l'on voit dans le monde réel :
1. si la clé SSH est utilisée fréquemment par un humain, le mot de passe devient une gêne et les utilisateurs finissent par inventer des moyens pour que celui-ci soit donné automatiquement via par exemple des scripts expect ou d'autres outils… (surtout si le dit utilisateur a besoin de se connecter à nombre de machines différentes…) et ce mot de passe se retrouve donc en clair quelque part dans le système…

2. si la clé SSH doit être utilisée par des tâches automatisées le mot de passe devient plus qu'une gêne… et donc soit il n'est pas utilisé du tout… soit il est contourné par les mêmes moyens d'automatisation (expect and C°)…

Avoir un mot de passe sur une clé SSH c'est utile si vous voyagez avec vos clés sur un périphérique amovible (clé USB par exemple, ordinateur portable…) qui peut être facilement soit perdu, soit volé…

Sur une machine à demeure… cela devient vite emm…

Si vous voulez encore augmenter la sécurité, vous pouvez aussi spécifier côté serveur les adresses IP d'où peuvent se connecter les différentes clés… (par range si vous vous connectez d'adresses dynamiques…)
et alors n'utilisez from="*" que pour les clés protégées par mot de passe…

[lennelei]

Certes, mais il n'empêche qu'il vaut mieux une clé + un mot de passe qu'une clé seule ou un mot de passe seul ce qui était le but de ma remarque.

Après, c'est sur que sauf à utiliser la biométrie, l'utilisateur lambda aura toujours tendance à choisir un mot de passe faible, mais le fait de l'associer à une clé réduit un peu les risques.