Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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
share|improve this question
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 '11 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 '11 at 12:58
telnet .. what for? for punching holes into firewall google for 'stun' –  akira Jan 6 '11 at 22:11
add comment

2 Answers

up vote 8 down vote accepted

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)

share|improve this answer
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 '11 at 9:56
Using ChrootDirectory for that particular user will do the trick, will try that ! –  SCO Jan 10 '11 at 16:43
In authorized_keys, set command="/sbin/nologin". This should prevent them from running any commands on the server. –  justis Jul 31 '12 at 15:15
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 '12 at 20:08
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 '12 at 21:33
add comment

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

The syntax of these is the same as for the AllowUsers and AllowGroups options. [Section, "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.

share|improve this answer
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 '11 at 10:10
The best way to verify this, would be to try the setup. –  Christian Jan 6 '11 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 '12 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 '12 at 22:46
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.