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 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).
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?
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.
Created attachment 3570 [details] 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.
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).
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?
How about using some other symbol for denoting the port? "\" for example?
(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.
> - 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?
(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).