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
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
