So, as I know ssh public key doesn't expire if you do not generate a new pair. Is there a way to grant the access to the client for a certain duration ? Like a token based authentication. So basically, I am interested can you make a "expirable public key"?
1 Answers
Short answer
Yes, there are two common mechanisms: Kerberos and short-lived SSH certificates. (Search for "SSH certificate authority".)
Long answer
You don't really need a new authentication method as long as the SSH server software allows enforcing some means of expiration for regular keys. OpenSSH has multiple mechanisms for doing so:
You can literally remove the key from the server-side
authorized_keysfile, manually or using a cronjob. If the key was the only means of accessing the server, or if you reconfigured sshd to store keys in a root-owned location (instead of ~/.ssh/) then the user cannot simply add it back.You can make this automatic, in recent OpenSSH server versions, by adding the
expiry-time=option to the authorized_keys entry. (See format documentation in sshd(8).) Same as above, if this was the last key or if the authorized_keys file is somewhere non-user-writable, that would prevent the user from simply editing the setting.You can generate a key revocation list using ssh-keygen. Configure the server to check all keys against it by enabling the
RevokedKeysoption of /etc/ssh/sshd_config. Users cannot bypass key revocation – it simply overrides the authorized_keys entry.You can in fact generate a special key type that has expiration built in – a "certificate". This currently requires OpenSSH to be used by the client as well, as other clients simply haven't implemented support for sending certificates.
OpenSSH certificates work quite similarly to TLS X.509 certificates: they are issued by a "certification authority", which is the server's owner in this case. See the
-soption in ssh-keygen(1) – you can specify validity time, allowed usernames, etc. and the OpenSSH server will enforce them.Similarly to method #4, there exist SSH clients and servers (such as PKIX-SSH) which let you use actual X.509 certificates for publickey auth, and of course they also enforce the "expiry time" parameter embedded in those certificates.
That said – yes, there are token-based authentication mechanisms in SSH:
Kerberos 5 is a commonly used "ticket"-based mechanism. (It is actually based on shared secret keys.) You acquire short-lived tickets from an authentication server using
kinit– 10 hours is the default lifetime – and you can use them with SSH using the "GSSAPI" authentication method.Globus GSI is another mechanism which builds on the GSSAPI framework (although it requires a patched OpenSSH version on top of that, due to unfortunate choices by the latter's developers). It is much less common than Kerberos, practically only ever seen in academic 'grid' environments.
Finally, I would include OpenSSH publickey certificates in the same category because nowadays many big sites indeed treat them as short-lived tokens – you'll find software for automatically issuing certificates for one day, in a similar fashion to Kerberos and GSI. (Examples: CloudFlare, Netflix.)