3

I understand that the permitopen="host:port" option limits the use of ssh -L to a single remote port. Is there a way to do the same with ssh -R?

Kamil Maciorowski
  • 81,893
Hoal James
  • 31

1 Answers1

1

is there a way to do the same with ssh -R?

Not really "the same". For the most common usage of ssh -R there is little to no point in having such option, but read this answer to the end.

Analysis

PermitOpen is an option in sshd_config. It affects not only ssh -L, but also ssh -D, ssh -W and ssh -J (at least). I think it's designed as a filter to TCP connections initiated by the SSH server on request of a client.

Imagine you're an admin of the server. The client, for whom SSH may be the only entrance to the system, may be totally untrusted. The system may be a bastion the client should use only to obtain a tunnel to well-defined location(s). You are able to set things up, so the client cannot run arbitrary commands. Then you may want your computer not to initiate connections to random addresses for this client. PermitOpen lets you configure this easily.

An option in sshd_config that would limit the target of client's ssh -R is not useful for you (the admin of the SSH server) because:

  1. In case of ssh -R, any connection to the target address:port will originate from the client's system which is not your concern. Your concern is the interface and the port your system will listen on. There is an option to limit this: PermitListen.

  2. I don't think ssh (the client's application) even reports this address:port to the SSH server.

  3. Even if it did, a modified ssh (or anything using the protocol) could lie. The server has no means to tell what ssh does with any data on its end.

  4. Even if the client's application didn't lie, the client could request address:port you allow and locally use iptables, socat, /etc/hosts or its own DNS server to connect the tunnel to another address and another port.

In short: as an admin of the server you cannot control the client's side anyway. Do not try; it's not your concern.

Maybe you meant an option to limit ssh -R on the client's side, in ssh_config. At first glance such option makes some sense; but think about it and you'll notice that:

  1. It's the client who wants a tunnel to some address:port, so certainly he or she won't be interested in any limiting in ~/.ssh/config.

  2. An admin of the client's system (where the client may be a regular user) may want to impose some limitations, e.g. in /etc/ssh/ssh_config. But with ssh personal config and command line options take precedence, the client can override any global config. This is by design and you shouldn't fight it because…

  3. If you're the admin of the client's system and you don't want the client to connect to some address:port then what difference does it make if they try to establish such connection using ssh, nc or anything else? You need a solution with scope broader than the config of ssh.

    Note there's asymmetry: on the server side, in cases where SSH is the only entrance for the client to the system, limiting in sshd_config makes sense. On the client's side the client is already in the system, ssh is just a program he or she can use; therefore limiting (if needed) should be more system-wide than in ssh_config.

PermitRemoteOpen

There is one scenario in which the client may be interested in limiting address:port his or her ssh can connect to. And it is with ssh -R; but not the ssh -R that mirrors ssh -L (and I guess this is what you had in mind), but the form of ssh -R that mirrors ssh -D.

With ssh -R, if you (as a client) don't specify any address:port to forward to, then the SSH server will become a SOCKS proxy and it will be your computer who will connect to addresses requested by people using the proxy. It's like ssh -D but the other way around.

In case of ssh -D, whoever uses the proxy chooses address:port the SSH server shall connect to on their behalf. The admin of the server may want to limit this, PermitOpen is the way. In case of ssh -R acting as a SOCKS proxy, similarly whoever uses the proxy chooses address:port the SSH client application shall connect to on their behalf. As a client you may want to limit this because in general these address:ports are not necessarily (in practice: never) your choice, but it's your ssh connecting to them. You can use PermitRemoteOpen in your ~/.ssh/config. This is the option to limit ssh -R, but it only works when ssh -R creates a SOCKS proxy on the server.

Summary

  • PermitOpen in sshd_config on SSH server limits ssh -L (and ssh -D, ssh -W, ssh -J). PermitRemoteOpen in ssh_config (or ~/.ssh/config) on a client's side limits ssh -R.

  • Each option is governed by the person whose application will eventually initiate connections: the admin of the server (owning sshd) and the client (running ssh) respectively. Limiting ssh -R by the admin of the server would be futile.

  • Each option works in cases where the governing person is not the person who chooses address:port for the application to connect to. For PermitOpen all cases are like this. For PermitRemoteOpen only ssh -R creating a SOCKS proxy on the server is like this.

  • Limiting ssh -R of other types by the client makes no sense (the client would limit himself) and there is no option for it.

Kamil Maciorowski
  • 81,893