1

I've done an ssh remote port forwarding:

[email protected]% ssh -R 127.0.0.1:11999:host2.a.com:99 [email protected] My understanding is that this creates a TCP socket on host3.b.com's localhost port 11999.

I then checked that from host3.b.com I can indeed access the service exposed at host3.b.com's localhost port 11999.

I've also checked that I can login to host3.b.com with a different ssh session (thus creating a new login shell) and can also access the service exposed at host3.b.com's localhost port 11999. This kind of scares me. I naively thought I'd get a different loopback interface for each login shell, but apparently not.

My question is: what about other people who can log into host3.b.com like my friend buddy and my enemy aHacker? Do they get assigned to the same loopback interface that I get when I log into host3.b.com? Or do they get their own private loopback interfaces and can't see my open port on my host3.b.com's localhost:11999? Is there a way to make sure that I'm the only user who can access a forwarded port?

Wandering Logic
  • 1,341
  • 11
  • 11
  • I never heard of a `different loopback interface for each login` unless I'm mistaken there is no such thing as a "different loopback interface" for each login let alone user. – Marco Feb 28 '23 at 17:57
  • You will need to do some authentication on your service that sits on port 11999 and control user behaviour that way. – Marco Feb 28 '23 at 17:58
  • _Maybe_ you can block certain users (or allow) with a software firewall solution on your host server. But it's definitely good design to authenticate someone over a connection _anyway_. – Marco Feb 28 '23 at 18:01
  • The service actually does do user authentication. Unfortunately, I'm going to have to shut off the port forwarding because the service is behind a firewall, and the owners of the server view the firewall as being an important aspect of the security. – Wandering Logic Feb 28 '23 at 18:02
  • I thought the TCP socket would have the same user access control as a UNIX socket, and it clearly doesn't. If I could just get my client to communicate over a UNIX socket instead of a TCP socket, I could use ssh to forward a UNIX socket instead of a TCP socket and I'd be fine, but I don't think the client supports UNIX sockets, just TCP sockets. – Wandering Logic Feb 28 '23 at 18:04
  • It's a good question nonetheless it's actually a good idea to restrict access to resources as much as possible. I just think this isn't possible without a firewall solution since ports are OS-wide (and not _tied_ to a specific user). I don't think you can achieve this with UNIX sockets, since you'll need TCP/IP for forwarding/routing the traffic through the internet. – Marco Feb 28 '23 at 18:05
  • [This](https://unix.stackexchange.com/questions/111906/allowing-users-to-access-certain-ports-on-server) might be able to solve your problem. It involves `iptables` and permitting/denying access to a specific port on a per user basis. – Marco Feb 28 '23 at 18:08

0 Answers0