22

I have a server running Ubuntu and the OpenSSH daemon. Let's call it S1.

I use this server from client machines (let's call one of them C1) to do an SSH reverse tunnel by using remote port forwarding, eg :

ssh -R 1234:localhost:23 login@S1

On S1, I use the default sshd_config file. From what I can see, anyone having the right credentials {login,pwd} on S1 can log into S1 and either do remote port forwarding and local port forwarding. Such credentials could be a certificate in the future, so in my understanding anyone grabbing the certificate can log into S1 from anywhere else (not necessarily C1) and hence create local port forwardings.

To me, allowing local port forwarding is too dangerous, since it allows to create some kind of public proxy. I'm looking for a way tto disable only -L forwardings.

I tried the following, but this disables both local and remote forwarding :

AllowTcpForwarding No

I also tried the following, this will only allow -L to SX:1. It's better than nothing, but still not what I need, which is a "none" option.

PermitOpen SX:1

So I'm wondering if there is a way, so that I can forbid all local port forwards to write something like :

PermitOpen none:none

Is the following a nice idea ?

PermitOpen localhost:1
3
  • so, as always, lets get to the root of this: what is your real problem, why do you want to setup something like this for mobile /embedded devices, what do you want to solve?
    – akira
    Jan 6, 2011 at 10:44
  • The problem to be solved here is to be able to open a Telnet session, anywhere from the Internet, to a mobile/embedded device connected to the Internet, taking into account that the device might be NATed, or firewall'd, hence not reachable from the Internet.
    – SCO
    Jan 6, 2011 at 12:58
  • telnet .. what for? for punching holes into firewall google for 'stun'
    – akira
    Jan 6, 2011 at 22:11

5 Answers 5

19

anyone with login credentials can bring up their own instance of sshd, running on a random port and allow whatever they want, including -L local forwardings:

% /usr/sbin/sshd -d -f mysshd.config -p 12345

if you do not trust the users to do something with your machine then you shouldnt allow them to login in the first place.

(btw, the -D flag is kind of "proxy-problematic" as well)

7
  • Well I guess I can setup a very restrictive account for this purpose (eg. stick the user to its home, no listing, no filesystem browsing), so that it can not start and sshd (or install and start an sshd binary). The point is that the clients are supposed to be embedded devices. But since they will probably embedded certificates and their flash memoery can be dumped, it's possible the certificates will leak, hence allowing anyone to login to S1.
    – SCO
    Jan 6, 2011 at 9:56
  • Using ChrootDirectory for that particular user will do the trick, will try that !
    – SCO
    Jan 10, 2011 at 16:43
  • 1
    In authorized_keys, set command="/sbin/nologin". This should prevent them from running any commands on the server.
    – justis
    Jul 31, 2012 at 15:15
  • 4
    The statement "anyone with login credentials can bring up their own <whatever>" is false. ssh can be used to connect to accounts which have severely restricted login shells that do not allow this. Port forwarding is a security hole in such restricted shells. In addition to running a permitted command, the user can create tunnels.
    – Kaz
    Dec 7, 2012 at 20:08
  • 7
    Quote from sshd_config man page: Note that disabling TCP forwarding doesn't improve security unless users are also denied shell access, as they can always install their own forwarders. (Emphasis mine).
    – Kaz
    Dec 7, 2012 at 21:33
20

Another solution would be to only allow port forwarding to specififc users:

From SSH: The definitive guide

Port forwarding can be globally enabled or disabled in sshd. This is done with the serverwide configuration keyword AllowTcpForwarding in /etc/sshd_config. The keyword may have the value yes (the default, enabling forwarding) or no (disabling forwarding):

# SSH1, SSH2, OpenSSH
AllowTcpForwarding no

In addition, SSH2 has the following options:

# SSH2 only
AllowTcpForwardingForUsers
AllowTcpForwardingForGroups

The syntax of these is the same as for the AllowUsers and AllowGroups options. [Section 5.5.2.1, "Account access control"] They specify a list of users or groups that are allowed to use port forwarding; the server refuses to honor port forwarding requests for anyone else. Note that these refer to the target account of the SSH session, not the client username (which is often not known).

...

It's important to realize that the directives in this section don't actually prevent port forwarding, unless you also disable interactive logins and restrict what programs may be run on the remote side. Otherwise, knowledgeable users can simply run their own port-forwarding application over the SSH session. These settings alone might be a sufficient deterrent in a nontechnical community, but they won't stop someone who knows what she's doing.

4
  • 1
    Basically I'll have only one user provisionned on S1. AFAIU, in this specific case, using AllowTcpForwardingForUsers/AllowTcpForwardingForGroups will not do the trick, right ? Forbidding interactive login is a good idea since it will make users not be able to start binaries. But any client will still be allowed to by using -L syntax right ? So for now, the best options would be : 1/ Disable interactive login, 2/ PermitOpen with a fake hostname:port. Did I miss something ?
    – SCO
    Jan 6, 2011 at 10:10
  • The best way to verify this, would be to try the setup.
    – Christian
    Jan 6, 2011 at 12:36
  • I cannot see these options in the free OpenSSH software. A google for AllowTcpForwardingForUsers reveals that it's configured in an sshd2_config, which is used in some commercial programs. See one of the answers to: superuser.com/questions/384643/…
    – Kaz
    Dec 7, 2012 at 21:53
  • ^ OpenSSH has Match blocks in the configuration. You can Match on users and groups, and enclose the AllowTcpForwarding within.
    – Kaz
    Dec 7, 2012 at 22:46
6

There is now an option to allow only local / remote forwarding.

AllowTcpForwarding

Specifies whether TCP forwarding is permitted. The available options are “yes” or “all” to allow TCP forwarding, “no” to prevent all TCP forwarding, “local” to allow local (from the perspective of ssh(1)) forwarding only or “remote” to allow remote forwarding only. The default is “yes”. Note that disabling TCP forwarding does not improve security unless users are also denied shell access, as they can always install their own forwarders.

So, as stated already you should set the shell to nologin, too.

1

My solution to this problem was to add: PermitOpen fo.local:80 in the main section of the sshd_config.

This simply denies any request of local forwarding besides fo.local:80.

0

I'm looking for a way tto disable only -L forwardings

If I understand you correctly, your users have full shell access, but you don't want them to be able to open connections towards the rest of the net.

The "local port forwarding" allowed by SSH is just one of the possible ways to do that. Others include launching an instance of socat, netcat, or any other number of tools.

The best way to control outgoing as well as incoming connections in Linux is Netfilter, aka IPTables.

It has a special module called owner (ipt_owner) which allows you to match various characteristics of the packet creator, for locally generated packets. It is valid in the OUTPUT and POSTROUTING chains.

You can use it to deny outgoing packets generated by certain groups of users, thus disallowing any kind of port forwarding, not just the -L option of SSH.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .