Ssh – How to check lifetime of SSH keys loaded to agent

sshssh-agentssh-keys

I'm using OpenSSH on Linux. For securioty reasons, when I load keys to agent, I use -t option, to limit time of availability of the keys (generally for 10 hours or so).

Is there any way to list all loaded keys with their "expiry" time?

Best Answer

As you can see in the ssh-agent protocol specification, there is no field that would expose the timeout to the client.

If you want to use expiry time, but do not want to care about adding them, there is option AddKeysToAgent, which will allow to add the keys to the agent when it is used for the first time.

Related Solutions

SSH – Stop Client from Offering All Public Keys

This is expected behaviour according to the man page of ssh_config:

 IdentityFile
         Specifies a file from which the user's DSA, ECDSA or DSA authentica‐
         tion identity is read.  The default is ~/.ssh/identity for protocol
         version 1, and ~/.ssh/id_dsa, ~/.ssh/id_ecdsa and ~/.ssh/id_rsa for
         protocol version 2.  Additionally, any identities represented by the
         authentication agent will be used for authentication.  

         [...]

         It is possible to have multiple identity files specified in configu‐
         ration files; all these identities will be tried in sequence.  Mul‐
         tiple IdentityFile directives will add to the list of identities
         tried (this behaviour differs from that of other configuration
         directives).

Basically, specifying IdentityFiles just adds keys to a current list the SSH agent already presented to the client.

Try overriding this behaviour with this at the bottom of your .ssh/config file:

Host *
  IdentitiesOnly yes

You can also override this setting on the host level, e.g.:

Host foo
  User bar
  IdentityFile /path/to/key
  IdentitiesOnly yes

Ssh – How to arrange for an ssh key with a passphrase to be loaded and available in ssh-agent to other processes on Windows startup

SSH in a Windows environment is an unusual option. Most people would use WMI to deploy applications and manage remote systems. Jenkins-CI (formerly Hudson-CI) makes great use of WMI for this purpose, so have a look there for examples.

But, you're on SSH, so I recommend you generate SSH keys without passwords.

It'll be harder to shouldersurf or guess (unencrypted) SSH keys compared to stealing or guessing a regular password.

Combine the unencrypted SSH with IP restrictions and log monitoring, so you'll know instantly if someone stole a key and tried to log in from another host using the stolen key.

If you didn't already: Consider a design that allows your high-value hosts to connect out to your application nodes, rather than the other way around.

If your (exposed?) nodes connect via SSH to a central server for application updates, consider using ForcedCommand and ChrootDirectory to restrict how much data is available to an attacker who tries to use an application node to attack your golden host.

Best Answer

Related Solutions

SSH – Stop Client from Offering All Public Keys

Ssh – How to arrange for an ssh key with a passphrase to be loaded and available in ssh-agent to other processes on Windows startup

Related Topic