When an internet-exposed reverse tunnel is being brute-force attacked, and there's more than one such tunnel in effect, the logs don't indicate which tunnel the invalid user or password login attempt was being used.? It's pretty certain that it's one of the reverse tunnels, though, because the log entry reports that the attack came from the loopback device's IP: Dec? 1 15:50:25 ory sshd[21398]: Invalid user nyk from 127.0.0.1 port 52140 Dec? 1 15:50:25 ory sshd[21398]: Received disconnect from 127.0.0.1 port 52140:11: Bye Bye [preauth] Dec? 1 15:50:25 ory sshd[21398]: Disconnected from invalid user nyk 127.0.0.1 port 52140 [preauth] But which tunnel?? If I knew which tunnel, maybe I could figure out a way to detect and block the attackers' IP addresses via fail2ban, etc. I found an interesting solution <https://en.wikibooks.org/wiki/OpenSSH/Logging_and_Troubleshooting#Connections_Seemingly_From_127.0.0.1,_::1,_or_Other_localhost_Addresses>, which is basically to establish each reverse tunnel to a distinct IP address, with all such addresses being aliases for localhost, e.g.: ssh ... -R *:2621:127.0.0.75:22 ... ... instead of the more usual ... ssh ... -R *:2621:127.0.0.75:22 ... .? Note that an... ssh 127.0.0.75 ...connects to localhost, like all other 127.0.0.0/16 possibilities, but the "75" uniquely identify a specific tunnel -- a specific ssh invocation -- for purposes of logging. Alas, the "interesting solution" doesn't work; ssh logs... Dec? 1 15:50:25 ory sshd[21398]: Invalid user nyk from 127.0.0.1 port 52140 ... instead of ... Dec? 1 15:50:25 ory sshd[21398]: Invalid user nyk from 127.0.0.75 port 52140. Is this a bug?? Is there some other solution to the problem?? The suggested solution is kind of a hack; a more general solution might be to provide an invocation parameter that would simply be included verbatim in the log. (I'm using openssh 7.9, Debian 10.6 (stable) Linux.) SteveNewcomb