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