>> > A key database where you could share ssh host keys with ipsec would
>> > be good too.  
>> The professional paranoid in me worries that reusing the same key for
>> both purposes might have unexpected consequences..
>I figured I must have misunderstood because I don't see why one would
>want to share a single per-host key between different algorithms
>either.
>Let's say SSH puts its public key for host X into /etc/big-file-o-keys.  
>Now if ipsec were to use that same host key for DES it would be using
>what for all purposes was a disclosed key.  Not good.

	there are so many keys involved in IPsec and SSH operation.  please
	read the documents and familize yourself on how they are used.
	the fear you mentioned is not there.

	For example, IKE + IPsec.
	Basic background:
	- IKE has two phases, phase 1 and phase 2.
	  phase 1 tries to establish secret communication channel between
	  two nodes.  phase 2 tries to exchange IPsec key.
	now, here are keys used for phase 1:
	- RSA, or pre-shared secret, is used to authenticate the other party
	  (i need to be sure that i'm talking with Wolfgang, for example).  it
	  may make sense to use SSH host key here.  racoon does not do that
	  (yet).
	- Diffie-Hellman algorithm is used to exchange the session key for
	  phase 1.  the Diffie-Hellman key is generated on the fly.
	- based on phase 1 negotiation we pick an phase 1 algorithms (3DES
	  and SHA1, for example).  DH exchanges key between two nodes for 3DES
	  and SHA1.  the key is used for securing communication between IKE
	  daemons (for example, phase 2 exchange is not visible from outside.
	for phase 2:
	- Diffie-Hellman algorithm is used (again) to exchange the IPsec key
	  negotiated by phase 2.  again, we generate a fresh key.
	for IPsec:
	- phase 2 negotiates final IPsec key to be used (let's say AES and MD5).
	  the key is exchanged by phase 2 DH, and used to encrypt/authenticate
	  packets.
	now you know how complex IKE could be :-)

	For SSH, please read internet drafts.  I'm not a guru.

itojun