Sujet : ssh
-
Paramètres post-quantiques par défaut d'OpenSSH et avertissement d'échange de clés non post-quantique
Relier l'avertissement d'OpenSSH à l'échange de clés sélectionné, vérifier les paramètres effectifs des deux extrémités et rétablir une négociation hybride sans affaiblir l'authentification de l'hôte.
-
Les avertissements SSH « Host key verification failed » et « REMOTE HOST IDENTIFICATION HAS CHANGED »
OpenSSH refuse de se connecter et affiche « Host key verification failed » ou la grande bannière « WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! » lorsque la clé du serveur ne correspond pas à celle enregistrée dans known_hosts. L'article explique pourquoi un serveur reconstruit et une véritable attaque produisent le même message, et comment les distinguer avant d'exécuter ssh-keygen -R.
-
« Permission denied (publickey) » avec SSH : l'interpréter grâce à ssh -v
Dans OpenSSH, « Permission denied (publickey) » signifie que toutes les clés proposées par le client ont été rejetées, ou qu'aucune n'a été proposée, sans préciser laquelle. L'article montre comment ssh -v désigne précisément les clés essayées et passe en revue les cas suivants : mauvais nom d'utilisateur, IdentitiesOnly, permissions d'authorized_keys côté serveur et abandon par défaut de ssh-rsa (SHA-1) depuis OpenSSH 8.8.
-
Régénérer les clés d'hôte SSH et le machine ID d'un hôte Linux cloné
Un hôte Linux fraîchement cloné doit disposer de ses propres clés d'hôte SSH et de son propre machine ID avant de rejoindre un parc ; ssh-keygen -A et systemd-machine-id-setup permettent de les créer, mais sur un clone déjà démarré, un machine ID dupliqué exige l'écriture d'une nouvelle valeur puis un redémarrage. Rechercher les doublons sur l'ensemble du parc est la seule vraie vérification que le clonage n'a pas simplement copié les mêmes identifiants partout.
-
Tunnels SSH : redirection de port locale, distante et dynamique
ssh -L expose un service distant sur un port local, -R expose un service local sur l'hôte distant, -D fournit un proxy SOCKS et -J permet de rebondir via un bastion ; les combiner avec -N, se lier à localhost et régler ExitOnForwardFailure afin qu'une redirection n'ayant pas pu être établie ne laisse pas une session silencieusement inutile.
-
SSH known_hosts et vérification de la clé d'hôte en automatisation : ssh-keyscan complété par un contrôle hors bande
Un processus automatisé qui se connecte en SSH doit tout de même vérifier la clé d'hôte du serveur : ssh-keyscan se contente de récupérer une clé sans prouver qu'elle est authentique. StrictHostKeyChecking=accept-new, HashKnownHosts et les enregistrements SSHFP couvrent chacun un aspect différent d'une mise en œuvre sûre, sans invite interactive.
-
Codes de sortie de ssh et scp : 255 signale un échec de ssh lui-même, tout autre code vient de la commande distante
ssh renvoie le code de sortie de la commande distante exécutée et réserve 255 aux échecs de ssh lui-même (connexion refusée, échec d'authentification, clé d'hôte non concordante) ainsi qu'aux commandes distantes tuées par un signal. La documentation de scp ne distingue que 0 (succès) et non nul (échec) ; pour différencier un problème de transport local d'une erreur distante, il faut donc lire la sortie d'erreur de ssh, et non le code de scp.
-
Exécuter des commandes CL IBM i depuis un shell SSH/PASE : system, qsh et pièges liés au CCSID
Depuis une session SSH vers IBM i PASE, l'utilitaire PASE for i `system` et l'environnement QSH/Qshell sont les deux moyens pris en charge pour exécuter des commandes CL et en récupérer la sortie. Tous deux convertissent entre le CCSID du job et l'encodage propre à PASE, source de la plupart des bogues d'intégration rencontrés au départ.
-
Exploiter un bastion SSH : ProxyJump côté client et restriction des redirections autorisées sur l'hôte de rebond
Un bastion doit relayer les connexions ProxyJump vers les hôtes internes sans servir de relais TCP généraliste. Cette méthode configure ProxyJump côté client, restreint AllowTcpForwarding et PermitOpen sur le bastion, et limite les exceptions à un bloc Match plutôt qu'à une autorisation globale.
-
Installer et sécuriser le serveur OpenSSH intégré à Windows Server
Add-WindowsCapability installe la fonctionnalité OpenSSH Server ; le fichier sshd_config se trouve sous %ProgramData%\ssh. Les clés autorisées d'un administrateur doivent figurer dans administrators_authorized_keys, protégé par une ACL restrictive, faute de quoi le serveur les ignore, et DefaultShell détermine ce qu'exécute réellement une session SSH.
-
Durcir un serveur SSH sans perdre l'accès
Désactiver la connexion par mot de passe et l'authentification interactive au clavier, restreindre root et les comptes autorisés, garder MaxAuthTries et LoginGraceTime serrés, préférer ProxyJump au transfert d'agent, et tester chaque modification de sshd_config avec sshd -t pendant qu'une seconde session reste ouverte.
Lisible par machine : JSON