On Thu, 25 Feb 2010, Nikos Mavrogiannopoulos wrote:
Ssh without secure public key distribution mechanism is not really
secure cryptographically.
In general, public key cryptography is scure only if public key
distribution is secure.
Well as far as I know ssh works pretty well today and this model can be
easy made verifiable (i.e. secure as you say) by the administrator
verifying the keys of upstream.
It already is, using DNSSEC.
dig +dnssec -t sshfp www.xelerance.org
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 5, ADDITIONAL: 1
;; ANSWER SECTION:
www.xelerance.org. 7200 IN SSHFP 1 1 F79BDD2C882A9AC575198D507DE89D9B38145F00
www.xelerance.org. 7200 IN SSHFP 2 1 B0B26D4895F3628AA721DAA0DB1B8236AFF02BF2
www.xelerance.org. 7200 IN RRSIG SSHFP 5 3 7200 20100306233849 20100220075947 58970 xelerance.org. HgME4vnp12/NhZKRUP7YVrSs6aXPeUvaWSoZ1FIS1Mk/8o9qIQgSb8k3 nC9LiQ8HjwGgVf7T2fSywvvW2KrlnFg8geJPSuMPEFXA41eXLUcmHHxr YQNfxkNnoJPz1iayk9tPjhKtfGwQuoL+hWiGUpnnjBKKU8hiCww4UjN4 yMo=
And from "man ssh_config":
VerifyHostKeyDNS
Specifies whether to verify the remote key using DNS and SSHFP
resource records. If this option is set to “yes”, the client
will implicitly trust keys that match a secure fingerprint from
DNS. Insecure fingerprints will be handled as if this option was
set to “ask”. If this option is set to “ask”, information on
fingerprint match will be displayed, but the user will still need
to confirm new host keys according to the StrictHostKeyChecking
option. The argument must be “yes”, “no”, or “ask”. The default
is “no”. Note that this option applies to protocol version 2
only.
See also VERIFYING HOST KEYS in ssh(1).
Paul
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf