Re: 2 demons sshd ?

Page principale

Répondre à ce message
Auteur: Steph
Date:  
À: guilde
Sujet: Re: 2 demons sshd ?
Guillaume Allegre wrote:
> Le Wed 26 Apr 2006 à 14:08 +0200, Guillaume Allegre a écrit :
>
>> Salut,
>>
>> Je voudrais mettre sur une machine une configuration un peu particulière
>> du démon sshd :
>> - autoriser toutes les identifications par mot de passe
>> - autoriser les identifications par clé publique uniquement depuis
>> certaines IPs (très limitées)
>>
>
> J'ai dit une bêtise là :
>
>> Avec sshd, la possibilité de restreindre l'écoute à certaines adresses
>> est prévue (#ListenAddress)
>>
> En fait, ListenAddress concerne l'adresse locale en écoute, et non pas
> quelles adresses sont autorisées à entrer.
>

Pour autoriser ou non certaines IP, en général, il vaut mieux utiliser
les /etc/hosts.allow et /etc/hosts.deny
> Du coup, mon interrogation reste, mais je ne vois pas comment m'y
> prendre. Des idées ?

J'ai pas vraiment de solution à te proposer.
1 - soit la connexion avec mot de passe est autorisée
2 - soit la connexion par clé publique/privée est la seule a être
autorisée, donc pas de mot de passe.

Avec un seul serveur, la solution qui s'approcherait le plus de ce que
tu veux faire, ça serait de prendre la solution 1 (connexion par mot de
passe pour tout le monde), et de rajouter la directive
*ChallengeResponseAuthentication* a "Yes" dans le fichier sshd_config du
serveur.
Quand un utilisateur va essayer de se connecter, le serveur va essayer
plusieurs méthodes d'authentification, en commençant (si je me rappelle
bien) par la plus sécurisée, clé RSA, clé DSA, clé IDENTITY, puis
éventuellement, si les autres méthode ont échoué, authenfication par mot
de passe.

En gros : l'utilisateur qui a une clé publique va se connecter tout de
suite sans que le serveur lui demande son mot de passe. Et celui qui n'a
pas de clé va devoir entrer son mot de passe puisque la méthode de
connexion par clé aura échouée.

MAIS (car il y a un "mais") : ça n'interdira en rien à l'utilisateur
avec clé publique de se connecter tout de même grâce à son mot de
passe... Dans ce type de config, la clé publique est juste là pour
éviter à l'utilisateur de taper son mot de passe, donc on gagne sur le
coté pratique, mais _on ne gagne rien en sécurité_

3 - La solution des deux serveurs ?
Deux serveur SSH sur deux ports différents sur la même machine (quid des
fichiers de conf ?), ça doit être possible, mais à mon avis, pas
conseillé...

L'idéal serait bien sur d'interdire la connexion avec mot de passe
(solution 2) et d'obliger tous les utilisateurs à envoyer leur clé
publique...

Mébon, ça, ça serait dans un monde idéal... :-)

Voilà. En espérant avoir un peu répondu à la question.

A+