Linux / Commande ss : ports en écoute, connexions et processus

ss, fourni par iproute2, affiche les sockets de Linux : ports en écoute, connexions et, avec les droits nécessaires, processus associés. Pour voir les ports TCP en écoute sans convertir les ports en noms de services, utilisez ss -ltn. Un port en écoute indique une disponibilité locale du socket, mais ne prouve pas que le service est accessible depuis Internet.

Afficher les ports TCP et UDP en écoute

Un socket est un point de communication géré par le système. TCP, Transmission Control Protocol, établit des connexions ; UDP, User Datagram Protocol, échange des datagrammes sans la même procédure d’établissement. Les états et les résultats de ces deux protocoles se lisent donc différemment.

ss -ltn
ss -lun
sudo ss -ltnup

La première commande sélectionne TCP avec -t et les sockets en écoute avec -l. La seconde sélectionne UDP avec -u. -n conserve les numéros de port : un numéro tel que 22 reste visible au lieu d’un nom de service. La troisième réunit TCP et UDP et demande les processus avec -p ; sudo peut rendre visibles les informations de sockets d’autres utilisateurs.

Sans -l ni -a, ss n’affiche pas les sockets en écoute par défaut. Une recherche de serveur qui utilise seulement ss -tn peut donc manquer précisément le port recherché. Utilisez -a pour inclure à la fois les sockets en écoute et ceux qui ne le sont pas, en conservant les filtres de protocole nécessaires.

Comprendre l’adresse locale et l’état

Voici une sortie fictive de ss -ltn. Les colonnes et valeurs dépendent du système et de la version :

State  Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0      128    0.0.0.0:22         0.0.0.0:*

LISTEN désigne ici un socket TCP qui attend des connexions. Local Address:Port indique l’adresse et le port de ce côté de la communication ; Peer Address:Port concerne l’autre extrémité. Sur ce socket d’écoute, la valeur générique du pair ne représente pas un client déjà connecté. Les colonnes de file ne constituent pas un débit réseau mesuré.

• 0.0.0.0:22 : liaison générique sur les adresses IPv4 locales, pour le port 22.
• 127.0.0.1:22 : liaison à la boucle locale IPv4 ; un accès distant direct à l’adresse externe de la machine n’atteint pas ce socket. Une redirection ou un proxy peut cependant créer un autre chemin d’accès.
• [::]:22 : liaison générique IPv6. Ne déduisez pas de cette seule ligne la prise en charge d’IPv4 : elle dépend notamment de la configuration du socket et du système.

Pour lever une ambiguïté de famille, consultez séparément ss -4 -ltn et ss -6 -ltn. Une application peut ouvrir plusieurs sockets, utiliser un autre espace de noms réseau ou écouter seulement sur une adresse particulière. La vue de ss porte sur l’environnement réseau dans lequel la commande s’exécute.

Pour UDP, UNCONN peut être un état normal d’un socket qui reçoit des datagrammes sans pair fixé. Ce n’est pas l’équivalent d’un échec de connexion TCP. Inversement, un socket UDP peut avoir un pair associé sans qu’une poignée de main TCP ait eu lieu.

Filtrer un port, un état et retrouver un processus

ss -tn '( sport = :22 or dport = :22 )'
ss -tn state established '( sport = :22 or dport = :22 )'
sudo ss -ltnp 'sport = :22'

sport sélectionne le port source, c’est-à-dire le port local dans cette vue ; dport sélectionne le port du pair. Le premier filtre retient les sockets TCP hors écoute qui correspondent au port 22 d’un côté ou de l’autre. La deuxième commande ne conserve que l’état established, pour examiner les connexions TCP établies. La troisième cherche les sockets TCP en écoute sur le port local 22 et demande leurs processus.

Les apostrophes sont importantes : elles transmettent l’expression et ses parenthèses à ss sans que le shell les interprète. Remplacez 22 par le port réellement configuré ; un nom de service ou un numéro habituel ne garantit pas qu’une application utilise ce port.

Avec -p, une ligne peut inclure un nom de programme, un identifiant de processus et un descripteur de fichier. L’absence de cette information ne prouve pas que le socket n’a aucun propriétaire : les permissions, l’espace de noms ou un changement d’état pendant la consultation peuvent limiter ce qui est visible. Confirmez le service attendu avant toute intervention sur un processus.

Diagnostiquer un service sans confondre écoute et accès

1. Confirmez la famille, le protocole et le port attendus avec les commandes d’écoute adaptées. Si aucun résultat ne paraît, vérifiez aussi l’adresse configurée, le conteneur ou l’espace de noms concerné et l’état du service.
2. Lisez l’adresse de liaison. Une écoute sur la boucle locale répond à un autre besoin qu’une écoute sur toutes les adresses locales.
3. Identifiez le processus si les droits le permettent, puis vérifiez ses paramètres et journaux. Une écoute ne garantit pas une réponse correcte du protocole applicatif.
4. Pour un problème depuis une autre machine, vérifiez séparément les routes, les pare-feu de l’hôte et du réseau, les règles de l’hébergeur et la réponse applicative depuis le point d’accès concerné.

Les objets interface, adresse et route se consultent avec la commande ip pour le diagnostic réseau. ss répond surtout à la question des sockets locaux ; ses résultats ne remplacent pas un test de bout en bout autorisé.

ss -s

Le résumé aide à repérer un volume ou une répartition d’états à examiner ensuite, mais ne donne pas à lui seul la cause d’un incident. Des états tels que TIME-WAIT font partie du fonctionnement normal de TCP ; leur présence ne justifie pas automatiquement de fermer des sockets ou de changer des paramètres du noyau.

Les commandes de consultation de cet article ne ferment aucune connexion. Certaines autres options, notamment -K, peuvent en revanche fermer des sockets : ne les ajoutez pas à un diagnostic par analogie avec un filtre d’affichage. Le manuel ss d’iproute2 précise les familles, filtres et options disponibles.