Le 11 décembre 2017 à 08:31, Vincent a écrit :
> Une autre solution consiste à ne pas autorisé par défaut la clé à se
> connecter mais à juste garder une trace en commentaire de la clé public
> dans le fichier authorized_keys et l'activer quand cas de besoin.
> Biensûr, une clé par machine/utilisa
Le 11 décembre 2017 à 08:35, Andre Majorel a écrit :
> On 2017-12-09 17:32 +, Eric Degenetais wrote:
>
>> En fait, ça dépend du niveau de sécurité souhaité : il peut
>> être nécessaire de protéger la clef privée côté client par un
>> mot de passe pour éviter qu'elle soit volée. Dans ce cas,
>>
Une autre solution consiste à ne pas autorisé par défaut la clé à se
connecter mais à juste garder une trace en commentaire de la clé public
dans le fichier authorized_keys et l'activer quand cas de besoin.
Biensûr, une clé par machine/utilisateur n'authoriser qu'un utilisateur
à la fois.
On peut
On 2017-12-09 17:32 +, Eric Degenetais wrote:
> En fait, ça dépend du niveau de sécurité souhaité : il peut
> être nécessaire de protéger la clef privée côté client par un
> mot de passe pour éviter qu'elle soit volée. Dans ce cas,
> l'utilisateur doit entrer un mot de passe, avec les avantage
En fait, ça dépend du niveau de sécurité souhaité : il peut être nécessaire
de protéger la clef privée côté client par un mot de passe pour éviter
qu'elle soit volée. Dans ce cas, l'utilisateur doit entrer un mot de passe,
avec les avantages suivants sur un mot de passe classique :
1-le mot de pass
> > Le 9 déc. 2017 à 09:29, amandine SZCZYGIEL Z.elec wrote :
> > Le plus simple est de ne pas mettre de mot de passe et
> > d'utiliser une passkey avec un utilisateur crée spécifiquement
> > sur ta machine.
Avec une paire de clés publique et privée,
pas besoin de taper un mot de passe.
André
6 matches
Mail list logo
