3 ms·

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

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 17y ago
You read the article.. but apparently only one throwaway line and not the actual meat. Good try tho.
- oomkiller 17y ago
  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!
- humbledrone 17y ago
  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."
antonovka 17y ago
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.
- humbledrone 17y ago
  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.
  - antonovka 17y ago
    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".

joeyh 17y ago

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

oomkiller 17y ago
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!
humbledrone 17y ago
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."

antonovka 17y ago

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.

humbledrone 17y ago
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.
- antonovka 17y ago
  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".