4

I'm setting up git in a corporate environment. Git operations will be primarily though SSH using a single account with SSH keys used for access control. (http will be used for account configuration, web-based code browsing but little else.)

But the idea of having SSH keys that never expire sounds foolish to me. It would just take one compromised desktop to leak a private key and an intruder would have access to our intellectual property in perpetuity.

I've done a lot of googling and there is very little information about this. Which alarms me because I don't think I'm on the wrong track.

It would be easy enough to expire keys on a regular basis, although tools like GitLab and Stash don't make it simple. We have a "git login" wrapper script for sending SSH public keys to the server. It can ensure that old keys are not just re-used and it can also make sure to use special keys (as specified in~/.ssh/config ) so that we are not regularly overwriting somebody's ~/.ssh/id_da* and stopping their other logins. (Although using keys in a non-default location specified in a ssh config file might be problematic for some of my lon-linux (Windows) users.)

Has anybody else done this? What is industry best practice?

Update

Ok, so it looks like part of the answer is "This is exactly what SSH passphrases are meant for." So the remaining questions are along the lines of

Is there a way to enforce use of and regular changing of passphrases? I'm assuming people will comply, it just needs to be easy for them.

And, having said that, ssh passphrases eliminate the ability of doing git operations in a cron job. Which would be a real hindrance not to be able to do.

  • 2
    Have you considered adding some sort of multi-factor authentication? – EEAA Jul 29 '15 at 16:27
  • security.stackexchange.com/questions/14983/…. However I'm with EEAA use a second factor auth, personally I like duo from DuoSecurity – user9517 supports GoFundMonica Jul 29 '15 at 18:47
  • Thanks. To be honest, I'm in DevOps --a team of four of us-- not in a large IT department. We try to be lean and mean provide more service than big centralized IT while being much much less intrusive. Implementing a two-factor authentication scheme is simply not on our radar at the moment. – Mort Jul 29 '15 at 19:55
2

The answer to your question is no, there is no way within ssh to enforce regular changing pass phrases.

As you're using a single account presumably all the public keys will be in a single authorised_keys file so you could invalidate keys by removing them from it. This though feels like too much effort and people could just use the same pass phrase on a different key.

A way to ease your problem is to use multi-factor authentication, this way, even if the key/pass phrase is compromised there is another layer in the way.

  • Yes, I don't understand the claim "It would just take one compromised desktop to leak a private key and an intruder would have access to our intellectual property in perpetuity." Remove the key from authorized_keys. Done. I was going to suggest RevokedKeys in sshd_config but that isn't needed. – Mark Wagner Jul 29 '15 at 19:31
  • I guess that if someone has compromised a key and you don't have a method of forcing a change then the intruder has access to the data while the key is valid. Multi-factor auth does solve that issue. – user9517 supports GoFundMonica Jul 29 '15 at 19:37
  • Thanks. To be honest, I'm in DevOps --a team of four of us-- not in a large IT department. We try to be lean and mean provide more service than big centralized IT while being much much less intrusive. Implementing a two-factor authentication scheme is simply not on our radar at the moment. Yes, we can revoke keys and/or force users to re-send their keys or force users to run a login script that gives them a new passphrase. I just wonder what the industry standard is on these things. – Mort Jul 29 '15 at 19:57
  • @Mort if you all have smart phones duo will only take a couple of hours to install and for small orgs it's $1/user/month or free for less than 10 users if personal use. – user9517 supports GoFundMonica Jul 29 '15 at 20:13
  • We're not small. We're big, and across countries. – Mort Jul 29 '15 at 20:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.