Slashdot Mirror

← Back to Stories (view on slashdot.org)

Overconfidence in SSH Protection

Posted by ryuzaki0 on from the don't-be-too-proud-of-this-technological-terror dept.

nitsudima writes to mention a post on the Informit site about the common misunderstandings surrounding SSH, and how well-intentioned admins may be creating holes in their own security by using it. From the article: "In UNIX, all things are files. To send network traffic, UNIX writes the traffic to the network device file. In this case, the connection to Box A (and that private key used for authentication) is a socket file. This file will shuttle the authentication traffic between Box A and Box P. So what's the risk? Maybe the hacker can't get a copy of the private key through the socket file, but something better (from his/her view) can be done. If the hacker has root on Box D, he or she can point a private copy of the agent forwarding software to that socket file and thereby point the authentication process to the administrator's credentials--the ones kept on the 'safe' intranet. What are the chances that the administrator has configured access to all the DMZ servers he controls?"

2 of 194 comments (clear)

  1. Re:Huh? What? by limegreen · · Score: 4, Interesting

    I think part of the article is trying to say that users can enable their own ssh tunnels to home, and thus if their home network is compromised there is an easy route into the office intranet.

  2. Re:Hopefully, a better summary... by flooey · · Score: 4, Interesting
    Administrators use SSH to run scripts (from server A) to patch other servers (B, etc). These scripts are automated and make use of credentials stored in server A to gain access to the other servers (B, etc.).

    If a hacker gains access to server A, he can then use the credentials to access the other servers.
    Actually, it was a little more complicated. The scenario is actually that administrators use SSH to run scripts on server A to patch server A using patches from server B. The trick is, without having credentials stored on server A, a hacker who compromised server A could still trick his way into getting server B to allow him to log in if someone was logged into server A and had agent forwarding turned on.

    It's not quite as straightforward of a duh moment (after all, server A on its own can't log into server B), it's basically just saying "when you log into a server and have agent forwarding turned on, you allow anyone with root access on that server to log into anywhere your agent can log into".