SSH port forwarding : different IP/port on server

[b4u]

Hi,

I have a question regarding SSH server on Linux that I hope you can help me out to see if it's possible and how.

I want to allow port forwarding for a user, but only to a specific IP/port, a fake one. So let's say the user connects to ssh with option -L 3000:9.9.9.9:2000

On the client side, he's opening a local port 3000 and it will forward on server side to 9.9.9.9:2000.

The thing is, I want to only allow port forwarding to that IP/port destination, and they do NOT exist. I want to rewrite/alias that IP/port to the correct one (for example a real existing IP/port like 192.168.0.200:3080).

This way the client can connect to 127.0.0.1:3000, client knows he's tunneling to 9.9.9.9:2000, but that is not the correct destination, and server side the connection is being made to 192.168.0.200:3080, which the client doesn't know.

Meaning this way the client will not even know what IP address I'm using, thus not inferring anything about my network.

Is it possible with SSH server on Linux?


Thanks.

 

[mv2devnull]

Nothing in man sshd_config hints about such things.

From point of view of the server the sshd is just a local process that connects "out" to 9.9.9.9:2000.
The server could perhaps port forward (with nftables) and filter the outgoing connections?

 

[you2]

This seems to ahve what you want (not 100% sure so read it carefully):

Restrict SSH access to port forwarding to one specific port - Experiencing Technology

Allowing access to an unprotected service on a server is always a problem. Sometimes the easiest way is to not expose this service to the network but ...

blog.tinned-software.net

 

[mxnerd]

Googled

Google Search

 

[mv2devnull]

@you2:
The "no-port-forwarding,permitopen" lets us(?) set the limit that the user can forward only to 9.9.9.9:2000. Furthermore, how do you restrict the public key of the user so that the user won't remove the limitation?

@mxnerd:
Latest openssh has option "ProxyJump", "-J", that makes simplifies daisy chaining syntax.
Alas, OP asks for obfuscation of true destination from the user. No daisies.

 

[you2]

This is the private key. The server has to have the private key - that is also how it identifies the user. I'm not sure if this works if you allow password login via ssh as i have not tested it.

@you2:
The "no-port-forwarding,permitopen" lets us(?) set the limit that the user can forward only to 9.9.9.9:2000. Furthermore, how do you restrict the public key of the user so that the user won't remove the limitation?

@mxnerd:
Latest openssh has option "ProxyJump", "-J", that makes simplifies daisy chaining syntax.
Alas, OP asks for obfuscation of true destination from the user. No daisies.

 

[mv2devnull]

This is the private key. The server has to have the private key - that is also how it identifies the user.

The ssh keypair has two parts:
* User (client) has "private" part. It should be password-protected and not to be revealed to anyone.
* The "public" part is added to authorized_keys on servers.
Server allows connection (authenticates user), if any of its public keys matches the client's private key(s).
User can thus connect to all servers that have a copy of user's public key.

Reading your link more carefully ... that server has special account, whose authorized_keys contains public keys of all allowed users, but the only action is allowed to that account is creation of a tunnel. No shell session. No file transfer.

That technique is essential in limiting information available to the users, but it does not answer the OP question.

 

[you2]

Thanks for correcting me. Yea i said it backwards. I'm not sure that limiting shell session is a requirement for this to work but as i said i merely skimmed the article. It does sound like it was a server setup for tunneling.... We had something like that at work.

The ssh keypair has two parts:
* User (client) has "private" part. It should be password-protected and not to be revealed to anyone.
* The "public" part is added to authorized_keys on servers.
Server allows connection (authenticates user), if any of its public keys matches the client's private key(s).
User can thus connect to all servers that have a copy of user's public key.

Reading your link more carefully ... that server has special account, whose authorized_keys contains public keys of all allowed users, but the only action is allowed to that account is creation of a tunnel. No shell session. No file transfer.

That technique is essential in limiting information available to the users, but it does not answer the OP question.

 

[mxnerd]

After re-reading OP's post, what he wants is to have a fake IP (using ssh or not).

I don't think we have fake IP thing in the real world networking.

 

[mv2devnull]

Well, one could ...
* set up a software bridge and VM. Give host 9.9.9.8 and VM 9.9.9.9 [1]
* give VM second address on the 192.168.0/x "b4u network"
* set the VM port forward its 9.9.9.9:2000 into 192.168.0.200:3080

The sshd would happily talk with the "9.9.9.9" with no clue that it is just a "NAT-router".

Depending on what actually runs in 192.168.0.200:3080 the sense of obscurity could be false.

So,
"Is it possible with Linux?" Sure.
"Is it feasible?" Depends.
"Is it sane?" ...


[1] It would be much smarter to use some private subnet, rather than 9.9.9.*

 

[you2]

You can have 'fake' ip easily. We did it all the time. If they are on the local net just make them 172.16.* (there are several other options). Conversely if it is on the same machine 127.0.0.*

Technically you can use any ip if you setup your routing tables to keep them on the local net.

After re-reading OP's post, what he wants is to have a fake IP (using ssh or not).

I don't think we have fake IP thing in the real world networking.

 

[mxnerd]

Well, one could ...
* set up a software bridge and VM. Give host 9.9.9.8 and VM 9.9.9.9 [1]
* give VM second address on the 192.168.0/x "b4u network"
* set the VM port forward its 9.9.9.9:2000 into 192.168.0.200:3080

The sshd would happily talk with the "9.9.9.9" with no clue that it is just a "NAT-router".

Depending on what actually runs in 192.168.0.200:3080 the sense of obscurity could be false.

So,
"Is it possible with Linux?" Sure.
"Is it feasible?" Depends.
"Is it sane?" ...


[1] It would be much smarter to use some private subnet, rather than 9.9.9.*

Exactly what I thought. But probably not in the sense of OP's thinking.

 

[b4u]

Man, and I thought this would be easier ...

I'm trying to resume here what I'm thinking so far.

I can, on server side, restrict a specific user to only allow port forwarding to a specific destination and no shell:

no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,permitopen="9.9.9.9:2000" ssh-rsa AAAA...GdaAR test@example.com

From what I can see, the client side would be able to open a tunnel using option -L 3000:9.9.9.9:2000 and unable to do any other port forwarding. Blocking the user from opening a shell would be important so it does not change those settings, and anyway the user will only need port forwarding (no shell) he only needs to access a service.

Now on server, I could probably have 9.9.9.9:2000 being routed to 192.168.0.200:3080, knowing that IP 9.9.9.9 does not exist on the network.

Theoretically, this all seems possible, right?


Thank you for your opinions.

 

[mv2devnull]

Is, not just seems.

Now on server, I could probably have 9.9.9.9:2000 being routed to 192.168.0.200:3080, knowing that IP 9.9.9.9 does not exist on the network.

No. The 9.9.9.9 is a public address and belongs to Quad9 organization.
The address that the client forwards to must exists and definitely should not be a public, routable address.

Use private addresses for your additional subnets: https://en.wikipedia.org/wiki/IP_address#Private_addresses
Something from 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16.

BTW, the 192.168.0.0/24 is probably one of the most frequently used private subnet ranges.
If one would blindly attempt to test your router/firewall, they would probably start with 192.168.0.0/24 (which includes 192.168.0.200).
(Not that it really matters much, the entire IPv4 address space is "small" to probe through.)

 

[you2]

My router users 172.16 and the company where i worked used 172.16 exclusively. I'm not sure 192.168 is used any more frequently.

Is, not just seems.


No. The 9.9.9.9 is a public address and belongs to Quad9 organization.
The address that the client forwards to must exists and definitely should not be a public, routable address.

Use private addresses for your additional subnets: https://en.wikipedia.org/wiki/IP_address#Private_addresses
Something from 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16.

BTW, the 192.168.0.0/24 is probably one of the most frequently used private subnet ranges.
If one would blindly attempt to test your router/firewall, they would probably start with 192.168.0.0/24 (which includes 192.168.0.200).
(Not that it really matters much, the entire IPv4 address space is "small" to probe through.)

 

[b4u]

No. The 9.9.9.9 is a public address and belongs to Quad9 organization.
The address that the client forwards to must exists and definitely should not be a public, routable address.

Use private addresses for your additional subnets: https://en.wikipedia.org/wiki/IP_address#Private_addresses
Something from 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16.

Hi,

The thing is, the 9.9.9.9 should not be a public nor private address, it should only be an IP format value that will then be re-wired to the real internal IP address

With a private address range for the internal network as 192.168.0.0/16, for instance the SSH server will be listening on 192.168.1.100:22, the router/firewall will redirect incoming traffic from the public address (for example: 92.122.240.123) on port 22 to that SSH server.

There will be another server providing a service, on 192.168.0.200:3080, and I want to externally give access to it, through SSH tunneling, but without exposing any private details.

So for instance a client will connect using the command:
ssh -N -i /path/to/priv.key -L 3000:9.9.9.9:2000 -l user 92.122.240.123

From the client side, a person with some knowledge will understand that IP 9.9.9.9 is probably incorrect/invalid, but at the same time it will not have any idea, from that command alone, what is my private range, and more importantly, which internal server IP/port address I'm connecting to.

the following command would work, but it exposes information regarding the target (private) IP and the port number, which many times provides information about the service running there:
ssh -N -i /path/to/priv.key -L 3000:192.168.0.200:3080 -l user 92.122.240.123

Furthermore, if I change the target service machine's IP/port address, I can simply re-wire the internal routing from 9.9.9.9:2000 to the new internal server without any impact on any client that uses such connection.

 

[you2]

Any ip can be used if you set a custom routing table. By default 9.9.9.9 would not be handled by your local network and would be handed to the router to be routed. If you use an ip that exist on the public network but set a routing rule to handle it locally then it would be handled locally and the public machine would not be accessible.