I don't think I've mentioned this publically before, but I found a security
hole in OpenBSD in 1999. Ok, so it wasn't in the security-focused OS, but
just in their infrastructure. And it wasn't a very bad hole; it just
allowed doing things like IRCing with a openbsd.org address.

The hole was in their CVS over SSH
setup. They had forgotten to turn off port forwarding. I have a clear
memory of contacting them, probably on irc, and getting back a dismissive
response, but assuming they'd fix it.

So I was really suprised when, checking as I write this article, I found
the same hole still exists in one of their main CVS servers, as well as
more than one of their CVS mirrors. What this says about OpenBSD and
security is left to the reader. And if the reader is in China -- hey, this
is a great way to get around the Great Firewall ...

But I hadn't planned to poke at OpenBSD here. What I really want to think
about is why ssh, which is very security focused, has in one area had
an insecure default for over a decade. By default, if you can connect
to a ssh server, you can forward ports to and from that server (with the
-L and -R options). The sshd_config(5) man page says:

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.

Which is a pretty silly justification --
have you ever tried to install a forwarder on some random shell account?
Without pissing off the admin? ssh provides a much less obvious way to
do it, one the admin will probably never notice.

Anyway, the assumption is that if a user connects via ssh,
they get an unrestricted unix shell. But in many ssh setups, from
OpenBSD's CVS, to the Pro Git book's ssh setup,
to innumerable limited purpose ssh accounts, that's not true. The user
lacks a shell, but unless the administrator remembers to turn off
port forwarding, they retain the ability to bounce through the ssh server
to google, or an intranet, or whatever.

I wonder that percentage of people setting up restricted ssh accounts
forget to add "no-port-forwarding" to authorized_keys? It's hard
to tell because most such accounts are limited to a few people. You can't
scan the whole net for them. Still I've seen enough people get this wrong
that I wouldn't be suprised if it affects between 10% and 50% of restricted
ssh accounts.

Why did this feature get into ssh in the first place? I'm sure it was
inherited into the current OpenSSH from the original, proprietary ssh. Which
turns out to have been one of those programs where the "secure" in the name
has a certian amount to do with marketing. Note that the more recent
PermitTunnel option defaults to off. I doubt that AllowTcpForwarding
would be accepted into OpenSSH today with its current default.

Why does ssh still have this increasingly bad default? Well, partly because
it has indeed become increasingly bad over the years as ssh use for special
purpose things like git push has spread. (OpenBSD were fairly
far ahead of the curve using ssh for anonymous CVS in the 90's.) The frog
has been heating up for a while. In 2004 there was
CVE-2004-1653
about this, and today books are being published documenting insecure
configurations for legions of DVCS fans to copy. Boiling yet?

Another reason might be that any ssh admin you ask about this will swear
that they always remember to disable it. And a lot of them do, and that makes
them feel smart & superior, so why complain about it. And another reason,
of course, is that changing the default would break untold amounts of
weird stuff.

Ssh's main function is, as you mention, to connect to a shell. That it also can be configured to served to secure other protocols is secondary; and when you use it in that function it's your problem to secure it. With this in mind, it's obvious why port forwarding is enabled by default: all you have to do is

is X11forwarding more useful?
Is X11Forwarding more useful than generic TCP forwarding? You could, in principle, implement X11 forwarding on top of a forwarded TCP port, I think it would be harder to implement generic TCP forwarding on top of X11 or other application specific protocol forwarding.
Comment by
jmtd [livejournal.com]
— early Monday morning, August 10th, 2009

However, I can conveniently view any file on a host by running "ssh host cat $FILE". By your reasoning, it would be acceptable for ssh to get an option that cats a file on the host at connect time, and enable it by default. Anyone using ssh for "another protocol" (or just with a restricted shell) would then have to remember to disable that "feature".

How exactly is that "insecure"? It just allows somebody with shell access to be able to bounce from there to elsewhere in the network... But if they have shell access, they're already capable of getting in the network. Why make it a step more difficult to run some program on the shell to do the same thing?

It defaults to "yes" because it's incredibly convenient, and because it is not an actual threat to "security", since it doesn't allow anything that can't be allowed through some other means.

Your analogy to the 'cat' command makes no sense. It's not something that is often done. If it was, then yeah, it should be built in for performance reasons.