Skip to content

Connection SSH

Modification du fichier de connexion SSH

Vous pouvez spécifier un utilisateur dans votre fichier ssh.config en ajoutant le mot-clé "Utilisateur" suivi du nom d'utilisateur. Voici un exemple: 

Host example.com
  User username
  Port 22
  IdentityFile .ssh/privatekey.pem

Connexion via le domain

ssh domain\utilisateur@nomduserveur.domain.xx

Linux connexion avec sa clé publique

Pré-configuration

avoir un client ssh et créer la clée :

ssh-keygen

Se connecter si le mot de passe est activé

ssh-copy-id 192.168.1.210 -p 45293
ssh 192.168.1.210 -p 45293

on peut maintenant se connecter a 192.168.1.210 sans mot de passse

Se connecter si le mot de passe est désactiver

Dans se scénario nous allons nous connecter sur un serveur qui accepte uniquement l'authtification par clé publique.

Se connecter avec l'utilisateur par default et crée l'utilisateur avec lesque ont souhaite se connecter :

adduser user
usermod -aG sudo
tee -a /home/user/.ssh/authorized_keys  >/dev/null <<'EOF'
ssh-rsa mettrelaclépublicici
EOF

On va ensuite pouvoir se connecter avec le bon compte et supprimer le compte par default

Résolution du problème de persmission

Si l'erreur suivante se présente : Permissions are too open pour le dossier .ssh alors il faut utiliser la commande suivante : 

sudo chmod 700 .ssh
sudo chmod 600 .ssh/id_rsa.pub
sudo chmod 600 .ssh/id_rsa
sudo chmod 600 .ssh/authorized_keys
Source : Howtogekk

Windows connexion avec sa clé public

Instalation du client OpenSSH

Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0

Pré-configuration

Dans powershell :

ssh-keygen
gsudo choco install gsudo ssh-copy-id
ssh-copy-id 192.168.1.201

Problème de permission

Si des problème de permission surviennent bien vérifier :

  • Qu'il n'y a pas d'érithage sur le dossier
  • Qui est le propriétaire

capture_d'écran_2024-09-24_120525.png

Voici a quoi doit ressemblé les perms

Utilisation avancé

Serveur de rebond SSH

Utilisation de base

ssh -J utilisateur@serveur-de-rebond utilisateur@serveur-cible
ou avec l'option -i pour spécifier la clé SSH :

ssh -i /chemin/vers/votre/clé_privée -J utilisateur@serveur-de-rebond utilisateur@serveur-cible
ou en utilisant le fichier de configuration SSH (~/.ssh/config) :

Host serveur-cible
  HostName serveur-cible
  User utilisateur
  ProxyJump utilisateur@serveur-de-rebond
  IdentityFile /chemin/vers/votre/clé_privée

Puis simplement : 

ssh serveur-cible

On peut aussi forward la clée ssh via cette commande :

ssh -A -i /chemin/vers/votre/clé_privée -J utilisateur@serveur-de-rebond utilisateur@serveur-cible

Utilisation plus avancé

On peut utilisé des expression régulière pour avoir moin de gestion de conf à faire :

Host *.domaine.fr !dcadm-inf-ssh1.domaine.fr
    ProxyJump username@dcadm-inf-ssh1.domaine.fr
    User username
    ServerAliveInterval 60
    ForwardAgent yes

Warning

pour évité une boucle on rajoute le ProxyJump après le "!" de Host

redirection de port SSH

Redirige un port local de votre machine vers un port sur une machine distante :

ssh -L 8080:localhost:80 utilisateur@serveurdistant
Dans cet exemple, tout le trafic envoyé au port 8080 sur votre machine locale sera redirigé vers le port 80 sur serveurdistant

Redirige un port sur le serveur SSH distant vers un port sur votre machine locale

ssh -R 8080:localhost:80 utilisateur@serveurdistant
Ici, tout le trafic envoyé au port 8080 sur serveurdistant sera redirigé vers le port 80 sur votre machine locale.

Proxy SOCKS sur votre machine locale, permettant d'accéder à plusieurs services sur le serveur distant

ssh -D 8080 utilisateur@serveurdistant
Vous pouvez ensuite configurer votre navigateur ou une autre application pour utiliser un proxy SOCKS sur localhost:8080, ce qui permet d'accéder à Internet à travers serveurdistant.

Vérifier l'agent forwarding (Transfer de clée privé)

Par defaut ssh va aussi transférer la clée privé (Je suppose que c'est sécurisé ?) on peut facilement vérifier avec la commande : 

ssh-add -l
# 256 SHA256:xxxxxxxx user 07/03/25 (ED25519)
# 2048 SHA256:xxxxxxx /home/user/.ssh/id_rsa (RSA)
# 256 SHA256:xxxxxxxx user.name@domaine.com (ED25519)
On pourrait aussi supprimer le forward de sont agent 

eval $(ssh-agent)
# Agent pid 628332
ssh-add -l
# The agent has no identities.

On peut aussi le rajouter à sont fichier de configuration SSH 

Host *.domain.com
    ProxyJump username@bastion.domaine.com
    User username
    ConnectTimeout 10
    IdentityFile ~/.ssh/id_ed25519
    ServerAliveInterval 60
    ForwardAgent yes

Vérifier la parire de clée

Une clé RSA

ssh-keygen -y -f ~/.ssh/id_rsa | diff - ~/.ssh/id_rsa.pub

Une clé Ed25519

ssh-keygen -y -f ~/.ssh/id_ed25519 | diff - ~/.ssh/id_ed25519.pub

Multiplexage SSH (ControlMaster)

Le multiplexage permet de réutiliser une connexion SSH TCP déjà ouverte pour toutes les connexions suivantes vers le même hôte, rendant l'ouverture de nouvelles sessions ou l'exécution de scripts Ansible quasi-instantanée.

Configuration (~/.ssh/config)

Host *
    ControlMaster auto
    ControlPath ~/.ssh/sockets/%r@%h:%p
    ControlPersist 4h

Dépannage et gestion des sockets orphelines

Si le réseau ou le tunnel VPN intermédiaire (ex: WireGuard) coupe brutalement, la socket maître dans ~/.ssh/sockets/ peut rester active alors que la session TCP sous-jacente est rompue. Toute nouvelle connexion SSH va s'accrocher à cette socket fantôme et se figer jusqu'au timeout.

Pour vérifier l'état ou forcer la fermeture d'une socket multiplexée :

# Vérifier si la socket maître répond
ssh -O check utilisateur@serveur

# Fermer proprement la connexion maître
ssh -O exit utilisateur@serveur

# En cas de blocage persistant, supprimer manuellement la socket
rm -f ~/.ssh/sockets/utilisateur@serveur:22

Dépannage et Erreurs Fréquentes

Erreur Host key verification failed

Cette erreur survient lorsque la clé publique d'hôte (Host Key ED25519 ou RSA) enregistrée dans ~/.ssh/known_hosts ne correspond plus à celle renvoyée par le serveur distant (ex: réinstallation du système, régénération de clés, changement d'IP).

Solutions :

  1. Supprimer l'ancienne empreinte enregistrée pour cet hôte : 

    ssh-keygen -R <nom_d_hote_ou_ip>

  2. Accepter automatiquement les nouvelles clés sans désactiver la sécurité (recommandé pour l'automatisation sans passer par StrictHostKeyChecking=no) : 

    ssh -o StrictHostKeyChecking=accept-new utilisateur@serveur

Piège du timeout <n> ssh <serveur>

Lancer timeout 5 ssh serveur sans spécifier de commande distante tente d'allouer un terminal interactif distant (TTY) et attend des saisies utilisateur. Au bout des 5 secondes de délai d'attente, timeout envoie un signal SIGTERM au processus SSH, ce qui termine la session et rend la main immédiatement sur le prompt local sans afficher d'erreur explicite.

Bonne pratique pour tester la connectivité non-interactive :

# Tester avec une commande distante et en mode Batch (sans invite de mot de passe)
timeout 5 ssh -o BatchMode=yes -o ConnectTimeout=5 utilisateur@serveur 'echo OK'

Diagnostic d'une chaîne ProxyJump avec VPN

Lorsqu'une connexion vers un serveur interne échoue via un bastion (ProxyJump), il est essentiel d'isoler chaque maillon de la chaîne :

  1. Tester la résolution DNS du bastion : 
    getent hosts bastion.albt.org
  2. Tester l'accessibilité réseau du port SSH (TCP 22) : 
    nc -zvw3 bastion.albt.org 22
  3. Tester la connexion SSH au bastion directement : 
    ssh -o BatchMode=yes bastion.albt.org 'echo BASTION_OK'
  4. Depuis le bastion, tester le réseau VPN vers la cible : 
    ssh bastion.albt.org 'ping -c 2 10.2.0.1'
ssh bastion.albt.org 'nc -zvw3 10.2.0.1 22'
  5. Tester la chaîne complète de bout en bout en mode très verbeux : 
    ssh -vvv -o ConnectTimeout=5 medusa.albt.org