graceful ssh key management

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello List,

Short version: How do I have multiple ssh keys not overwrite each other,
and not force me to use the -i <keyfile> option to ssh for different
servers?

Long version . . .

Motivation/Scenario:
I have a computer that is a client to a number of different servers.
For question purposes, it's a client to four servers. The client needs
to log in to all four servers via SSH. All four servers disallow
passwords, forcing ssh keys for logging in. (For the sake of argument,
the keys have no passphrase. They do in reality, I promise!) The
servers are 100% disparate: separate companies having nothing to do with
each other. Consequently, they do not share authentication tokens
amongst themselves. Hopefully this text-diagram will explain the
relationship:

- ---------------------------Client computer----------------------------
| | | |
| | | |
Server 1 Server 2 Server 3 Server 4

^-------------------^---------------------^--------------------^
No communication among the servers

This means that the client must have four separate private keys, one
each for each server. Further, this means that the default key file
name conflicts, even if I use both rsa and dsa schemes.

The answer, of course, is to use the -i option to specify the key file
for the each server

$ ssh -i key1 server1

Problem: I'm lazy. 8-P

Short of using alias, is there a way to have multiple keys play nice
with each other and me at the same time? I'm looking for my users to be
able to straight 'ssh server' from any shell window they've opened in
their window manager.

I feel like ssh-agent is the way to go. However, that'd still require a
little bit of wrapping for our multiple environments (2 flavors of BSD,
4 flavors of Linux, Solaris 8-10, OS X). I don't have the
"not-invented-here" syndrome so I'd love to not reinvent any wheels,
especially if an elegant solution exists.

GINMF today. 8-(

Thanks in advance,

Kevin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGS+TEajNaelVGYAERAsshAKCCp+A9NqhhyFFOZaxOJ/DqFNT9xACgqU+U
LXSmlrdUNWeZfwSyygr44lk=
=UJ4b
-----END PGP SIGNATURE-----

Relevant Pages

  • OpenSSH 3.0.1p1 Solaris 2.5 - 8.0 Nightmares occuring
    ... I am having some really bad problems trying to upgrade our servers to ... having all kinds of issues with the keys. ... PS Am purchasing O'reilly's SSH book today, hopefully, it will ...
    (comp.security.ssh)
  • Re: SSH ignores locked accounts
    ... >> via SSH still works too. ... > the remote users to use SSH key access rather than password based access, ... This is very useful for master servers that hold authentication ... > of private keys and a designated set of authorized keys for your authorized, ...
    (comp.security.ssh)
  • Re: ssh & X11 Authentication Issue - Advice Please
    ... >I went out and removed my .ssh directory on the mounted file system. ... >my keys are for my machine and anyone of the servers.. ...
    (Debian-User)
  • Re: Connect with null passphrases
    ... Be sure to check that under the SSH server configuration for remote and local machines, the option regarding the use of SSH keys is enabled. ... I changed to *NP* the password field of /etc/shadow for the fictitious users on the servers the cron jobs connect to, ... those servers to which the cron job tries to connect to as a real user, who has a real password, does not allow ssh connections with null passphrases. ...
    (SSH)
  • Analysis of SSH crc32 compensation attack detector exploit
    ... Analysis of SSH crc32 compensation attack detector exploit ... detector vulnerability to remotely compromise a Red Hat Linux ... Active Internet connections (servers and established) ...
    (Incidents)