Comment puis-je répertorier les MAC, les chiffrements et les KexAlogrithms pris en charge par mon serveur ssh?

Comment puis-je déterminer les MAC, les chiffres, la longueur de clé et les KexAlogrithms pris en charge par mes serveurs ssh?

J'ai besoin de créer une liste pour un audit de sécurité externe. Je cherche quelque chose de similaire à openssl s_client -connect example.com:443 -showcerts. D'après mes recherches, il sshutilise les chiffres par défaut répertoriés dans man sshd_config. Cependant, j'ai besoin d'une solution que je peux utiliser dans un script ~~et man sshd_configqui ne répertorie pas les informations sur la longueur des clés~~ . Je dois me corriger ici: vous pouvez spécifier ServerKeyBitsdans sshd_config.

Je suppose que cela ssh -vv localhost &> ssh_connection_specs.outrenvoie les informations dont j'ai besoin, mais je ne sais pas si les chiffres répertoriés sont les chiffres pris en charge par le client ou par le serveur. De plus, je ne sais pas comment exécuter ce non interactif dans un script.

Existe-t-il un moyen pratique d'obtenir SSHdes informations de connexion?

linux ssh audit

— Henrik Pingel
source

s'est avéré que sshd -T | grep "\(ciphers\|macs\|kexalgorithms\)"comme suggéré par @Jakuje ne fonctionne que sur les hôtes RHEL7, mais pas RHEL6. J'ai fini par utiliser nmap --script SSH2-hostkey localhostetnmap --script ssh-hostkey localhost

— Henrik Pingel

ssh -vvgénère les fonctionnalités prises en charge en tant que client vers serveur (ctos) et serveur vers client (stoc). Cependant, il semble que ces résultats soient limités à ce que les deux parties soutiennent, ce qui les rend moins utiles pour un audit de sécurité.

— Moshe

Réponses:

Vous manquez quelques points dans votre question:

Quelle est votre version openssh? Cela peut différer un peu selon les versions.
ServerKeyBits est une option pour le protocole version 1, que vous avez heureusement désactivée!

Les chiffrements, MAC et KexAlgorithms pris en charge sont toujours disponibles en manuel et cela n'a rien de commun avec les longueurs de clé.

Les Chiphers, MAC et KexAlgorithms activés sont ceux qui sont offerts en utilisant la connexion comme vous le faites remarquer. Mais ils peuvent également être obtenus par d'autres moyens, par exemple en utilisantsshd -T | grep "\(ciphers\|macs\|kexalgorithms\)"

Pour obtenir la longueur de clé de vos clés de serveur, vous pouvez utiliser ssh-keygen: ssh-keygen -lf /etc/ssh/ssh_host_rsa_key.pub

mais vous voudrez probablement aussi les tailles de modules qui sont proposées et utilisées lors de l'échange de clés, mais cela dépend vraiment de la méthode d'échange de clés, mais elle devrait également être lisible à partir de la sortie de débogage ssh -vvv host.

— Jakuje
source

Merci. Il s'est avéré que cela sshd -T | grep "\(ciphers\|macs\|kexalgorithms\)"ne fonctionnait que mes hôtes RHEL7, mais pas RHEL6. J'ai fini par utiliser nmap --script SSH2-hostkey localhostetnmap --script ssh-hostkey localhost

— Henrik Pingel

L'hôte RHEL6 avec la dernière mise à jour openssh devrait également le faire réparer.

— Jakuje

damm vous avez raison à ce sujet. Je n'ai vérifié que sur une machine virtuelle obsolète ... merci

— Henrik Pingel

sshd -T ne proposera que des informations sur les chiffrements configurés dans le fichier sshd_config, pas ce qui peut en effet y être ajouté comme étant pris en charge par le binaire

— Daniel J.

Comment puis-je déterminer les MAC, les chiffres, la longueur de clé et les KexAlogrithms pris en charge par mes serveurs ssh?

Il semble que la réponse sur /superuser//a/1219759/173408 soit également une réponse à votre question. Il tient sur une seule ligne:

nmap --script ssh2-enum-algos -sV -p 22 1.2.3.4

Voici la sortie sur une machine Debian 9.4 simple avec la version SSH actuelle:

Démarrage de Nmap 7.01 (https://nmap.org) le 22/05/2018 à 13h40 CEST
Rapport d'analyse Nmap pour 1.2.3.4
L'hôte est actif (latence de 0,00024 s).
VERSION DU SERVICE DE L'ÉTAT DU PORT
22 / TCP Open SSH OpenSSH 7.4p1 Debian 10 + deb9u3 (protocole 2.0)
| ssh2-enum-algos:
| kex_algorithms: (10)
| curve25519-sha256
| curve25519-sha256@libssh.org
| ecdh-sha2-nistp256
| ecdh-sha2-nistp384
| ecdh-sha2-nistp521
| diffie-hellman-group-exchange-sha256
| diffie-hellman-group16-sha512
| diffie-hellman-group18-sha512
| diffie-hellman-group14-sha256
| diffie-hellman-group14-sha1
| server_host_key_algorithms: (5)
| ssh-rsa
| rsa-sha2-512
| rsa-sha2-256
| ecdsa-sha2-nistp256
| ssh-ed25519
| algorithmes de chiffrement: (6)
| chacha20-poly1305@openssh.com
| aes128-ctr
| aes192-ctr
| aes256-ctr
| aes128-gcm@openssh.com
| aes256-gcm@openssh.com
| mac_algorithms: (10)
| umac-64-etm@openssh.com
| umac-128-etm@openssh.com
| hmac-sha2-256-etm@openssh.com
| hmac-sha2-512-etm@openssh.com
| hmac-sha1-etm@openssh.com
| umac-64@openssh.com
| umac-128@openssh.com
| hmac-sha2-256
| hmac-sha2-512
| hmac-sha1
| algorithmes_de compression: (2)
| aucun
| _ zlib@openssh.com
Informations sur le service: OS: Linux; CPE: cpe: / o: linux: linux_kernel

Détection de service effectuée. Veuillez signaler tout résultat incorrect sur https://nmap.org/submit/.
Nmap fait: 1 adresse IP (1 hôte) analysée en 0,52 seconde

— Stéphane Gourichon
source

J'obtiens un PORT STATE SERVICE VERSION 22/tcp filtered sshavec cette commande - bien que je puisse me connecter à ce même serveur via ssh.

— hey

Avez-vous littéralement utilisé la commande ou l'avez-vous remplacée 1.2.3.4par l'IP de votre serveur?

— Stéphane Gourichon

J'ai utilisé l'IP de mon serveur.

— salut