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.
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.
$ 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.
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.
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.
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.
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.
Allowing command-restricted users to trivially bypass firewalls by default is insecure.
Most individuals (myself included) don't realize that SVN over SSH with command-restricted SSH keys would allow the users unmitigated access to the SVN server's network. I should know better, but still have made the mistake.
Command-restricted users are NOT the SSH default. If the sysadmin is taking the trouble to restrict the user's privileges, they need to restrict forwarding as well. By the argument that you and others make, the SSH server should not allow ANY access at all by default -- the sysadmin should apparently have to enable everything explicitly.
Given the fact that the organization responsible for creating OpenSSH has -- on more than one occasion-- left their own servers susceptible to abuse due to SSH forwarding issues, it seems reasonable to assume that the default setting most likely to prevent abuse is "off".
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!
Actually, I read the full article and not "one throwaway line." The one line that I quoted is the crux of your argument against the implementor's decision to allow forwarding by default. Don't know what you mean by the "actual meat."
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.
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 ...
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.
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]
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.
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.
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.
Being flippant for a minute, if you want your users to have access to a box but not have a shell, a tool called "secure shell" may not be the wisest choice.
Setting the default to frankly crippling levels for the primary function of a tool to accommodate an edge case seems slightly backwards to me. Host firewalls and/or disabling the option seem to be an acceptable set of hardening tasks if that use case is relevant to you.
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.
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), 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
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.
I was just stating that Theo will undoubtably turn up with some hilarity. He will most likely end up whipping the anoncvs mirror administrators into shape.
I do agree with the article.
At the end of the day, it's about as bad as people who used to mess up their sendmail relaying a few years ago. It in no way affects the credibility of OpenBSD, which is how it is worded and discussed.
