SSH Access : Le Guide Technique Complet pour la Gestion Sécurisée de Serveurs à Distance

SSH (Secure Shell) est un protocole réseau cryptographique qui établit un tunnel chiffré entre deux hôtes en réseau, permettant l’exécution de commandes authentifiées, le transfert de fichiers et la redirection de ports sur des réseaux non fiables. Il fonctionne par défaut sur le port TCP 22 et remplace les prédécesseurs en texte clair — Telnet, rsh et FTP — par un protocole qui assure la confidentialité, l’intégrité et l’authentification mutuelle en une seule négociation.

Pour tout administrateur gérant un VPS ou un serveur dédié, SSH n’est pas une infrastructure optionnelle — c’est le plan de contrôle principal. Chaque décision de configuration que vous prenez concernant SSH affecte directement la surface d’attaque de votre serveur, la fiabilité opérationnelle et la conformité.

Comment fonctionne SSH : l’architecture du protocole

Comprendre SSH au niveau du protocole est ce qui distingue les administrateurs qui le configurent correctement de ceux qui laissent des failles exploitables.

Le modèle à trois couches

SSH est défini par les RFC 4251–4254 et fonctionne sur trois sous-couches distinctes empilées au-dessus de TCP :

• Protocole de couche transport SSH — gère l’authentification du serveur, l’échange de clés, la négociation du chiffrement et la configuration du MAC (code d’authentification de message). C’est ici que se produit la négociation cryptographique.
• Protocole d’authentification utilisateur SSH — s’exécute au-dessus de la couche transport et gère l’authentification client-serveur en utilisant des méthodes telles que publickey, password, keyboard-interactive ou gssapi-with-mic.
• Protocole de connexion SSH — multiplexe le tunnel chiffré en canaux logiques, chacun transportant une session shell, un sous-système SFTP, un port redirigé ou une connexion d’agent.

La négociation en détail

Lorsque vous exécutez ssh user@host, la séquence suivante s’exécute avant que vous ne voyiez une invite :

1. La connexion TCP est établie vers le serveur sur le port configuré.
2. Échange de version — le client et le serveur échangent des chaînes de version de protocole (SSH-2.0-OpenSSH_9.x).
3. Négociation d’algorithme (SSH_MSG_KEXINIT) — les deux parties annoncent les algorithmes d’échange de clés pris en charge, les types de clés d’hôte, les chiffrements, les MAC et les méthodes de compression. La première option mutuellement prise en charge dans chaque liste l’emporte.
4. Échange de clés (KEX) — généralement Diffie-Hellman ou Elliptic Curve Diffie-Hellman (ECDH). Les deux parties dérivent un secret partagé sans le transmettre. Cela produit des clés de session.
5. Vérification de la clé d’hôte du serveur — le serveur signe une valeur avec sa clé d’hôte privée. Le client vérifie cette signature par rapport à son fichier ~/.ssh/known_hosts. Une incompatibilité déclenche un avertissement et bloque la connexion par défaut.
6. Chiffrement activé — tout le trafic ultérieur est chiffré et protégé en intégrité à l’aide du chiffrement négocié (par exemple, chacha20-poly1305) et du MAC.
7. Authentification utilisateur — le client tente de s’authentifier en utilisant la méthode négociée. Avec l’authentification publickey, le client signe un défi avec sa clé privée ; le serveur vérifie en utilisant la clé publique stockée.
8. Ouverture de canal — un shell, un sous-système SFTP ou un canal d’exécution est ouvert et la session commence.

L’ensemble de ce processus se termine généralement en moins de 100 millisecondes sur un réseau local.

Cryptographie symétrique et asymétrique dans SSH

Une idée reçue courante est que SSH « utilise le chiffrement à clé publique » pour tout le trafic. Ce n’est pas le cas. Les rôles sont distincts :

SSH vs. protocoles d’accès à distance hérités

Génération de paires de clés SSH

Les paires de clés SSH sont le fondement d’un accès serveur sécurisé et évolutif. L’authentification par mot de passe est vulnérable aux attaques par force brute et au credential stuffing ; l’authentification par clé ne l’est pas.

Choisir le bon algorithme de clé

Ed25519 est la meilleure pratique actuelle. Il utilise la cryptographie à courbe elliptique Curve25519, produit des clés compactes de 256 bits, est plus rapide que RSA à des niveaux de sécurité équivalents, et est pris en charge par OpenSSH 6.5+ (publié en 2014).

ssh-keygen -t ed25519 -C "admin@yourhost.example.com"

Utilisez RSA uniquement lorsque vous avez besoin de compatibilité avec des systèmes hérités qui ne prennent pas en charge Ed25519 :

ssh-keygen -t rsa -b 4096 -C "admin@yourhost.example.com"

N’utilisez pas DSA (limité à 1024 bits, compromis) ni ECDSA avec les courbes NIST (préoccupations concernant la provenance des paramètres des courbes NIST). Ed25519 est le choix incontestable pour les nouveaux déploiements.

Guide de génération de clés

ssh-keygen -t ed25519 -C "ops-team-key-2025"

Il vous sera demandé :

• Emplacement du fichier — la valeur par défaut est ~/.ssh/id_ed25519. Acceptez la valeur par défaut ou spécifiez un chemin personnalisé pour les environnements multi-clés.
• Phrase secrète — définissez-en toujours une. Une phrase secrète chiffre la clé privée au repos en utilisant AES-256-CBC (ou bcrypt avec les versions plus récentes d’OpenSSH). Si votre fichier de clé privée est volé, la phrase secrète est la dernière ligne de défense.

Cela produit deux fichiers :

~/.ssh/id_ed25519 — la clé privée. Ne la partagez jamais. Les permissions doivent être 600.
~/.ssh/id_ed25519.pub — la clé publique. C’est ce que vous distribuez aux serveurs.

Gestion de plusieurs clés avec ~/.ssh/config
Lors de la gestion de plusieurs serveurs ou comptes, utilisez un fichier de configuration SSH pour éviter de spécifier des indicateurs à chaque connexion :
# ~/.ssh/config

Host prod-web
    HostName 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/id_ed25519_prod
    Port 2222

Host staging
    HostName 203.0.113.20
    User ubuntu
    IdentityFile ~/.ssh/id_ed25519_staging
Avec cela en place, ssh prod-web se développe automatiquement en paramètres de connexion complets.
Déploiement de votre clé publique sur un serveur
Méthode 1 : ssh-copy-id (Recommandée pour la configuration initiale)
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@your_server_ip
Cela ajoute la clé publique à ~/.ssh/authorized_keys sur l’hôte distant et définit automatiquement les permissions correctes.
Méthode 2 : Déploiement manuel (lorsque ssh-copy-id n’est pas disponible)
cat ~/.ssh/id_ed25519.pub | ssh user@your_server_ip 
  "mkdir -p ~/.ssh && chmod 700 ~/.ssh && 
   cat >> ~/.ssh/authorized_keys && 
   chmod 600 ~/.ssh/authorized_keys"
Méthode 3 : Console ou API du fournisseur cloud
La plupart des fournisseurs cloud et des panneaux de contrôle d’hébergement vous permettent d’injecter des clés publiques lors du provisionnement des instances. C’est la bonne approche pour une infrastructure automatisée — la clé est présente avant le démarrage de l’instance, éliminant le problème de l’œuf et de la poule consistant à avoir besoin de SSH pour déployer des clés SSH.
Le format du fichier authorized_keys
Chaque ligne dans ~/.ssh/authorized_keys est une clé publique, optionnellement préfixée par des options :
restrict,command="/usr/local/bin/backup.sh" ssh-ed25519 AAAA... backup-key
from="192.168.1.0/24" ssh-ed25519 AAAA... ops-key
L’option restrict désactive la redirection de ports, la redirection d’agent et l’allocation PTY pour cette clé — utile pour les clés de déploiement ou les comptes d’automatisation de sauvegarde qui ne devraient pas avoir accès à un shell interactif.
Durcissement du serveur SSH : /etc/ssh/sshd_config
Une installation OpenSSH par défaut est fonctionnelle mais pas durcie. La configuration suivante représente une base de niveau production. Appliquez les modifications à /etc/ssh/sshd_config, puis validez et rechargez :
sshd -t && systemctl reload sshd
Exécutez toujours sshd -t avant de recharger — une erreur de syntaxe dans sshd_config ne fera pas planter le démon en cours d’exécution mais l’empêchera de redémarrer après un redémarrage du système, vous bloquant l’accès.
Bloc de durcissement sshd_config recommandé
# /etc/ssh/sshd_config - Production hardening baseline

Port 2222
AddressFamily inet
ListenAddress 0.0.0.0

# Host keys - prefer Ed25519
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key

# Cryptographic hardening
KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com

# Authentication
PermitRootLogin no
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
UsePAM yes

# Session hardening
LoginGraceTime 30
MaxAuthTries 3
MaxSessions 5
ClientAliveInterval 300
ClientAliveCountMax 2
TCPKeepAlive no

# Disable unused features
X11Forwarding no
AllowAgentForwarding no
AllowTcpForwarding no
PermitTunnel no
GatewayPorts no

# Restrict access
AllowUsers deploy ops-user
Banner /etc/ssh/banner.txt
Décisions critiques de durcissement expliquées
PermitRootLogin no — La connexion root via SSH est une cible de haute valeur. Utilisez un utilisateur ordinaire et escaladez avec sudo. Si vous avez absolument besoin d’un accès équivalent à root via une clé spécifique (par exemple, pour l’automatisation), utilisez PermitRootLogin prohibit-password pour autoriser la connexion root par clé uniquement tout en bloquant les tentatives par mot de passe.
AllowTcpForwarding no — Si votre serveur n’est pas un bastion ou un hôte de rebond, désactivez la redirection TCP. Un attaquant disposant d’une session SSH valide pourrait autrement utiliser votre serveur comme proxy pour atteindre les ressources du réseau interne.
TCPKeepAlive no avec ClientAliveInterval — TCPKeepAlive fonctionne au niveau de la couche TCP et est visible par les intermédiaires réseau. ClientAliveInterval envoie des messages keepalive via le canal SSH chiffré, ce qui est à la fois plus fiable et plus privé.
LoginGraceTime 30 — Réduit la fenêtre pendant laquelle une connexion non authentifiée occupe un slot serveur. La valeur par défaut de 120 secondes est excessive.
AllowUsers — Autorisez uniquement les comptes qui ont légitimement besoin d’un accès SSH. C’est une barrière stricte qui s’applique avant toute tentative d’authentification.
Modification du port SSH par défaut
Déplacer SSH hors du port 22 n’améliore pas la sécurité contre un attaquant ciblé — tout scan de ports le trouvera. Ce que cela fait, c’est éliminer l’énorme volume de bots automatisés et opportunistes de force brute qui s’attaquent exclusivement au port 22. Cela réduit significativement le bruit des journaux et la charge du serveur.
# In /etc/ssh/sshd_config
Port 2222
Avant de recharger, ouvrez le nouveau port dans votre pare-feu :
# UFW
ufw allow 2222/tcp
ufw delete allow 22/tcp

# firewalld
firewall-cmd --permanent --add-port=2222/tcp
firewall-cmd --permanent --remove-service=ssh
firewall-cmd --reload

# iptables
iptables -A INPUT -p tcp --dport 2222 -j ACCEPT
iptables -D INPUT -p tcp --dport 22 -j ACCEPT
Si votre serveur exécute SELinux, vous devez également mettre à jour le contexte de port SELinux :
semanage port -a -t ssh_port_t -p tcp 2222
Connexion à un serveur
Connexion de base
ssh user@your_server_ip
Connexion à un port non par défaut
ssh -p 2222 user@your_server_ip
Connexion avec une clé spécifique
ssh -i ~/.ssh/id_ed25519_prod user@your_server_ip
Mode verbeux pour le débogage
ssh -vvv user@your_server_ip
L’indicateur -vvv affiche chaque étape de la négociation, de la tentative d’authentification et de la négociation de canal. C’est le premier outil à utiliser lorsqu’une connexion échoue de manière inattendue.
Transferts de fichiers sécurisés via SSH
SCP (Secure Copy Protocol)
SCP est un outil de copie de fichiers simple et non interactif. Il est rapide et largement disponible mais n’a pas de capacité de reprise et une gestion des erreurs limitée.
Copier un fichier local vers un serveur distant :
scp -P 2222 /local/path/file.tar.gz user@your_server_ip:/remote/path/
Copier un fichier distant en local :
scp -P 2222 user@your_server_ip:/remote/path/file.tar.gz /local/path/
Copie récursive de répertoire :
scp -rp -P 2222 /local/directory/ user@your_server_ip:/remote/directory/
Remarque : Le projet OpenSSH a déprécié le protocole SCP hérité dans OpenSSH 9.0. Le scp moderne utilise désormais le protocole SFTP sous le capot par défaut. L’interface de commande reste la même, mais le transport sous-jacent est plus robuste.
SFTP (SSH File Transfer Protocol)
SFTP est un sous-système de transfert de fichiers complet avec liste de répertoires, gestion des permissions et support de reprise. C’est le bon choix pour la gestion interactive de fichiers.
sftp -P 2222 user@your_server_ip
Commandes SFTP courantes dans la session interactive :
sftp> ls -la                          # List remote directory
sftp> lls                             # List local directory
sftp> put localfile.txt /remote/path/ # Upload file
sftp> get /remote/file.txt ./         # Download file
sftp> mput *.log /remote/logs/        # Upload multiple files
sftp> mkdir /remote/newdir            # Create remote directory
sftp> chmod 640 /remote/file.txt      # Change remote permissions
sftp> bye                             # Exit
rsync via SSH (recommandation pour la production)
Pour la synchronisation de répertoires, les sauvegardes incrémentielles ou les grands ensembles de données, rsync via SSH est significativement plus efficace que SCP ou SFTP. Il ne transfère que les blocs modifiés, pas les fichiers entiers.
rsync -avz --progress -e "ssh -p 2222 -i ~/.ssh/id_ed25519" 
  /local/data/ user@your_server_ip:/remote/data/
L’indicateur -z active la compression en transit. Pour les données déjà compressées (archives, images), omettez-le — la compression de données déjà compressées gaspille du CPU sans réduire la taille du transfert.
Redirection de ports SSH et tunneling
La redirection de ports est l’une des capacités les plus puissantes et sous-utilisées de SSH. Elle vous permet d’accéder de manière sécurisée à des services qui ne sont pas directement exposés à Internet.
Redirection de port locale
Redirigez un port local vers un service distant. Exemple : accéder à une instance MySQL distante (port 3306) liée à localhost sur le serveur :
ssh -L 3307:127.0.0.1:3306 user@your_server_ip -N
Maintenant mysql -h 127.0.0.1 -P 3307 sur votre machine locale se connecte via le tunnel chiffré au MySQL distant.
Redirection de port distante
Exposez un service local au serveur distant. Utile pour tester des webhooks ou partager un serveur de développement local :
ssh -R 8080:127.0.0.1:3000 user@your_server_ip -N
Redirection de port dynamique (proxy SOCKS)
Transformez la connexion SSH en proxy SOCKS5, acheminant le trafic TCP arbitraire via le serveur :
ssh -D 1080 user@your_server_ip -N
Configurez votre navigateur ou application pour utiliser SOCKS5 127.0.0.1:1080.
Agent SSH et transfert d’agent
ssh-agent conserve les clés privées déchiffrées en mémoire afin que vous n’ayez pas à ressaisir votre phrase secrète à chaque connexion.
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519
Le transfert d’agent (ssh -A) permet à un serveur distant d’utiliser votre agent local pour s’authentifier auprès d’un troisième serveur. Cela est utile pour les architectures de bastion mais comporte des risques : un utilisateur root sur le serveur intermédiaire peut utiliser votre socket d’agent transféré. Préférez plutôt ProxyJump :
ssh -J bastion.example.com user@internal-server.example.com
ProxyJump achemine la connexion TCP via le bastion sans lui exposer votre agent.
Résolution des problèmes SSH courants
Connexion refusée (ssh: connect to host ... port 22: Connection refused)
Diagnostic systématique :

Vérifiez que le démon SSH est en cours d’exécution : systemctl status sshd

• Confirmez le port d’écoute : ss -tlnp | grep sshd
• Vérifiez les règles de pare-feu : ufw status ou iptables -L -n | grep 22
• Vérifiez que le serveur est accessible au niveau réseau : ping your_server_ip
• Si vous utilisez un fournisseur cloud, vérifiez les règles de groupe de sécurité ou les ACL réseau dans la console du fournisseur.

Permission refusée (publickey)

C’est l’erreur SSH la plus courante. Suivez cette liste de vérification :

# On the server, check authorized_keys permissions
ls -la ~/.ssh/
stat ~/.ssh/authorized_keys

# Fix permissions if wrong
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R $USER:$USER ~/.ssh

# Verify the public key is actually present
cat ~/.ssh/authorized_keys

# Check sshd logs for the specific rejection reason
journalctl -u sshd -n 50 --no-pager
# or
tail -50 /var/log/auth.log

Causes courantes au-delà des permissions :

• Le fichier authorized_keys contient la mauvaise clé (par exemple, vous avez copié la clé privée au lieu du fichier .pub).

StrictModes yes dans sshd_config (la valeur par défaut) rejette les connexions si les permissions du répertoire personnel sont trop ouvertes — chmod 755 ~ est le maximum autorisé.
AllowUsers ou AllowGroups dans sshd_config exclut l’utilisateur qui se connecte.
SELinux bloque l’accès à ~/.ssh/ — vérifiez ausearch -m avc -ts recent.

Délai d’expiration de la connexion SSH
# In /etc/ssh/sshd_config (server side)
ClientAliveInterval 60
ClientAliveCountMax 3

# In ~/.ssh/config (client side)
Host *
    ServerAliveInterval 60
    ServerAliveCountMax 3
ClientAliveInterval envoie un paquet nul via le canal SSH chiffré toutes les 60 secondes. Après ClientAliveCountMax réponses manquées consécutives, le serveur termine la connexion. Cela empêche l’accumulation de sessions fantômes.
Échec de la vérification de la clé d’hôte
WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!
Cet avertissement signifie que la clé d’hôte du serveur ne correspond plus à ce qui est stocké dans ~/.ssh/known_hosts. Les causes légitimes incluent la réinstallation du serveur ou la réaffectation d’adresse IP. Les causes malveillantes incluent une attaque de l’homme du milieu. Enquêtez avant de continuer.
Si vous avez confirmé que le serveur a été légitimement réinstallé :
ssh-keygen -R your_server_ip
Reconnectez-vous ensuite et vérifiez l’empreinte de la nouvelle clé d’hôte par rapport à la console du serveur ou au tableau de bord du fournisseur avant de l’accepter.
Authentification multi-facteurs pour SSH
L’authentification par clé est robuste, mais l’ajout d’un second facteur TOTP (Time-based One-Time Password) crée une défense en profondeur. Même si une clé privée et sa phrase secrète sont compromises, un attaquant ne peut pas s’authentifier sans le jeton TOTP.
Installez et configurez libpam-google-authenticator sur le serveur :
apt install libpam-google-authenticator
google-authenticator
Configurez ensuite PAM et sshd_config :
# /etc/pam.d/sshd - add this line
auth required pam_google_authenticator.so

# /etc/ssh/sshd_config
UsePAM yes
ChallengeResponseAuthentication yes
AuthenticationMethods publickey,keyboard-interactive
Avec AuthenticationMethods publickey,keyboard-interactive, un utilisateur doit fournir une clé valide ET un code TOTP. C’est la configuration de production correcte pour les serveurs à haute valeur.
Autorité de certification SSH : mise à l’échelle de la gestion des clés
Dans les environnements avec des dizaines de serveurs et plusieurs administrateurs, la gestion des entrées authorized_keys individuelles devient opérationnellement insoutenable. Les certificats SSH résolvent ce problème.
Une autorité de certification (CA) SSH signe les clés d’utilisateurs et d’hôtes. Les serveurs font confiance à la clé publique de la CA plutôt qu’aux clés d’utilisateurs individuels. L’ajout d’un nouvel administrateur nécessite uniquement la signature de sa clé publique — aucune modification du fichier authorized_keys d’aucun serveur.
# Create a CA key pair (store the private key offline or in a secrets manager)
ssh-keygen -t ed25519 -f /etc/ssh/ca_key -C "infrastructure-ca-2025"

# Sign a user's public key, valid for 7 days, for specific principals
ssh-keygen -s /etc/ssh/ca_key 
  -I "alice-ops-cert" 
  -n alice,deploy 
  -V +7d 
  ~/.ssh/id_ed25519.pub
Sur chaque serveur, configurez la confiance envers la CA :
# /etc/ssh/sshd_config
TrustedUserCAKeys /etc/ssh/ca_key.pub
C’est ainsi que les infrastructures à grande échelle (y compris les fournisseurs cloud et les entreprises) gèrent l’accès SSH sans gestion des clés par serveur.
Matrice de décision pratique : configuration SSH par cas d’utilisation



Cas d’utilisation
Type de clé
Port
Auth par mot de passe
Connexion root
Redirection
MFA








—
—
—
—
—
—
—








VPS personnel
Ed25519
2222+
Désactivée
Interdite
Désactivée
Optionnel








Serveur web de production
Ed25519
Non par défaut
Désactivée
Non
Désactivée
Requis








Bastion / hôte de rebond
Ed25519
22 ou personnalisé
Désactivée
Non
Contrôlée
Requis








Automatisation CI/CD
Ed25519 (clé de déploiement)
Non par défaut
Désactivée
Non
Désactivée
Non (clé uniquement)








Serveur de base de données
Ed25519
Non par défaut
Désactivée
Non
Locale uniquement
Requis








Serveur de développement
Ed25519
Par défaut ou personnalisé
Optionnelle
Non
Optionnelle
Optionnel





Configuration de SSH sur l’infrastructure AlexHost
Lorsque vous provisionnez un VPS ou un serveur dédié via AlexHost, l’accès SSH est configuré par défaut. Le mot de passe root initial est fourni par e-mail de provisionnement, et la première action recommandée est de :

Se connecter en tant que root, créer un utilisateur administratif non-root et ajouter votre clé publique au ~/.ssh/authorized_keys de cet utilisateur.
Appliquer la base de durcissement sshd_config documentée ci-dessus.
Désactiver l’authentification par mot de passe et la connexion root.
Configurer votre pare-feu pour restreindre l’accès SSH aux plages IP connues lorsque cela est opérationnellement faisable.

Si vous préférez une couche de gestion graphique en complément de SSH, les options VPS avec cPanel et Panneaux de contrôle VPS d’AlexHost fournissent une interface web pour les tâches courantes tout en laissant SSH disponible pour le contrôle administratif complet.
Pour les environnements où vous devez sécuriser des applications web fonctionnant sur le même serveur, associer le durcissement SSH à un certificat SSL correctement configuré couvre à la fois les couches de transport administratif et applicatif.
Liste de vérification des points clés techniques
Avant de considérer votre configuration SSH prête pour la production, vérifiez chacun des éléments suivants :
Gestion des clés

Les clés privées utilisent Ed25519 ou RSA-4096 minimum
Toutes les clés privées sont protégées par une phrase secrète robuste
Le répertoire ~/.ssh/ a les permissions 700 ; authorized_keys a 600

• Les clés de déploiement utilisent les options restrict et command= le cas échéant
• Le calendrier de rotation des clés est documenté et appliqué

Configuration du serveur

PasswordAuthentication no est défini et actif
PermitRootLogin no ou prohibit-password est appliqué
SSH fonctionne sur un port non par défaut avec les règles de pare-feu mises à jour
AllowUsers ou AllowGroups restreint l’accès aux comptes nommés
LoginGraceTime est défini à 30 secondes ou moins
sshd -t réussit sans erreurs après chaque modification de configuration

Durcissement cryptographique

KexAlgorithms exclut diffie-hellman-group1-sha1 et diffie-hellman-group14-sha1

• Ciphers exclut 3des-cbc, arcfour et blowfish-cbc
• MACs utilise uniquement les variantes -etm (encrypt-then-MAC)

Sécurité opérationnelle

• Les journaux d’authentification SSH sont surveillés (/var/log/auth.log ou journalctl -u sshd)
• fail2ban ou équivalent est configuré pour bloquer les échecs d’authentification répétés
• Les empreintes de clés d’hôte sont enregistrées et stockées hors bande pour vérification
• MFA est activé pour toutes les sessions utilisateur interactives sur les systèmes de production
• La CA SSH est utilisée pour les environnements avec plus de cinq serveurs ou trois administrateurs

FAQ

Quelle est la différence entre les clés SSH et les certificats SSH ?

Les clés SSH nécessitent que chaque serveur stocke la clé publique de l’utilisateur dans authorized_keys. Les certificats SSH sont signés par une autorité de certification ; les serveurs font confiance à la CA plutôt qu’aux clés individuelles. Les certificats s’adaptent aux grandes flottes sans gestion des clés par serveur et prennent en charge les délais d’expiration, ce qui simplifie la révocation.

Pourquoi Permission denied (publickey) apparaît-il même lorsque la clé est correcte ?

Les causes les plus courantes sont des permissions de fichier incorrectes sur ~/.ssh/ (doit être 700) ou authorized_keys (doit être 600), un répertoire personnel accessible en écriture par tous (bloqué par StrictModes), ou une directive AllowUsers dans sshd_config qui exclut le compte qui se connecte. Vérifiez journalctl -u sshd sur le serveur pour la raison spécifique du rejet.

Changer le port SSH du 22 est-il une vraie mesure de sécurité ?

Cela élimine les attaques automatisées et opportunistes ciblant le port 22, ce qui réduit significativement le bruit des journaux et les tentatives d’authentification échouées. Cela ne protège pas contre un attaquant ciblé qui effectue un scan de ports. Cela devrait être combiné avec fail2ban, l’authentification par clé uniquement et la liste blanche IP du pare-feu pour une amélioration significative de la sécurité.

Puis-je utiliser SSH sans adresse IP statique côté client ?

Oui. L’authentification par clé ne nécessite pas d’IP client fixe. Si vous souhaitez restreindre par IP, utilisez l’option from= dans authorized_keys ou des règles de pare-feu. Pour les IP dynamiques, envisagez un VPN pour établir une identité réseau stable avant de vous connecter, plutôt que d’ouvrir SSH à l’ensemble d’Internet.

Quelle est la façon la plus sûre de récupérer l’accès SSH si je suis bloqué ?

Accédez au serveur via la console hors bande de votre fournisseur d’hébergement (VNC, IPMI ou KVM over IP). De là, montez le système de fichiers, corrigez le problème sshd_config ou authorized_keys et redémarrez le démon SSH. Sur les plans VPS et serveur dédié d’AlexHost, la console du fournisseur est disponible via le portail client et ne dépend pas du bon fonctionnement de SSH.