[Tuto] SSH, mode console avec échange de clé : Une seule règle pour accéder à tous vos serveurs SSH

MilesTEG a dit:
Bon à priori ça doit pouvoir se faire en mettant le masque de sous-réseau, comme ceci :
Code: 
AllowUsers root@192.168.2.28 root@192.168.2.30 root@192.168.2.80 root@192.168.2.0/24 root@192.168.10.0/24 root@192.168.2.12/24
Ça te parait correct ?
Cliquez pour agrandir...

Je pense qu'il faut plutôt mettre les masques réseaux sous cette forme :

Code: 
root@192.168.2.* root@192.168.10.*

Ils vont englobés les 2 premiers (2.28 et 2.30) et le dernier de ta liste (pourquoi 192.168.2.12/24 ?)
 
Bambusa29 a dit:
Je pense qu'il faut plutôt mettre les masques réseaux sous cette forme :

Code: 
root@192.168.2.* root@192.168.10.*

Ils vont englobés les 2 premiers (2.28 et 2.30) et le dernier de ta liste (pourquoi 192.168.2.12/24 ?)
Cliquez pour agrandir...
Je viens de trouver ceci :
https://manpages.ubuntu.com/manpages/noble/en/man5/sshd_config.5.html
1712844176637.png
Et : https://manpages.ubuntu.com/manpages/noble/en/man5/ssh_config.5.html
1712844263179.png

Du coup je dirais que les deux devraient fonctionner, non ?
Je vais tenter avec le masque CIDR.

Pour la plage 192.168.2.12/24, c'est une erreur de frappe, je voulais écrire 192.168.12.0/24.
Et c'est celle du VPN Wireguard dans la MV Proxmox.
Mais j'ai un peu de mal à savoir si je serais vu avec une IP en 192.168.12.xxx ou bien si ce sera la machine hébergeant le serveur VPN, donc l'IP de la VM qui sera vue.
Si c'est cette dernière, alors, ce sera une IP fixe ^^
 

Pièces jointes

  • 1712844329248.png
    1712844329248.png
    235.6 KB · Affichages: 0
Dernière édition:
Bon j'ai du merder quelque part...
j'ai ce message sur mon client :
Code: 
No ED25519 host key is known for [nuc1.mon.lan]:1234 and you have requested strict checking.
Host key verification failed.
 
Salut, @Bambusa29
J'ai réussi à faire fonctionner la connexion par clé SSH mais sans le fichier /etc/ssh/sshd_config.d/ssh_keys.confci-dessous :
Code: 
# ╔══════════════════════════════════════════════════════════════════════════╗
# ║ Fichier ssh_keys.conf                                                    ║
# ║ à copier sur le serveur SSH dans                                         ║
# ║         /etc/ssh/sshd_config.d/ssh_keys.conf                             ║
# ╚══════════════════════════════════════════════════════════════════════════╝

Port 1234
SyslogFacility AUTH
LogLevel INFO
LoginGraceTime 2m
PermitRootLogin yes
AllowGroups ssh
AllowUsers root@192.168.2.28 root@192.168.2.30 root@192.168.2.80 root@192.168.2.142 root@192.168.2.0/24 root@192.168.10.0/24 root@192.168.12.0/24
PermitEmptyPasswords no
StrictModes yes
MaxAuthTries 6
MaxSessions 10

Match user root
    PubkeyAuthentication yes
    PasswordAuthentication no
    ChallengeResponseAuthentication no
Match all

X11Forwarding no
Car si je le met, pouf, la connexion ne se fait pas, et j'ai ce message :
Code: 
╰ ssh nuc1
root@nuc1.miles.lan: Permission denied (publickey).

Ensuite, j'ai fait d'autres actions pour que ça fonctionne sans ce fichier sur le serveur, ton tuto manque d'informations pour un novice comme moi.
Si tu es d'accord, je proposerais plus bas (et plus tard) une version modifiée qui ajoutera les éléments manquants, et qui remettra dans un ordre cohérent les différentes étapes.

Donc ce que j'ai fait et qui n'est pas décrit dans le tuto :
  • Ajouter la clé publique sur le serveur avec ssh-copy-id :
    Code: 
    ssh-copy-id -p 1234 -i ~/.ssh/nuc1.miles.lan.pub root@nuc1.miles.lan
  • Ajouter la clé privée sur le client avec ssh-add :
    Code: 
    ssh-add ~/.ssh/nuc1.miles.lan.pub root@nuc1.miles.lan
    Sans cet ajout, pas moyen de me connecter avec la clé, j'avais toujours la demande du mot de passe du compte root.
Ce que j'ai fait grâce au tuto (listé dans le désordre) :
  • Mettre le fichier de configuration du client /Users/miles/.ssh/config (je suis sous macOS, sinon, ce serait ici /home/user/.ssh/config ) :
  • Code: 
    # ╔══════════════════════════════════════════════════════════════════════════╗
# ║ Fichier config                                                           ║
# ║ Configuration de SSH sur l'ordinateur client                             ║
# ║ à placer dans le dossier ${HOME}/.ssh                                    ║
# ║ Sous macOS : /Users/miles/.ssh                                           ║
# ╚══════════════════════════════════════════════════════════════════════════╝
Host syno
    User admin-syno
Host asustor
    User admin-ast
Host *
    HostName %h.miles.lan
    User root
    Port 1234
    IdentityFile /Users/miles/.ssh/%h.pub
    IdentitiesOnly yes
    StrictHostKeyChecking yes
  • Placé le fichier de configuration du serveur ici : /etc/ssh/sshd_config.d/ssh_keys.conf
    voir son code au-dessus.
  • Mis les permissions sur les dossiers et fichiers (qui étaient déjà OK).
  • Créé les clés privées et publiques avec un petit script pour ne pas avoir à tout faire à la main (oui, écrire le script aura été plus long que de tout taper mais bon XD, si jamais je dois refaire tout ça sur un autre ordinateur (linux, ou windows notamment), ça me sera utile.
    Script ZSH posté plus bas.
Maintenant, il me reste à comprendre ce qui ne va pas avec ma configuration sur le serveur.
@Bambusa29 Si tu comprends, je suis preneur :)
PS : pour le moment je laisse la clé privée dans le dossier .ssh de mon ordinateur, je verrais plus tard comment faire en sorte qu'elle soit dans un coffre bitwarden ou autre.

Le script pour générer les clés privées et publique, ainsi que les passphrases.
Il sera amélioré plus tard quand j'aurais réussi à faire fonctionner la connexion avec le fichier de configuration sur le serveur avec les commandes ssh-copy-id et ssh-add. Et aussi avec la copie du fichier de configuration sur le client et aussi sur l'hôte.
Bash: 
#!/bin/zsh
#
# Version : 1.1
#
# Script de configuration des clés SSH sur le client
#
# Nécessite les binaires suivants :
#   Bitwarden-CLI : bw          <-- brewi bitwarden-cli
#  

# ~~~~~~~~~~~~~ Some variables ~~~~~~~~~~~~ #

declare -a alias_ARRAY=("nuc1" "nuc2" "nuc3" "pbs-ast" "syno" "asustor" "rt")
declare -a user_ARRAY=("root" "root" "root" "root" "syno-admin" "ast-ssh-admin" "rt-admin")

hostname_end="miles.lan"

ssh_dir=${HOME}/.ssh
copy_dir="/Users/miles/path_to/Clés-SSH/config_client"
write_passphrase_to_file=""
# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ #



# ~~~~~~~ Some functions definitions ~~~~~~ #

function yes_or_no {
    # Source : https://stackoverflow.com/a/29436423/17694638
    #    and : https://linuxconfig.org/bash-script-yes-no-prompt-example
    #    and : https://9to5answer.com/how-can-i-prompt-for-yes-no-style-confirmation-in-a-zsh-script
    while true; do
        if [ -n "$ZSH_VERSION" ]; then
            # SHELL = ZSH
            # read -q "REPLY?Press y/Y to continue with $MESSAGE :"
            # read -q "choice?"
            read -q "choice? [y/n] : "
        elif [[ "${SHELL}" == *"bash"* ]]; then
            # SHELL = BASH
            read -p "$* [y/n]: " CHOICE
        fi
        printf "\nChoix : %s\n" "${choice}"
       
        case $choice in
            y )
                # echo "YES selected !"
                return 0
                ;;
            n )
                # echo "Aborted azdadaz"
                return 1
                ;;
            *) printf "\nInvalid response!\n" ;;
        esac
    done
}
# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ #

# ~~~~~~~~~~~~~~ Main script ~~~~~~~~~~~~~~ #
printf "\n-> Heure : %s" "$(date +"%Hh %Mm %Ss")"

printf "\nVoudrez-vous stocker les passphrases dans un fichier qu'il faudra supprimer manuellement après récupération de ses données ?\n"
yes_or_no
# echo $?
if (( $? == 0 )); then
    write_passphrase_to_file="yes"
    pass_file=${HOME}"/passphrase-TO_BE_DELETED.pass"
    touch "${pass_file}"
    echo "Liste de passphrase générés par Bitwarden CLI" > "${pass_file}"

else
    write_passphrase_to_file="no"
fi

printf "\nAttention, ce script va écrire la clé dans un fichier, qui s'il existe, sera effacé et recréé.\n"
printf "Voulez-vous continuer l'exécution du script ? (Oui, ou Non pour arrêter le script pour sauvegarder manuellement les clés existante ?\n"
yes_or_no
if (( $? == 1 )); then
    printf "\nFin du script !\n"
    exit 0
fi

for alias_i in "${alias_ARRAY[@]}"; do
    # Récupérer l'indice d'un tableau : https://unix.stackexchange.com/a/334049
    index="${alias_ARRAY[(ie)$alias_i]}"
    user_i="${user_ARRAY[$index]}"
    fichier_cle="${ssh_dir}/${alias_i}.${hostname_end}"

    hostname_i="${user_i}@${alias_i}.${hostname_end}"

    creation_cle=1      # 1 = on crée la clé | 0 on ne crée pas la clé

    PASSPHRASE_1=""
    PASSPHRASE_2=" "

    printf "\n\nCréation de la clé ssh pour \"%s\"\n" "${hostname_i}"

    printf "\nVoulez-vous générer une clé avec l'outils Bitwarden CLI (qui doit être préalablement installé) ?"
   
    yes_or_no
    # echo $?
    if (( $? == 0 )); then
        printf "\nGénération de la passphrase par bw cli..."
        # Avec la version macOS, il y a un avertissement "DeprecationWarning: The `punycode` module is deprecated."
        # donc pour le neutraliser il faut lancer la commande avec une variable NODE_OPTIONS="--no-deprecation"
        PASSPHRASE_1=$(NODE_OPTIONS="--no-deprecation" bw generate --passphrase --words 10 --separator - --capitalize --includeNumber)
    else
        while [[ "${PASSPHRASE_1}" != "${PASSPHRASE_2}" ]]; do
            printf "\tEntrer (coller) la Passphrase pour cet hôte : "
            printf "\n\tEntrer à nouveau (coller) la Passphrase pour cet hôte : "
            read -s PASSPHRASE_2


            if [[ "${PASSPHRASE_1}" == "${PASSPHRASE_2}" ]]; then
                printf "\n\nLes deux passphrases entrées sont identique, on peut continuer.\n"
            else
                printf "\nLes deux passphrases entrées ne sont pas identiques. Veuillez recommencer.\n"
            fi
        done
    fi
    printf "\n\t--> Hostname : \"%s\": " "${hostname_i}"
    printf "La passphrase pour est : %s"  "${PASSPHRASE_1}"
    if [[ "${write_passphrase_to_file}" == "yes" ]]; then
        printf "\n\tÉcriture de la passphrase dans le fichier temporaire '${pass_file}'"
        printf "\n%s :\n%s\n\n" "${hostname_i}" "${PASSPHRASE_1}" >> "${pass_file}"
    fi
   
    if [ -f "${fichier_cle}" ]; then
        printf "\nLa clé %s existe déjà, voulez-vous la recréer ?\n" "${fichier_cle}"
        # fichier_cle=$(yes_or_no)
    fi

    if (( $creation_cle == 1 )); then
        ssh-keygen -t ed25519 -C "${hostname_i}" -N "${PASSPHRASE}" -f "${fichier_cle}" <<< y
        cp "${fichier_cle}" "${copy_dir}"
    fi
    PASSPHRASE_1=""
done
printf "\n---- Fin de création des clés SSH locales ----\n"
printf "-> Heure : %s\n" "$(date +"%Hh %Mm %Ss")"

# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ #


Voilà voilà :)
Merci pour l'aide déjà apportée et la future ^^
 
Dernière édition:
Je vois deux problèmes potentiels :

Il faut coté serveur que le fichier des clés publiques porte le nom "authorized_keys"
Je vois que tu as mis des clés publiques dans ton fichier "config" coté client. Dans la ligne 'IdentityFile', il faut les clés privées (sans le .pub) !!

Avant de pouvoir utilisez la connexion par clés, il faut faire une première connexion sans indiqué de clé pour mémoriser la clé serveur dans le fichier "known_hosts" coté client.

known_hosts.png

Concrètement je procède ainsi pour chaque nouvelle connexion :

1) Je crée ma clé public _ privée : exemple avec mon container invidious :​

Code: 
ssh-keygen -t ed25519 -C "invidious@yannick.lan" -N "passwd" -f /home/yannick/.ssh/invidious.yannick.lan

Je remplace "passwd' par la passphrase choisie.

2) Je copie ma clé public généré coté serveur (je ne le fais pas avec ssh-copy) :​

Bash: 
nano /home/user/.ssh/authorized_keys

Puis je fais un copier coller de la ligne contenant la clé publique.

3) Je met à jour la config ssh du serveur si besoin, je met à jour et je vérifie le port :​

Code: 
sudo systemctl reload ssh
sudo systemctl restart ssh
sudo systemctl status ssh

4) J'initialise la connexion pour l'enregistrer dans le fichier "known_hosts" :​

Le renomme provisoirement mon fichier config et je tape les commandes suivantes.
Je réponds 'yes' pour enregistrer la clé serveur.

Bash: 
mv /home/miles/.ssh/config /home/miles/.ssh/config.old
ssh user@invidious.domaine -p 1122
mv /home/miles/.ssh/config.old /home/miles/.ssh/config

5) Je me connecte avec le fichier de config :​

Bash: 
ssh invidious
 
Dernière édition:
@Bambusa29
Avant de répondre à ton message précédent, j'ai réussi à trouver où ça bloquait :) J'explique après, mais ça n'est en rien la méthode utilisée pour envoyer la clé publique sur le serveur.
Ton point 1 : nickel, j'ai fait pareil, si ce n'est avec mon script ^^
Bambusa29 a dit:
2) Je copie ma clé public généré coté serveur (je ne le fais pas avec ssh-copy) :
Bash: 
nano /home/user/.ssh/authorized_keys
PS : je pense que ton problème vient de là !! Il faut que coté serveur le fichier porte ce nom là "authorized_keys"

Puis je fais un copier coller de la ligne contenant la clé publique.
Cliquez pour agrandir...
Et bien, en fait ce que tu fais manuellement, la commande ssh-copy-id le fait elle-même, elle ajoute la clé au fichier /home/user/.ssh/authorized_keys ou crée le fichier (c'est une supposition) s'il n'existe pas.

Bambusa29 a dit:
3) Je met à jour la config ssh du serveur si besoin, je met à jour et je vérifie le port :
Code: 
sudo systemctl reload ssh
sudo systemctl restart ssh
sudo systemctl status ssh
Cliquez pour agrandir...
Ha merci pour ces commandes, moi j'utilisais celles-là, ne sachant pas trop laquelle fonctionne :
Bash: 
systemctl reload ssh.service && /etc/init.d/ssh restart

Bambusa29 a dit:
4) J'initialise la connexion pour l'enregistrer dans le fichier "known_hosts" :
Le renomme provisoirement mon fichier config et je tape les commandes suivantes.
Je réponds 'yes' pour enregistrer la clé serveur.

Bash: 
mv /home/miles/.ssh/config /home/miles/.ssh/config.old
ssh user@invidious.domaine -p 1122
mv /home/miles/.ssh/config.old /home/miles/.ssh/config
Cliquez pour agrandir...
Ha, merci pour cette méthode.
Mais en examinant ce qui a été ajouté dans le fichier known_hosts, je vois que ce qui est présent derrière
[nuc1.miles.lan]:1234 ssh-ed25519 est identique à ce que j'ai derrière l'adresse IP de ce nuc1.
Du coup, je pourrais lancer un script qui m'ajouterais automatiquement une ligne avec le nom de domaine .lan pour chaque adresse IP présente, moyennant le fait de valider que l'IP déjà présente corresponde bien au serveur du .lan donc le bon hash qui suit.
En ce qui me concerne c'est OK, puisque j'ai déjà accédé à tous mes serveurs en ssh.

Cependant, pour tout nouveau serveur, il faudra probablement faire ta manip, sinon je ne pourrai pas m'y connecter dessus.

Enfin, tous mes raccourcis dans iTerm2 sont à refaire XD ils utilisent l'adresse IP...

Il n'y a pas une méthode pour conserver l'accès via IP, tout en gardant celle via NDD ?
 
MilesTEG a dit:
Il n'y a pas une méthode pour conserver l'accès via IP, tout en gardant celle via NDD ?
Cliquez pour agrandir...

J'ai rajouté une ligne entre temps, mais si cela fonctionne, cela ne venait pas de là :

Je vois que tu as mis des clés publiques dans ton fichier "config" coté client. Dans la ligne 'IdentityFile', il faut les clés privées (sans le .pub) !!

Si je pense que cela est possible si tu met toutes les connexions via IP en priorité dans ton fichier "config" et ta section suivante a la fin :

Bash: 
Host 192.168.2.10
    HostName 192.168.2.10
    User root
    Port 1234
    IdentityFile /Users/miles/.ssh/tacleprive
    IdentitiesOnly yes
    StrictHostKeyChecking yes

...

Host *
    HostName %h.miles.lan
    User root
    Port 1234
    IdentityFile /Users/miles/.ssh/%h
    IdentitiesOnly yes
    StrictHostKeyChecking yes
 
Dernière édition par un modérateur:
Bambusa29 a dit:
J'ai rajouté une ligne entre temps, mais si cela fonctionne, cela ne venait pas de là :
Cliquez pour agrandir...
De quelle ligne parles-tu ?
(vu qu'on a pas mal discuté ^^ je ne sais plus de quelle partie on parle :ROFLMAO: )

Bambusa29 a dit:
Je vois que tu as mis des clés publiques dans ton fichier "config" coté client. Dans la ligne 'IdentityFile', il faut les clés privées (sans le .pub) !!
Cliquez pour agrandir...
Pourtant dans ton tuto, c'est bien le .pub que tu as mis :

[Tuto] SSH, mode console avec échange de clé : Une seule règle pour accéder à tous vos serveurs SSH

Bonjour, Petit Tuto rapide pour gérer simplement la configuration SSH coté client pour accéder en mode console à vos serveurs avec échanges de clés. Le but est d'avoir une seule règle pour accéder à tous vos serveurs SSH. 1) Préambule 2) Configuration optimale avec échange de clés 3)...
www.forum-nas.fr www.forum-nas.fr
1712925298996.png
L'erreur est-elle dans ce premier message du tuto ?

Si oui, serait-elle celle qui m'a fait utiliser la commande ssh-add pour ajouter ma clé privée (à je ne sais pas quel fichier) ?

Bambusa29 a dit:
Si je pense que cela est possible si tu met toutes les connexions via IP en priorité dans ton fichier "config" et ta section suivante a la fin :
Cliquez pour agrandir...
Ok, mais du coup, ça va vouloir dire écrire manuellement toutes les sections avec les IPs :ROFLMAO:
Va me falloir un script pour automatiser tout ça XD
(oui, j'aime les scripts ^^)
 
@Bambusa29
Je suis allé plus loin dans mes investigations :)
J'ai d'abord corrigé le fichier ../.ssh/config en enlevant le .pub pour avoir donc la clé privée.
Ensuite, avec la commande ssh-add -D, j'ai enlevé la clé stockée je-ne-sais-pas-où qui avait été ajoutée avec ssh-add , et blam, la connexion SSH fonctionne toujours :p
Je n'ai donc pas besoin d'avoir la clé privée ajoutée avec ssh-add, du moins tant que je laisse le fichier de la clé privée dans le dossier .ssh.

En poussant plus loin mes recherches, j'ai constaté que peut importe si je met ou pas cette clé privée avec ssh-add, la connexion ne fonctionne pas si je commente la ligne IdentityFile du fichier config du client.
 
  • J'aime
Réactions: Bambusa29
Bambusa29 a dit:
Si je pense que cela est possible si tu met toutes les connexions via IP en priorité dans ton fichier "config" et ta section suivante a la fin :
Cliquez pour agrandir...
Le temps que je mette des clés partout, et surtout le temps que je valide la procédure de A à Z, j'ai trouvé une technique pour continuer à me connecter aux autres serveurs via leur IP. Ajouter ceci au fichier de configuration :
Code: 
Host 192.168.2.*
    HostName %h
    Port 1234
    IdentitiesOnly no
    StrictHostKeyChecking no
 
  • J'aime
Réactions: Bambusa29
Je n'ai pas été assez clair dans mon tuto pour la gestion de la clé privée avec 'IdentityFile' (mode normal).
On peut mettre la clé publique a la place si seulement si nous utilisons un gestionnaire de mot de passe avec un agent ssh intégré :

Activation de l'agent SSH dans KeepassXC :

sshagent.png

Exemple pour accéder à mon serveur 'Gitea' : La clé est ajoutée a l'agent SSH quand la BD est déverouillée.

sshagent1.png

- IdentityFile : Indique le chemin de la clé privée. Ma clé devra donc se nommer 'alias.yannick.lan' (alias.yannick.lan.pub ici car je ne garde que la clé publique)

Remarque : J'utilise ici une subtilité de ssh-agent couplé avec mon coffre fort numérique pour ne garder que la clé publique localement. La clé privée est quant a elle dans mon coffre fort numérique et je l'ai supprimé localement après l'avoir créer.
Cliquez pour agrandir...
 
@Bambusa29
Un effet de bord non négligeable pour moi est que je ne peux plus accéder au serveur avec mes clients SFTP comme Forklift, ou CyberDuck.
Ça c'est un gros problème pour moi.
Sais-tu comment faire pour qu'ils fonctionnent ?
 
Bonjour @Bambusa29
J'ai une petite question :)
Pourrais-tu expliquer ce qu'apporte le principe d'avoir une clé différente par serveur ? Par rapport à une seule clé unique pour tous les serveurs ?
Car je vois partout (les autres tutos, les méthodes...) que tout le monde utilise une seule clé privée & publique sur le client pour tous les serveurs auquel il se connecte.

Sinon, j'ai réussi à faire en sorte que je puisse me connecter à la fois via le terminal iTerm2, et aussi avec Forklift avec le fichier de configuration client suivant qui me permet aussi de me connecter via l'adresse IP du serveur, et aussi tant que je n'ai pas généralisé les clés sur tous mes serveurs, de pouvoir me connecter aux autres via leur IP sans clés :
INI: 
# Bloc pour l'accès via IP, car profil créé depuis longtemps dans iTerm2 avec IP
Host 192.168.2.194
    HostName 192.168.2.194
    User root
    IdentityFile /Users/miles/.ssh/nuc1.miles.lan
    IdentitiesOnly yes
    StrictHostKeyChecking yes

# Bloc pour l'accès via alias court, transformé en ndd uniquement dispo sur le LAN
Host nuc1
    HostName %h.miles.lan
    User root
    IdentityFile /Users/miles/.ssh/%h
    IdentitiesOnly yes
    StrictHostKeyChecking yes

# Bloc commun à tout, pour éviter les répétitions
# Viendra dedans la partie avev IdentitiesOnly et StrictHostKeyChecking quand tout sera au point
Host *
    Port 1234
 
  • J'aime
Réactions: Bambusa29
MilesTEG a dit:
Bonjour @Bambusa29
J'ai une petite question :)
Pourrais-tu expliquer ce qu'apporte le principe d'avoir une clé différente par serveur ? Par rapport à une seule clé unique pour tous les serveurs ?
Car je vois partout (les autres tutos, les méthodes...) que tout le monde utilise une seule clé privée & publique sur le client pour tous les serveurs auquel il se connecte.
Cliquez pour agrandir...

Si on part du principe que toutes les clés privées sont stockées au même endroit; avoir plusieurs clés revient au même que d'en avoir une seul mais avoir plusieurs clés c'est :

- Avoir des PassPhrase différente pour chaque clé privée -> rajoute de la complexité pour casser toutes les clés,
- Quand on veux changer une clé privée -> on change la clé public d'un seul serveur et pas celles de tous les serveurs,
- Quand une politique de rotation régulière est mis en place pour une ou plusieurs machines, on ne change que les clés concernés et pas toutes les clés...
 
Dernière édition:
  • J'aime
Réactions: MilesTEG
Hello,
Personnellement j'ai 1 clé par serveur, et elles sont toutes stocké ensemble dans un coffre chiffré ( VeraCrypt ).

Le but d'avoir 1 clé différente par serveur, et principalement pour ne pas avoir a changer l'ensemble en cas de soucis.
 
  • J'aime
Réactions: MilesTEG
Merci pour vos explications :)

me faut trouver le moyen d'avoir la clé et la passphrase dans Bitwarden...
Ça me ferait suer de devoir utiliser KeepassXC juste pour ça :ROFLMAO:
 
EVO a dit:
Je suis sans passphrase dans mon cas, et j'utilise Tabby pour stocker dans un coffre la clé
Cliquez pour agrandir...
Le souci de Tabby, c'est que sur mac, il ne permet pas le déverrouillage du coffre par Touch-ID...
iTerm2 le fait, et je ne peux pas m'en passer. Devoir taper le mot de passe du coffre à chaque fois que je lance Tabby me saoule à un point...
Mais c'est son seul défaut !
Ha si, il faudrait que je refasse tous mes signets :ROFLMAO:
 
Vous devez vous connecter ou vous enregistrer pour répondre ici.
Haut Bas
Retour