Aller au contenu

Client SSH

De Marmits Wiki

Le fichier ~/.ssh/config dans Debian (et plus généralement sous Linux/Unix) est un fichier de configuration pour le client SSH. Il permet de définir des paramètres personnalisés pour vos connexions SSH, afin d’éviter de retaper des options à chaque commande.

À quoi sert-il ?

  • Simplifier les connexions SSH en définissant des alias.
  • Spécifier des options par hôte (serveur) : utilisateur, port, clé privée, etc.
  • Gérer plusieurs clés SSH ou serveurs sans conflit.
  • Activer des fonctionnalités comme le tunnel, le proxy, ou le forwarding.


Exemple typique de contenu :

Host serveur1
    HostName 192.168.1.10
    User john
    Port 2222
    IdentityFile ~/.ssh/id_rsa

Host github
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_ed25519

Avec ce fichier : - Pour se connecter à serveur1, il suffit de taper : bash ssh serveur1 (au lieu de ssh john@192.168.1.10 -p 2222 -i ~/.ssh/id_rsa)

  • Pour GitHub, Git utilisera automatiquement la bonne clé.

Voici ce que tu cherches :


✅ Options les plus utiles dans ~/.ssh/config

Chaque option peut être définie globalement ou par bloc Host.

Option Description
Host Alias pour le serveur (ex. serveur1).
HostName Nom DNS ou IP du serveur.
User Nom d’utilisateur pour la connexion SSH.
Port Port SSH (par défaut : 22).
IdentityFile Chemin vers la clé privée à utiliser.
ProxyJump Permet de passer par un serveur intermédiaire (jump host).
ForwardAgent Active le transfert d’agent SSH (yes/no).
ServerAliveInterval Intervalle (en secondes) pour envoyer un keep-alive et éviter la déconnexion.
ServerAliveCountMax Nombre de keep-alive avant coupure.
StrictHostKeyChecking yes = refuse les hôtes inconnus, no = accepte sans confirmation (⚠️ peu sécurisé).
UserKnownHostsFile Fichier où sont stockées les empreintes des hôtes (par défaut ~/.ssh/known_hosts).
LogLevel Niveau de verbosité (QUIET, INFO, VERBOSE, DEBUG).


Exemple complet

Host serveur1
    HostName 192.168.1.10
    User john
    Port 2222
    IdentityFile ~/.ssh/id_rsa
    ServerAliveInterval 60
    ServerAliveCountMax 3

Host github
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_ed25519
    StrictHostKeyChecking yes

✅ Guide pour sécuriser et tester ~/.ssh/config

1. Droits d’accès

  • Le fichier doit être lisible uniquement par l’utilisateur :

    chmod 600 ~/.ssh/config

  • Le dossier ~/.ssh doit avoir :

    chmod 700 ~/.ssh

2. Vérifier la syntaxe

  • SSH ne propose pas de commande dédiée, mais tu peux tester avec :

    ssh -G alias

    Cela affiche la configuration complète appliquée pour alias.

3. Tester la connexion

  • Simplement :

    ssh -v alias

    (-v = verbose, pour déboguer)

4. Bonnes pratiques

  • Ne jamais mettre StrictHostKeyChecking no en production.

  • Utiliser des clés fortes (ed25519 ou RSA ≥ 4096 bits).

  • Éviter les mots de passe → préférer les clés SSH.

  • Limiter les permissions sur les clés privées :

    chmod 600 ~/.ssh/id_*


Voici un modèle ~/.ssh/config durci (sécurité renforcée) avec commentaires ligne par ligne, puis un guide pas à pas pour sécuriser et tester.
Tout est compatible Debian/OpenSSH récents (Bookworm et +).


🔐 Modèle ~/.ssh/config – sécurité renforcée + commentaires

Place ce fichier dans ~/.ssh/config et assure-toi des permissions indiquées plus bas. 

# =========================
# Fichier : ~/.ssh/config
# Objectif : Sécurité renforcée + lisibilité
# =========================

# ---- Valeurs par défaut applicables à tous les hôtes ----
Host *
    # N'utiliser que l'authentification par clé (pas de mot de passe)
    PubkeyAuthentication yes
    PreferredAuthentications publickey
    PasswordAuthentication no
    KbdInteractiveAuthentication no
    GSSAPIAuthentication no             # sauf si tu utilises Kerberos/AD

    # N'offrir que les clés explicitement listées (évite l'énumération de clés)
    IdentitiesOnly yes

    # Ne JAMAIS transférer l'agent par défaut (réduit le risque de vol d'identité)
    ForwardAgent no
    ForwardX11 no

    # Integrity & protection contre les attaques de type MITM
    StrictHostKeyChecking yes            # refuser les hôtes inconnus
    HashKnownHosts yes                   # hash les noms dans known_hosts
    UserKnownHostsFile ~/.ssh/known_hosts
    UpdateHostKeys ask                   # facilite la rotation des clés hôte, mais te demande

    # Si ton DNS est signé DNSSEC + SSHFP publié, tu peux activer :
    # VerifyHostKeyDNS yes

    # Robustesse (évite les déconnexions silencieuses)
    ServerAliveInterval 60
    ServerAliveCountMax 3
    TCPKeepAlive yes

    # Multiplexage (plus rapide, avec prudence)
    ControlMaster auto
    ControlPersist 10m
    ControlPath ~/.ssh/ctl/%C           # nécessite le dossier ~/.ssh/ctl (700)

    # Limiter la durée/taille avant re-clé (bon hygiène crypto)
    RekeyLimit 1G 1h

    # Journalisation standard (utilise -vvv pour debug ponctuel)
    LogLevel INFO

    # N'ajoute pas automatiquement des clés à l'agent (évite les surprises)
    AddKeysToAgent ask

    # Nettoyer tout port forwarding hérité d'une session multiplexée
    ClearAllForwardings yes


# ---- Exemple : bastion / jump host ----
Host bastion
    HostName bastion.exemple.org
    User john
    Port 22
    IdentityFile ~/.ssh/id_ed25519_bastion

    # Bastion : on peut être plus strict (aucun port forwarding)
    ForwardAgent no
    LocalForward
    RemoteForward

# ---- Exemple : serveurs internes accessibles via le bastion ----
Host intra-*.exemple.org
    User admin
    Port 22
    IdentityFile ~/.ssh/id_ed25519_intra
    ProxyJump bastion

    # Optionnel : séparer les empreintes des hôtes internes
    UserKnownHostsFile ~/.ssh/known_hosts_intra

# ---- Exemple : GitHub ----
Host github
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_ed25519_github
    IdentitiesOnly yes
    # Astuce : pré-semer l’empreinte GitHub dans known_hosts (voir guide)
    # et tester avec : ssh -T git@github.com

# ---- Exemple : serveur spécifique avec port non standard ----
Host prod-db
    HostName 203.0.113.42
    User postgres
    Port 2222
    IdentityFile ~/.ssh/id_ed25519_prod

💡 Pourquoi on ne force pas les suites cryptographiques (Ciphers, MACs, KexAlgorithms) ?

Les versions modernes d’OpenSSH choisissent automatiquement des algorithmes sûrs et à jour. Figer ces listes peut casser des connexions ou te priver d’améliorations de sécurité à l’avenir. Ne les borne que si tu as une politique formelle ou un audit qui l’exige.

🛡️ Guide pas-à-pas : sécuriser & tester

0) Préparer l’environnement et les droits

mkdir -p ~/.ssh/ctl
chmod 700 ~/.ssh ~/.ssh/ctl
touch ~/.ssh/config ~/.ssh/known_hosts
chmod 600 ~/.ssh/config ~/.ssh/known_hosts

1) Générer des clés modernes et protégées par passphrase

# Clé générale
ssh-keygen -t ed25519 -a 100 -f ~/.ssh/id_ed25519 -C "john@$(hostname -f)"

# Clés dédiées (meilleure hygiène : une clé par usage)
ssh-keygen -t ed25519 -a 100 -f ~/.ssh/id_ed25519_bastion -C "bastion"
ssh-keygen -t ed25519 -a 100 -f ~/.ssh/id_ed25519_intra -C "intra"
ssh-keygen -t ed25519 -a 100 -f ~/.ssh/id_ed25519_github -C "github"
chmod 600 ~/.ssh/id_ed25519*

-a 100 renforce la dérivation de la passphrase (plus résistant au brute-force).

2) Pinner les hôtes (pré-semer known_hosts) avant la 1re connexion

  1. Obtiens les empreintes publiques par un canal de confiance (fiche d’exploitation, document interne, site officiel du fournisseur, ou administrateur).

  2. Ajoute-les sans te connecter :

    # Exemple pour un hôte avec clé ed25519
ssh-keyscan -t ed25519 bastion.exemple.org | tee -a ~/.ssh/known_hosts
ssh-keyscan -t ed25519 github.com           | tee -a ~/.ssh/known_hosts

  3. Vérifie les empreintes localement :

    ssh-keygen -lf ~/.ssh/known_hosts | grep -E 'bastion\.exemple\.org|github\.com'

    Compare avec la source officielle avant d’autoriser la connexion.

Si tu ne peux pas pré-semer, laisse StrictHostKeyChecking yes et saisis-toi de la première empreinte uniquement après vérification hors bande.

3) Charger une clé dans l’agent à la demande

# Démarrer l'agent si besoin
eval "$(ssh-agent -s)"

# Ajouter la clé avec demande de passphrase
ssh-add ~/.ssh/id_ed25519_bastion
# Avec confirmation à chaque utilisation (plus sûr) :
ssh-add -c ~/.ssh/id_ed25519_bastion

Comme ForwardAgent no, l’agent n’est pas exposé au serveur distant.

4) Tester la configuration et diagnostiquer

# Voir la config effective (utile pour déboguer)
ssh -G bastion | less

# Connexion verbeuse
ssh -vvv bastion

# Test GitHub sans exécuter de commande (échange SSH uniquement)
ssh -T git@github.com

5) Bonnes pratiques complémentaires

  • Une clé privée par contexte sensible (prod ≠ dev ≠ perso).
  • Rotation : change périodiquement les clés (ssh-keygen -p pour changer la passphrase).
  • Sauvegarde chiffrée des clés privées (jamais en clair).
  • Isolation des empreintes : utilise un UserKnownHostsFile séparé pour les environnements (ex: known_hosts_intra, known_hosts_prod).
  • Multiplexage : purge le dossier ~/.ssh/ctl/ si tu soupçonnes une session bloquée.
  • Éviter StrictHostKeyChecking no : préfère yes. Si tu dois assouplir ponctuellement : ssh -o StrictHostKeyChecking=accept-new host une seule fois après vérification.


🧪 Check-list rapide

  • ☐ ~/.ssh en 700, fichiers en 600
  • ☐ Clés ed25519 avec passphrase
  • ☐ StrictHostKeyChecking yes, empreintes pré-semées et vérifiées
  • ☐ IdentitiesOnly yes, ForwardAgent no
  • ☐ ProxyJump pour segmenter l’accès (bastion)
  • ☐ Test avec ssh -G, ssh -vvv et ssh -T git@github.com


Récupérée de "https://marmits.com/w/index.php?title=Client_SSH&oldid=3511"