Git: expire ssh keys just like passwords expire?

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.

Solution 1:

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.