Comment déterminer le port alloué sur le serveur pour un tunnel inverse openssh lié dynamiquement?

Lors de la création de tunnels inverses sur les versions récentes d'OpenSSH, un port distant de 0 peut être attribué pour lier n'importe quel port disponible:

-R [bind_address:] port: hôte: port hôte

...

Si l'argument du port est «0», le port d'écoute sera alloué dynamiquement sur le serveur et signalé au client au moment de l'exécution.

page de manuel du client openssh ssh

Ma question est de savoir comment je peux (de manière automatisée) déterminer cette allocation de port sur le serveur. Il semble plutôt inutile qu'il soit signalé à l'hôte exécutant le client ssh - mais pas à la cible, qui voudra établir des connexions à ce port pour accéder aux services sur le client.

Deux options similaires auxquelles je peux penser sont en cours d'exécution

# netstat -ntlp

sur le serveur et recherchez les ports suspects liés sur 127.0.0.1 par sshd ou en regardant la sortie de

# lsof -p $PPID | grep TCP | grep LISTEN

Mais aucun de ces éléments n'est agréable du point de vue de l'automatisation, et il n'y a aucun moyen de rattacher les ports dynamiques au port de service d'origine si plusieurs tunnels de ce type sont créés.

Y a-t-il quelque chose qui me manque pour obtenir efficacement une liste des tunnels actifs (à la fois les numéros de port locaux et distants) côté serveur sshd, comme un équivalent à la variable d'environnement SSH_CONNECTION, mais pour les tunnels actifs?

Pour un certain contexte, j'essaie de créer potentiellement de très nombreux tunnels inverses simultanés vers un hôte, en tunnelant vers le même numéro de port sur de nombreux hôtes différents. La gestion automatique du pool de ports par la pile TCP semble être le moyen le plus efficace de procéder.

Si vous définissez «LogLevel» dans le fichier de configuration sshd_config sur DEBUG1 (ou tout niveau DEBUG), sshd enregistrera les numéros de port dans /var/log/auth.log.

N'oubliez pas que l'utilisation d'un LogLevel de DEBUG ou supérieur peut représenter un risque pour la confidentialité, car une grande partie est enregistrée.

(de /var/log/auth.log, supprimé quelques lignes pour afficher les informations pertinentes)

Jun 24 06:18:24 radon sshd[9334]: Connection from 192.168.13.10 port 39193
Jun 24 06:18:24 radon sshd[9334]: Accepted publickey for lornix from 192.168.13.10 port 39193 ssh2
Jun 24 06:18:24 radon sshd[9334]: pam_unix(sshd:session): session opened for user lornix by (uid=0)
Jun 24 06:18:24 radon sshd[9334]: User child is on pid 9339
Jun 24 06:18:24 radon sshd[9339]: debug1: Local forwarding listening on 0.0.0.0 port 0.
Jun 24 06:18:24 radon sshd[9339]: debug1: Allocated listen port 39813
Jun 24 06:18:24 radon sshd[9339]: debug1: channel 0: new [port listener]
Jun 24 06:18:24 radon sshd[9339]: debug1: Local forwarding listening on :: port 39813.
Jun 24 06:18:24 radon sshd[9339]: debug1: channel 1: new [port listener]
Jun 24 06:18:27 radon sshd[9339]: Received disconnect from 192.168.13.10: 11: disconnected by user

Si vous le suivez, vous pouvez voir où vous pouvez analyser les informations de connexion, puis le port redirigé (39813 dans ce cas)

J'ai utilisé cette ligne de commande entre deux de mes machines, j'ai une connexion ssh-key configurée, donc pas d'invite de mot de passe ni de retard

-xenon- lornix:~> ssh -R "*:0:radon:22" -N -T radon
Allocated port 39813 for remote forward to radon:22

-N spécifie qu'aucune commande n'est donnée et -T arrête l'allocation d'un terminal pour cette connexion.

Une autre façon de diffuser les informations de connexion au port serait de les analyser du côté client et d'envoyer un e-mail, un jabber, un SMS, des signaux de fumée ou un pigeon pour transporter le port # à qui en a besoin.

Vous pouvez diriger le stderr de sshdans un programme qui ouvre une connexion à un serveur sur la machine cible et signale son nom de machine / adresse IP / numéro de série / peu importe avec le numéro de port. Un peu comme ça:

% ssh -R "*:0:radon:22" -N -T radon 2>&1 | sed "s/^/`uname -n` /" | netcat radon 3743