openssh bugs - Feb 2022 - [Bug 3386] New: [FEATURE REQUEST]Option to set client source port.

https://bugzilla.mindrot.org/show_bug.cgi?id=3386

            Bug ID: 3386
           Summary: [FEATURE REQUEST]Option to set client source port.
           Product: Portable OpenSSH
           Version: -current
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: ssh
          Assignee: unassigned-bugs at mindrot.org
          Reporter: yasen6275 at abv.bg

Hello,

How plausible is to add option in ssh client that fixes source port of
the connection?

My idea is to filter connections server side by source port and
redirect all that are coming from wrong port to tarpit like endlessh. 

Best regards
Yasen

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3386

Darren Tucker <dtucker at dtucker.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dtucker at dtucker.net

--- Comment #1 from Darren Tucker <dtucker at dtucker.net> ---
You can do this with a ProxyCommand such as netcat.  Something like

ProxyCommand nc -p 1234 %h %p

should work.

Note that use a single source port you'll have problems if you try to
use more than one connection at a time (or within 2 minutes of closing
the last one unless the proxycommand supports setting SO_REUSEADDR or
SO_REUSEPORT).

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3386

--- Comment #2 from Yasen <yasen6275 at abv.bg> ---
Yeah I'm aware of that possibility, but don't like it somehow. Probably
because I feel that as a missing option of the ssh client, not
something that has to be worked around with external program. 

But I guess your reply means that you wont consider that request,
right?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3386

--- Comment #3 from Darren Tucker <dtucker at dtucker.net> ---
We've talked about extending the syntax of BindAddress/-b to support
this use case (similar to the existing support in things like port
forwarding) but so far it has not been a high priority.  That said,
it's likely that most of the required bits are already there.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3386

--- Comment #4 from Darren Tucker <dtucker at dtucker.net> ---
Created attachment 3570
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3570&action=edit
Add optional port to BindAddress and -b

Only lightly tested, but this adds an optional bind port to ssh -b and
BindAddress.  It supports both "address:port" and ":port"
forms.  We
would need add the equivalent functionality to BindInterface too.  That
doesn't look that hard but would need a bit of reshuffling.

Please test it and let us know if it works for you.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3386

--- Comment #5 from Darren Tucker <dtucker at dtucker.net> ---
Just noticed a problem with this patch: previously bare IPv6 addresses
would be accepted:

$ ssh -vvv -b '::1' ::1

however with this patch it can't distinguish between a bare IPv6
address and an optional port:

$ ssh/obj/ssh -b '::1' ::1
Invalid BindAddress specification '::1'
ssh: connect to host ::1 port 22: failure

So this would potentially break currently working configs.

We have a convention of putting addresses inside square brackets for
that case, but that doesn't work in the patch (hpdelim2 has code to
support this but AFAICT it doesn't work, at least for this case).

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3386

--- Comment #6 from Yasen <yasen6275 at abv.bg> ---
Sorry by my programing patching and compiling skills are quite limited.

Is this patch made against 8.8p1 version or same development git/svn
version?

Compiled ok. I think.

Seems to be working:
$ ./ssh -b :6969 ovirt
$ sudo lsof -i -P -n | grep ssh
...
sshd      2556482     root    4u  IPv4 5607043      0t0  TCP
...:22->...:6969 (ESTABLISHED)

Seems to be working.

Any idea how to test it more rigorous besides using it?

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3386

--- Comment #7 from Yasen <yasen6275 at abv.bg> ---
How about using some other symbol for denoting the port? "\" for
example?

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3386

--- Comment #8 from Darren Tucker <dtucker at dtucker.net> ---
(In reply to Yasen from comment #7)
> How about using some other symbol for denoting the port? "\" for
> example?
Some options actually support an obsolete form using "/" as a
separator
but we've been deprecating that because for better or worse the world
has  settled on ":" with square brackets and "/" can be
misinterpreted
as a subnet specification.

Anyway, I think we could require square brackets when supplying a port.
 That would give the following semantics which would be backward
compatible:
 - no colons: IPv4 or hostname
 - one colon: IPv4 and port or hostname and port
 - two or more colons and no square brackets: bare IPv6 address.
 - two or more colons and square brackets: IPv6 address and port.

I got as far as adding a unit test to make I don't break it any
further.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3386

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org

--- Comment #9 from Damien Miller <djm at mindrot.org>
---
> - one colon: IPv4 and port or hostname and port
I guess you mean this case to cover ":port" too when the
address/hostname is the empty string?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3386

--- Comment #10 from Darren Tucker <dtucker at dtucker.net> ---
(In reply to Damien Miller from comment #9)
> > - one colon: IPv4 and port or hostname and port
> 
> I guess you mean this case to cover ":port" too when the
> address/hostname is the empty string?
Yes.  I used this in the patch above, but did not explicitly state it
or add a unit test for it (yet).

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.