Slashdot Mirror

← Back to Stories (view on slashdot.org)

Lax SSH Key Management A "Big Problem"

Posted by Unknown on from the we're-all-doomed dept.

cstacy writes "Tatu Yionen, inventor of SSH, says he feels 'a moral responsibility' to come out of retirement and warn that a 'little-noticed problem' could jeopardize the security of much of the world's confidential data. He is referring to the management (or lack thereof) of SSH keys (i.e. 'authorized_keys') files. He suggests that most organizations simply allow the SSH key files to be created, copied, accumulated, and abandoned, all over their network, making easy pickings for intruders to gain access. Do you think this is a widespread problem? How does your company manage SSH keys?" cstacy's summary here is accurate, but as charlesTheLurker notes, the article is a bit over the top: "The Washington Times claims that there's a huge vulnerability in ssh. It turns out that some reporter there has discovered that you can do passwordless login with the software, and has spun this into a story of a dangerous vulnerability. Sigh."

6 of 212 comments (clear)

  1. His name is by LucidBeast · · Score: 4, Informative

    Tatu Ylönen

  2. Re:Passwords are a worse vulnerability by Qzukk · · Score: 4, Informative

    And no, last time I checked openssh could not do that

    Last I checked, PasswordAuthentication is allowed inside a Match block, so

    PubkeyAuthentication yes
    PasswordAuthentication no
    Match Address 10.0.0.0/8
            PasswordAuthentication yes

    --
    If I have been able to see further than others, it is because I bought a pair of binoculars.
  3. Re:Passwords are a worse vulnerability by shaiay · · Score: 4, Informative

    use the Match config file directive:

    PubkeyAuthentication yes
    PasswordAuthentication no
    Match Address 10.0.0.0/8
    PasswordAuthentication yes

  4. Re:who is doing this? by gmack · · Score: 4, Informative

    It is not a matter of password protecting ssh keys, it is a matter of deleting obsolete keys from ~/.ssh/authorized_keys when they aren't used anymore. When someone quits or gets fired someone should be going through everything they have access to and removing the keys. They are remarkably easy to forget where they were put as well.

    After running my head into this problem one too many times I ended up creating a management system that rebuilds every copy of authorized_keys on each server.

  5. Re:Inability of server to enforce policy by nedlohs · · Score: 3, Informative

    Of course there isn't. The server doesn't see the passphrase and there'd be no point in trusting the client to tell you "oh yeah, there was a huge passphrase, I promise".

  6. Re:who is doing this? by nabsltd · · Score: 3, Informative

    I think you are trying to be funny and failed (also I think you are mixing up chroot and /dev/null)

    If you chroot, you can't see any files if the aren't in the chroot directory or below. So, if you want to back up /etc, your chroot better include /etc (either as the root or as a subdirectory).

    This is why the OP said the backup finished faster...because after the chroot, none of the files that needed to be backed up were visible.