Sufficiently recent versions of ssh
(7.2, released early 2016, and newer) have an option AddKeysToAgent which does just that:
AddKeysToAgent
Specifies whether keys should be automatically added to a running ssh-agent(1). If this option is set to yes and a key is
loaded from a file, the key and its passphrase are added to the agent with the default lifetime, as if by ssh-add(1). If
this option is set to ask, ssh(1) will require confirmation using the SSH_ASKPASS program before adding a key (see
ssh-add(1) for details). If this option is set to confirm, each use of the key must be confirmed, as if the -c option
was
specified to ssh-add(1). If this option is set to no, no keys are added to the agent. The argument must be yes, confirm,
ask, or no (the default).
As to differences in behaviour: the ssh-agent
protocol follows a standard, which boils down to the following: the client (ssh
, or ssh-add
, or anybody else interested) knows who to talk to by looking at the environment variable SSH_AUTH_SOCK
. The protocol, slightly simplified, has the following operations:
key management operations: add, remove, list available keys
message operations: sign, encrypt, etc.
Usually, you'd use ssh-add
for the first kind. But, as said, new ssh
s will add as well. When you ask about on-demand loading of keys: an agent might do something fancy when you ask for a list of available keys – the standard implementation requires you to add all the keys beforehand, but a desktop environment implementation might have keys in some wallet storage protected by a master password, and ask for the password when you first try to use any key. (Or maybe you mean keys are shared between different terminal windows? That's just a matter of getting the environment variable SSH_AUTH_SOCK
into all your terminals, which is why it's good to start the agent in your session, so all terminals inherit the variable.)
gnome-keyring-daemon
?gnome-keyring-daemon
in response to my comment.