RemoteForward Dynamic Port Allocation

Jochen Bern Jochen.Bern at binect.de
Wed Jul 10 21:37:17 AEST 2024


On 09.07.24 18:47, Thorsten Glaser wrote:
> On Tue, 9 Jul 2024, Jochen Bern wrote:
>> allocated" the *same* port, one for SSH, one for HTTPS:
> 
> No, it’s not the same port, it’s a different (address, port) tuple.

Well, if you want to discuss technicalities, please note that the 
"v4+v6" forward usually results in *separate* LISTENing ports for v4 and v6:

> # ss -natp | grep '^LISTEN .*,pid=22509,'
> LISTEN     0      128    127.0.0.1:34014        *:*    users:(("sshd",pid=22509,fd=9))
> LISTEN     0      128    127.0.0.1:24676        *:*    users:(("sshd",pid=22509,fd=11))
> LISTEN     0      128      [::1]:24676       [::]:*    users:(("sshd",pid=22509,fd=10))

so that the starting sshd's *do* indeed compete for the *same* (v4) 
endpoint, with the one wanting v4+v6 "losing" (this once? systematically?):

> # ss -natp | grep '^LISTEN .*,pid=22511,'
> LISTEN     0      128    127.0.0.1:13733        *:*    users:(("sshd",pid=22511,fd=9))
> LISTEN     0      128      [::1]:34014       [::]:*    users:(("sshd",pid=22511,fd=10))


>> Is there anything I can do to prevent a port number being double assigned like
>> this?
> 
> Use IPv4+IPv6 bindings for both?

I explained right in the initial post why I'm doing it like that. If you 
know another way to tell the two "port dynamically assigned" 
RemoteForwards of a single SSH login apart on the server side (other 
than doing port scans all the way onto the appliances to see which one 
returns an SSH server hello - I already found it necessary to introduce 
a cacheing layer to prevent them all getting hit 24/7 just to obtain a 
*listing* of currently-connected appliances), I'm all ears.

Kind regards,
-- 
Jochen Bern
Systemingenieur

Binect GmbH
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3447 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20240710/8f2bf6e6/attachment.p7s>


More information about the openssh-unix-dev mailing list