1

I have a server with multiple ip addresses. On this server a sshd is running and I can connect to it. I can also use this as a socks proxy, using ssh's danymic forwards, which is great. When I use the server as a socks proxy its default outbound ip address is used as source for the ip connections. Is there a way to configure which ip address will be used as source of the socks proxy?

To make an example: I have a client with the ip address 1.1.1.1 and a server with the ip addresses 2.2.2.2 and 3.3.3.3. 2.2.2.2 is used by default for all outbound ip connections from the server. I want to use ssh's dynamic forward to connect from 1.1.1.1 to 4.4.4.4 with the connection seem to be coming from 3.3.3.3, using the server and ssh as socks proxy.

Is there any way to configure ssh to use 3.3.3.3 as source ip when I make connections using the ssh dynamic forward? A way that avoids to change the general routing on that server, a way that uses maybe netcat and avoids iptables, would be preferred.

pnbecker
  • 13

1 Answers1

0

It appears the openssh daemon doesn't include this feature currently: the function connect_next() opening connections doesn't use any bind() system call, but only socket() and connect(): there's no provision made for altering the default source address.

Here's a route based method using a feature which appeared in Linux 4.10 (thus kernel >= 4.10 is a prerequisite):

  • Linux 4.10 added support for per-UID routing, which avoids having to resort to clumsy iptables rules.

  • Considering that sshd switches to the target ssh user once autheticated, the forwarded connection will be initiated on behalf of that authenticated ssh user on the server rather than root.

One can create specific routing rules tied to a specific user: this user (and only this user) will trigger the use of alternate route settings, which will be set the same as the normal routes, except for the default source IP address. This requires copying most of the main routing table into the alternate routing table to cover all cases.

So if the Linux system has a dedicated user from3333 with uid 3333 and this following route as would display ip route (inferred from this comment, please replace 2.2.2.1 with the actual gateway and use the correct interface name), with a secondary address 3.3.3.3 also set on eth0 but which doesn't appear in the main routing table:

default via 2.2.2.1 dev eth0
2.2.2.0/24 dev eth0 proto kernel scope link src 2.2.2.2

this would require to override the default route, and for dependency reasons (2.2.2.1 must have a route at the time the table 3333 below is looked up, which would happen before the main table would have been looked up to provide it) also the LAN route. This gives in the end:

# ip route add table 3333 2.2.2.0/24 dev eth0 src 3.3.3.3
# ip route add table 3333 default via 2.2.2.1 dev eth0 src 3.3.3.3
# ip rule add uidrange 3333-3333 lookup 3333

Now any packet sent by uid 3333 (aka user from3333) will select the routing table 3333 which will select the default source address 3.3.3.3 instead of 2.2.2.2 (unless overridden by the application which won't be the case for sshd), but beside this will use the same routes. For example reply packets, which don't have from3333 as owner, will still select the main routing table and this will still work as expected.

This will affect any connection created by user from3333 on the server, including those initiated through DynamicForward/-D or LocalForward/-L on behalf of the ssh running from the client system.

If the server has (in order of complexity) additional routes, routing rules or routing tables, this answer has to be adapted on a case-by-case basis, possibly requiring more route duplication work to do.

A.B
  • 6,306