Forgot your password?
typodupeerror
Privacy Security Your Rights Online

Lax SSH Key Management A "Big Problem" 212

Posted by Unknown Lamer
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."
This discussion has been archived. No new comments can be posted.

Lax SSH Key Management A "Big Problem"

Comments Filter:
  • by Smallpond (221300) on Wednesday December 26, 2012 @12:20PM (#42395153) Homepage Journal

    I've just noticed a huge vulnerability in keyless entry on cars - you can open the door without a key!

    ** just so we don't have a story without a car analogy **

    • Re: (Score:2, Offtopic)

      by paiute (550198)
      I just learned you can gain access to the Library of Congress without being a Congressman.
    • by Sulphur (1548251)

      I've just noticed a huge vulnerability in keyless entry on cars - you can open the door without a key!

      ** just so we don't have a story without a car analogy **

      You can get in some convertibles without opening the door even if the windows are up.

      --

  • by datapharmer (1099455) on Wednesday December 26, 2012 @12:22PM (#42395187) Homepage
    Who exactly is it that isn't password protecting their ssh keys? I mean if you choose to press enter shame on you.
    • by Skinkie (815924)
      Most likely your offline backup script that rsyncs your changes over every night with you sleeping tight.
      • by kthreadd (1558445) on Wednesday December 26, 2012 @12:39PM (#42395373)
        Then I would create a separate key for that service and restrict what it was allowed to do on remote end.
        • by h4rr4r (612664)

          That is what you should do.
          I use rssh for something like this all the time and each process has it own user. That takes planning though and people are lazy.

        • Exactly! chroot it, limit ssh by IP and run a second script on the server to do any additional housekeeping (move files/change permissions as necessary and cleanup). You shouldn't allow an unprotected key for an account with access to anything of value on your server. Being lazy isn't an excuse. You can be lazy and maintain security, it just takes a few extra minutes to set it up correctly the first time.
          • by Anonymous Coward on Wednesday December 26, 2012 @02:04PM (#42396289)

            I always run my backup scripts in chroot environments. I've also found that, as a bonus, they complete many orders of magnitude faster and use significantly less space. Huge wins all around.

        1. If this is for desktop use, it asks ssh-agent. If it cannot do that, oh well, the backup did not happen and hopefully I see an error message in the morning.
        2. If this is for something more general, it is a service that is confined in any number of ways (SELinux would be my preference).

        ...and on the remote end, whatever the backup script logs in as is confined -- no permissions to do anything other than write a backup.

    • by sribe (304414) on Wednesday December 26, 2012 @12:31PM (#42395283)

      Who exactly is it that isn't password protecting their ssh keys?

      Anyone who needs services to launch without manual intervention--which is a whole lot of services and a whole lot of people...

      • by h4rr4r (612664)

        Which is why we have things like chroot and rssh. Limiting the scope of the damage is a vital practice with those kinds of accounts.

        • by sribe (304414)

          Which is why we have things like chroot and rssh. Limiting the scope of the damage is a vital practice with those kinds of accounts.

          Yep. And more directly related to the article--not being a dipshit idiot about the key files ;-)

    • by X.25 (255792)

      Who exactly is it that isn't password protecting their ssh keys? I mean if you choose to press enter shame on you.

      It appears that you haven't seen any workplace yet.

    • by gmack (197796) <gmack@@@innerfire...net> on Wednesday December 26, 2012 @02:36PM (#42396581) Homepage Journal

      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.

    • by Khopesh (112447)

      Who exactly is it that isn't password protecting their ssh keys? I mean if you choose to press enter shame on you.

      From the IT policy standpoint, there's no way of requiring that a key has a password. There are lots of people who don't understand (or otherwise care to use) ssh-agent and similar mechanisms, and there are lots of people who assUme that their own systems' security is sufficient and don't realize that it jeopardizes the security of the IT department's systems.

      For this reason, there are lots of security-conscious departments that ban SSH key access on any external-facing system.

      • For this reason, there are lots of security-conscious departments that ban SSH key access on any external-facing system.

        So what your telling me is that they decided that a password that said user probably wrote on a sticky-note attached to their laptop or saved in a plaintext password is more secure than a ssh private key that MIGHT not be password protected?

        If a user isn't going to properly secure an ssh private key, there is no way in hell they are going to properly protect a password!

    • Be aware that there is a reason that ssh asks for a "passphrase". Encyrption passwords must have much more entropy than login passwords because the only thing restricting the number of attempts the attacker may make is the amount of computing power the attacker has at their disposal.

      I bet there are a lot of ssh keys out there with passwords that ammount to nothing more than a false sense of security.

  • Unmanaged keys are most certainly a pretty serious security vulnerability, and I agree - in my experience it is endemic.

    Key management - signing, validation, revocation - doesn't happen for free. Everything worthwhile requires effort.

    • by betterunixthanunix (980855) on Wednesday December 26, 2012 @12:39PM (#42395371)
      I see brute force attacks on passwords all the time; you do not see that with keys. Yes, if you are dealing with an adversary who is organized, well-funded, and specifically attacking you, you should be taking extra precautions with keys (and with many other things), but for most SSH use-cases the adversary is just trying to find the least secure system anywhere on the net, and does not care who owns it.

      So rather than scare people about poor key management, let's scare people about bad passwords -- which is nearly all passwords.
      • by vlm (69642) on Wednesday December 26, 2012 @12:45PM (#42395427)

        So rather than scare people about poor key management, let's scare people about bad passwords -- which is nearly all passwords.

        Hey slashdot does anyone have an implementation where the sshd config would look something like:

        PubkeyAuthentication yes
        PasswordAuthentication no any/any
        PasswordAuthentication yes 10.0.0.0/8

        And no, last time I checked openssh could not do that. Either yes or no, no src address filtering.

        The closest I could come up with is running two SSH servers on different port numbers and filter at the network level which src addrs can talk to which port.

        • by allo (1728082)

          why would you want passwords in your lan?
          when you need passwords sometimes, when you are on the road with your laptop or at some pc, which is not yours, okay there its useful. But in you own lan, you always can access some ssh-key. So your policy isn't very useful that way.

          • by vlm (69642)

            (years ago) I used to get blasted at home from China IP addrs trying various root passwords. Flooding my logs with failures. Since then I only allow key auth from the untrustable internet. I'd never allow password auth over the internet. Copying a key is not a big deal. Or logging into another machine that I know has a key, etc.

            On the LAN, if some clown gets infected and port scanning / password scanning, I can literally walk over and physically take care of it.

            • by Maow (620678) on Wednesday December 26, 2012 @02:50PM (#42396719) Journal

              (years ago) I used to get blasted at home from China IP addrs trying various root passwords. Flooding my logs with failures. Since then I only allow key auth from the untrustable internet. I'd never allow password auth over the internet. Copying a key is not a big deal. Or logging into another machine that I know has a key, etc.

              On the LAN, if some clown gets infected and port scanning / password scanning, I can literally walk over and physically take care of it.

              This may not be of use to you anymore, but I'll toss it out there: fail2ban.

              I use it to ban IPs attempting ssh-as-root on first attempt, ssh login password failures on 3rd attempt. Uses iptables to block the malicious addresses. Works like a charm.

              Also has "jails" for Apache-based log failures, such as attempts to access PHPMyAdmin (what ever it's called), which is worthwhile to run just for that, and a host of others.

            • by nedlohs (1335013)

              If copying a key is not a big deal why do you want password authentication enabled for lan?

          • why would you want passwords in your lan? when you need passwords sometimes, when you are on the road with your laptop or at some pc, which is not yours, okay there its useful. But in you own lan, you always can access some ssh-key. So your policy isn't very useful that way.

            When I first started my current job, we could only login to one server by using an SSH Key. However, you were expected to generate your own key and put in on the server. The only method was to use the insecure FTP (where passwords were allowed) to upload a new authorized_keys file.

            A couple years later, the hard disk failed and we had to rebuild the server. Needless to say, the SSH Key requirement did not get transferred. (And no, I'm not the admin; if I were It might get reinstated for logins from the ou

            • by allo (1728082)

              i think (good) password vs. ssh-keys is both okay from the security point of view. But ssh-keys have much more convenience, where you have them (with ssh-agent you type your password only once, agent forwarding, etc.), and passwords are a sane fallback for when you just somewhere and downloaded putty to access your server. another good option for not so trustworthy environments are one-time-passwords. There is a pam module for this, and you just carry a list of 100 OTPs.

              • i think (good) password vs. ssh-keys is both okay from the security point of view. But ssh-keys have much more convenience, where you have them (with ssh-agent you type your password only once, agent forwarding, etc.), and passwords are a sane fallback for when you just somewhere and downloaded putty to access your server. another good option for not so trustworthy environments are one-time-passwords. There is a pam module for this, and you just carry a list of 100 OTPs.

                Any links for that PAM module? Or how the 100 OTP list would work?

                • by heypete (60671)

                  I'm not sure about that specific module, but I've found using the Google Authenticator [google.com] pam module to be really useful. It ties in easily with SSH and allows users to use time-varying OTPs generated using the TOTP standard to authenticate to the system.

                  It's worth pointing out that although the module is developed by Google, it does not rely on nor communicate with their servers in any way: it's just an implementation of the TOTP standard. One can use their Google Authenticator client for iOS/Android or any o

                • by allo (1728082)

                  its called libpam-opie. There are debian packages, and googling finds some howtos. I'm not sure which to link, because some apply on freebsd, others are written in german ... so search for yourself which one works for you.
                  In the end you get prompted with a seed ((almost) constant per account) and a serial number, and can generate the corrsponding OTP (a sequence of some english words) or use a list of precomputed OTPs.

            • Wait, so new admins were required to use FTP to add their public key instead of just getting an exist admin to add it for them?
              • Well, no new admin. New users. The only admin setup the FTP account; I don't know why they just didn't generate a publickey pair at the same time to hand out.
        • by Qzukk (229616) on Wednesday December 26, 2012 @01:07PM (#42395673) Journal

          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

        • by Sancho (17056)

          You should be able to approximate that using Match keywords in sshd_config.

        • by ArsonSmith (13997)

          xinetd can. we launch a separate sshd with separate config file from xinetd with response from only certain ip addresses.

        • by shaiay (21101) on Wednesday December 26, 2012 @01:27PM (#42395909)

          use the Match config file directive:

          PubkeyAuthentication yes
          PasswordAuthentication no
          Match Address 10.0.0.0/8
          PasswordAuthentication yes

      • by Shavano (2541114)
        I find it a useful thought exercise to presume that my computers are under specific, directed attack even though they probably aren't.
        • I wish more people thought like you do. I protect all hosts like they were real assets or potential vectors for local 10./ infection.

          Because they are. Pubic facing? Secure perimeters? False security.

  • Your keys, my keys (Score:5, Insightful)

    by kthreadd (1558445) on Wednesday December 26, 2012 @12:29PM (#42395265)

    I've worked at a place where someone thought it was a great idea to mass-add a specific entry everyones authorized_keys, "because then $x would just work". No need to tell everyone of course.

    It's not enoguh that you know how to manage your keys. The rest of the organization has to know what's OK and not.

    • by vlm (69642)

      Would have been a lot funnier if they did

      cat somekey > ~/.ssh/authorized_keys

      rather than

      cat somekey >> ~/.ssh/authorized_keys

      I suppose that is one way to "solve" the problem.

      • by kthreadd (1558445)

        Turned out someone had a cron job that checked certain files for modifications, including authorized_keys. So it was detected fairly quickly.

        With great power comes great responsibility, or whatever it is that sudo sais the first time you run it.

    • by richlv (778496)

      just fyi, i found your comment somewhat confusing - probably because of a word you left out :)

      i'd guess "entry everyones authorized_keys" should have been something like "entry into everyone's authorized_keys", which then starts to make some sense

      • by kthreadd (1558445)
        Correct. The absence of edit functionality is sometimes a bit irritating. Thanks for pointing it out. :-)
  • His name is (Score:5, Informative)

    by LucidBeast (601749) on Wednesday December 26, 2012 @12:31PM (#42395285)
    Tatu Ylönen
  • by linuxtelephony (141049) on Wednesday December 26, 2012 @12:36PM (#42395339) Homepage

    The biggest issue with SSH is the inability of the server to enforce policy on the client keys. If I'm wrong, I'd love to be corrected and learn what I've been overlooking.

    As it stands, there's no way for the server to reject a key that has no pass phrase, a poor passphrase, or an old pass phrase. Short of over-the-shoulder random audits of users using their keys, there's no way to enforce a policy that sets minimum standards for pass phrases on SSH keys.

    To my way of thinking that is one of the bigger areas of risk with and drawbacks of the use of SSH.

    • by h4rr4r (612664)

      If you are that worried about it you could disable the use of ssh keys. No one is going to be guessing the keys anyway, but it is a concern if someone copied one.

    • by vlm (69642) on Wednesday December 26, 2012 @12:52PM (#42395517)

      Its a mess. In more detail.

      The pass phrase never leaves the client, right, so you'd have to magically protect against trojaned client that lies and pinky swears that it really did check.

      Or send the passphrase cleartext to the server for the server to test it. That would be bad. Of course if you had a trustable connection between, then you could safely transfer the passphrase to the server for testing, but then you'd already trust the link so it would be pointless.

      The solution is after you set up the trusted link you send the passphrase over the link and have the server verify the phrase and dump the connection if it fails.

      There's probably some horrible failure mode where if a server is owned then you're really screwed because now it has your passphrase which is probably your gmail password and xbox password and who knows what else.

      Kerberos does it (somewhat) better.

      • by Khopesh (112447)

        There are two (very ugly) "secure" solutions to this.

        1. Draconian: The IT department requests the private key, tries to brute force access, then deletes it after a certain degree of failure. IIRC, pubkeys can be generated from private keys without passwords, so it's verifiable. Big snag: the user could remove the password later. As long as the private key is safely and securely submitted (say via an SSL form) and safely/securely stored during the brute forcing, this is as secure as your trust in the s

      • by dkf (304284)

        Kerberos does it (somewhat) better.

        But Kerberos management is itself a PITA. I suppose it's not too bad within the context of a single organization, but it can't scale larger than that because of cross-domain trust problems. (Large organizations often internally organize themselves into multiple smaller organizations that are usually at loggerheads with each other over something stupid. Or the budget allocation.)

        It's important to remember that the main problem with SSH is that it allows authentication via password by default. That's by far t

    • That's because the server has no way of knowing anything about the passphrase unless the client tells it, and no way of knowing if the client is telling the truth, so it would be foolish to include such verification.

    • As it stands, there's no way for the server to reject a key that has no pass phrase, a poor passphrase, or an old pass phrase

      There is, however, a way for the server to accept only particular client keys -- say, keys that are known to have been generated on a smart card. SSH can be configured to look for authorized keys somewhere that users cannot write to (a basic centralized keystore), and there is some amount of support for a PKI. You cannot force users to have good passphrases, but you can force them to use smartcards (which is probably better than a passphrase anyway).

      • How does the server know the key came from a smartcard?

        • When the smartcard is given a public/private key pair, it registers the public key with a basic centralized keystore. Then the ssh server starts refusing key authentication with any client not trying to authenticate against one of the public keys generated by the smartcard setup process.

        • You are the one issuing the smartcards. When someone needs access to the server, you either give them a smartcard and add the card's public key to the authorized_keys file. In theory, the smartcard cannot export its secret keys, so you know that only a person who possesses the card and correctly entered the pin could be using that key to log in (in practice, smartcards can sometimes back up keys; I would assume that if you need to control client keys, you would not be issuing such cards).
    • This is basically the heart of the issue. Allowing users to add whatever keys they want (their uncle? Their best "friend" in Russia?) to their own user accounts circumvents the traditional authentication/authorization methods. When employees leave, occasionally their accounts stick around while things get cleaned up (or if they were especially bad and running production jobs out of their home account, they just stick around forever) their /etc/secrets entry gets a * for a password hash immediately but it
      • .ssh/authorized_keys is only writable by the user if you decide it should be. "chown root:root /home//.ssh/authorized_keys; chmod 755 /home//.ssh/authorized_keys" and voila, only root can update your authorized_keys file. Another solution is to change the location of the authorized_keys files in /etc/ssh/sshd_config (or wherever your distro stores the settings) to something outside their home folder.
    • by nedlohs (1335013) on Wednesday December 26, 2012 @03:01PM (#42396819)

      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".

  • by geekboybt (866398) on Wednesday December 26, 2012 @01:35PM (#42395991)

    Managing SSH keys for known service accounts is easy with configuration management tools like Puppet, Chef, or Salt.

  • It's not perfect, but - if you restrict where it (ostensibly) can connect from, and you restrict it to a specific command, I wouldn't exactly consider it low-hanging fruit.

  • I got to the end and was thinking all my SSH keys require a password as well. Then I saw the tidbit of some dumbass had one that was passwordless, read epic fail.
  • The SSH design of how keys are actually handled is part of the problem. This design makes things harder for key management. The first is that the ssh daemon wants to only look at one file. It should provide for a way to keep the files separate so it is not necessary to rebuild the authorized_keys file. Have a directory where keys can be stored with multiple keys per file. Provide an option to allow the user to configure which key files are active (choose whether not executable or not world readable is

  • Stop authenticating users via keys directly to a server. Use Kerberos v5. This centralizes the authentication to one or a set of servers. You then don't need to clean up key mess everywhere. Once you're running Kerberos you can choose the method of authentication to the central server. You can use password, public key (but only one in this case), OPIE (One-time Passwords In Everything), Google authenticator, RSA securid, biometrics, SRP (Secure Remote Password), or any combination of these to make thin

Computers will not be perfected until they can compute how much more than the estimate the job will cost.

Working...