

Why is ssh insecure by default?  [AllowTcpForwarding] - xtat
http://kitenet.net/~joey/blog/entry/ssh_port_forwarding/

======
jey
I don't think it's a bug to assume that ssh is normally used with shell
accounts. If you can run a shell on the server, you can open TCP ports. Sure,
you could argue that defaults should be set to the most security-paranoid
values, but that's really not common practice in any project. Yes, the
sysadmin should go through the SSH config file, and not just use the defaults
that come with the sshd.

~~~
thaumaturgy
I've set up authpf for a couple of clients that want remote access to internal
systems without exposing those systems to the outside.

So, in that particular example, ssh port forwarding by default is not desired
behavior, because the user isn't granted a full shell for authpf. However,
they're considered "trusted" users, so it's not a security problem from a
practical standpoint.

However, if I were running a similar service, but more broadly, for
"untrusted" users ... then it would be a problem.

While someone might argue then that as a sysadmin I should examine the default
settings and modify them according to the needs at hand -- and I would agree
-- I could also argue the reverse: that argument is equally valid for
disabling ssh port forwarding by default.

In the end, as with most defaults for security-sensitive systems, it should
come down to expected behavior. That is, someone who needs ssh port forwarding
will know they need it, and can go looking for that particular knob to turn.
However, someone who _doesn't_ know about ssh port forwarding should not be
expected to go looking for it and disable it in order to not get caught by
surprise later on.

It should be disabled by default.

------
jrockway
Github appears to handle this correctly

    
    
        $ ssh -L 1234:irc.perl.org:6667 git@github.com -N
        channel 2: open failed: administratively prohibited: open failed
        ^C
    

But anyway, this is not a huge deal. It is only available to vetted users
(those with git/cvs/whatever accounts), and that "Unauthorized use is
prohibited" banners that show up when you log in should cover the server
admin's ass when someone does something illegal. It is no more "a threat" than
an open wireless access point.

~~~
antonovka
What's the point of declaring "this is not a huge deal"? This, like an open
wireless access point, _can be_ very huge deal depending on the
network/organization in question.

Moreover, a "vetted" user is any user that has acquired a vetted user's SSH
keys or password. With individuals regularly SSH'ing from remote, compromised
machines, this happens all surprisingly often.

~~~
jrockway
All I'm saying is that the world is not coming to an end. Yeah, people can
send spam or something. So keep it turned off. But the sky is not falling.

~~~
antonovka
_All I'm saying is that the world is not coming to an end._

I never realized the issue existed when I've used command-limited SSH, and I
should know better. The OpenBSD developers and administrators should _really_
know better.

I'm actually embarrassed that I didn't recognize the issue, and I'm glad
someone noted it publicly so I won't repeat the mistake.

 _Yeah, people can send spam or something._

[http://openbsd.org:8080/pub/OpenBSD/OpenSSH/openssh-5.2.tar....](http://openbsd.org:8080/pub/OpenBSD/OpenSSH/openssh-5.2.tar.gz)

Are the contents of that URL trustable?

What about bypassing firewall restrictions?

 _So keep it turned off. But the sky is not falling._

Who said it was?

~~~
ars
You can do a lot more than that with CVS access. CVS is not secure. If you
have write access to the ADMIN directory you can run arbitrary programs via
CVS.

And if you have no write access, then what is the point of running it via ssh
anyway? BTW giving someone write access to CVS without also access to ADMIN is
a lot harder than it looks.

Running restricted account via SSH is not very common, while shell account via
SSH is, so in that light the default is correct. It is really really hard to
properly secure a restricted access account. So if you are going to do it,
it's your job to do it properly.

------
humbledrone
Allowing TCP forwarding by default is not "insecure." The author of the
article states that the SSH manual's justification for leaving it enabled by
default is not valid because, "have you ever tried to install a forwarder on
some random shell account?" Well, doing so would be trivially easy.

~~~
joeyh
You read the article.. but apparently only one throwaway line and not the
actual meat. Good try tho.

~~~
oomkiller
You are somewhat right here, it should probably be disabled by default, but I
believe you're misinterpreting what the docs say.

    
    
      AllowTcpForwarding
            Specifies whether TCP forwarding is permitted.
            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.
    

Basically this says, disabling TCP forwarding doesn't add any real security
UNLESS your users don't have shell access. This is not a throwaway statment
because many SSH accounts do not have shell access. For example, my Rsync.net
backup account allows me to access it over ssh, but I can only run
predetermined commands, that are deemed safe by the sysadmin (ls, cp, mv, etc,
AND in a jail). So in this case disabling it WOULD add security, since I don't
have real shell access. Also, it is quite easy to install a tcp forwarder as
long as you have some access to any real language interpreter.

At my university, they throttled speeds for the residential network, so I
compiled a simple java socks proxy and ran it on one of their servers that I
had student access to, which allowed me to bypass the speed restriction. Hell,
if you wanted to, you could cook something up with bash and netcat. To
summarize, this is a great feature to have, and also one I use often. At most,
it should be disabled by default, but in most cases it won't matter since
people who can use it usually have shells too.

And really, this is what sysadmins get paid to do!

------
halo
For some definition of "insecure", when you happen to use OpenSSH for a
relatively uncommon use-case, with the end result of disabling functionality
which is useful for many legitimate users in the common use-case.

------
frou
Does anyone have a link for a guide on how to set up sshd in the most secure
fashion? (i.e. the contents of the sshd_config file)

------
est
This article reminds me of typical Linux tutorials in China, often there's a
post on some Web-based forum, type command X, type command Y, and your server
is up. In one particular thread on how to setup vsftpd, someone replied 'my
server ftp.xyz.com is working fine', I tried SSH to ftp.xyz.com with the _ftp_
account and it works. I don't know how many other Linux step-by-step tutorials
are flawed that way.

> And if the reader is in China -- hey, this is a great way to get around the
> Great Firewall ...

Yeah there's lot of ssh scanner going on in China

------
tptacek
SSH port forwarding is used EXTENSIVELY in enterprises to provide mutually
authenticated secure tunnels for services that either don't do SSL, or don't
do it correctly. Smart security teams won't allow SSH or SFTP through their
perimeters because of things like this, but default disabling port forwarding
would probably break more things than it would fix.

The real issue here is that people are casual about giving SSH accounts
(limited or otherwise) to strangers. That's a mistake.

~~~
lallysingh
What'd be useful is a mode of sshd designed specifically for limited-access
cases like CVS.

------
afuchs
SFTP/SCP and other applications that use SSH for transport encryption work by
invoking commands once they have a shell on a remote machine. (A user can be
given a shell that limits the commands they can execute to only those needed
for such services.)

The problem occurs when an admin does not know what the daemon they are
running on their machine does. The article is placing blame on the SSH daemon
maintainers for making it easy to run their daemon in a way that exposes
features that the admin would not want to knowingly expose.

So blame could be placed on: * the admins who unintentional leave their
machines using such configurations * the developers of services which function
over SSH, for using a design that makes it easy for an admin to
unintentionally use such configurations. * the developers of the SSH daemon
for not designing their software to prevent misconfiguration when it is used
to encrypt the communication of other services

[excuse me if I sound hostile, I've had a fairly bad day]

~~~
afuchs
Looking at various docs, I'm not certain that SFTP functions in the same way
as SCP/etc. [have to look at this in more depth at another time]

------
JeremyChase
I would suspect most typical systems do not have ssh authenticated users users
who can not get to a login shell. If you are making accounts like this I think
you should have a firm enough grasp on systems administration to avoid this
problem.

------
thras
This article is silly. You can't grab low ports without root. This setting
does nothing because users have privileges to grab high ports anyway. For
example, they can write simple scripts to listen instead of using SSH for it.

On the other hand, SSH forwarding is extremely useful and serves as a nice
alternative to VPN when you need it.

~~~
wmf
Maybe you didn't read carefully enough. Users _who don't have shell access_
probably should not be able to proxy traffic through the server, but OpenSSH
allows it by default.

~~~
thras
But you have to set that sort of user account up specially, at which time you
can disable tcp forwarding. What he wants to change is the sshd default.

~~~
lallysingh
I agree with the poster.

There are two situations:

1) Nonshell use only -- you want port forwarding turned off. Unless you're
using the machine as a proxy, it's just waiting to be used as part of a larger
hack scheme.

2) Shell use only -- Normal logging in and shell use doesn't necessitate port
forwarding. The only time it is generally useful is for forwarding X11 back to
the client, but frankly that's not nearly as useful as it was 10 years ago. If
you've got an X install on your server, and an X server on your client, then
you're in a sufficiently-select subset of the user population to have to turn
on one config option in sshd_config.

In either case, I think it should be turned off by default.

------
smithjchris
Idiot. Wait for Theo to comment on this one. It's surely be a laugh.

~~~
joeyh
So, Theo was told around 1999 that the OpenBSD cvs server allowed port
forwarding. And then told again, in 2002, by someone else, in a message sent
to bugtraq
([http://marc.info/?l=bugtraq&m=109413637313484&w=2](http://marc.info/?l=bugtraq&m=109413637313484&w=2)),
about the same problem, and apparently fixed it at that time. And yet in 2009
at least 3 of the OpenBSD cvs servers once _again_ have the same problem.

I assume you're not calling me the idiot? -- Joey Hess

~~~
there
_And then told again, in 2002, by someone else, in a message sent to bugtraq,
about the same problem, and apparently fixed it at that time._

that bugtraq message says "OpenBSD cvs servers", as in, the anoncvs mirrors
that are setup by volunteers, many of whom are not openbsd developers. we
don't control any of those servers. an email was sent out to all of the mirror
maintainers years ago telling them that they should probably disable the
forwarding if they didn't know it was on.

 _And yet in 2009 at least 3 of the OpenBSD cvs servers once again have the
same problem._

the list of mirrors is updated constantly (<http://www.openbsd.org/cgi-
bin/cvsweb/www/build/mirrors.dat>). old mirrors drop off, new ones come on. if
new ones are allowing tcp forwarding for anoncvs and they aren't aware of it,
email them. clearly it bothers you more than it bothers any of us.

