Which reverse tunnel is being brute-force attacked?

[Steve Newcomb]

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