I just noticed (at least on OpenSSH 3.0p1) that even though I have both RSA and DSA keys available in sshd_config on a server, only a ssh-rsa line shows up in known_hosts on the client side, not a ssh-dss line (that priority may come from the fact that my RSA key is listed before my DSA key in sshd_config). If I comment out the RSA key in sshd_config and restart the server, then the next time the client connects it warns that a new key is being added and adds a ssh-dss line to known_hosts. Isn't that a potential opening for a man-in-the-middle exploit? Somebody could take over a DNS name, offer only a DSA key, and forward traffic to the real host. SSH users expect that once they've established the identity of a host they're safe from man-in-the-middle exploits so they may gloss over the warning of an additional key being added. Maybe the OpenSSH ssh client should retrieve and store both kinds of host keys if they're missing from known_hosts and the server has them available. I don't know if that would take a protocol change or not but I doubt it because ssh-keyscan has the ability to scan for both rsa and dsa keys at the same time (and be sure to scan for both if you do use it!). - Dave Dykstra
I might have to agree with this thought. It does leave a pretty wide open hole it seems for now. I only use One key type in my network end-to-end, but if I were to use 2, it is possible. How could this be stopped. On Thu, 2002-01-10 at 13:40, Dave Dykstra wrote:> I just noticed (at least on OpenSSH 3.0p1) that even though I have both > RSA > and DSA keys available in sshd_config on a server, only a ssh-rsa line > shows up in known_hosts on the client side, not a ssh-dss line (that > priority may come from the fact that my RSA key is listed before my DSA > key > in sshd_config). If I comment out the RSA key in sshd_config and > restart > the server, then the next time the client connects it warns that a new > key > is being added and adds a ssh-dss line to known_hosts. > > Isn't that a potential opening for a man-in-the-middle exploit? > Somebody > could take over a DNS name, offer only a DSA key, and forward traffic to > the real host. SSH users expect that once they've established the > identity > of a host they're safe from man-in-the-middle exploits so they may gloss > over the warning of an additional key being added. Maybe the OpenSSH > ssh > client should retrieve and store both kinds of host keys if they're > missing > from known_hosts and the server has them available. I don't know if > that > would take a protocol change or not but I doubt it because ssh-keyscan > has > the ability to scan for both rsa and dsa keys at the same time (and be > sure > to scan for both if you do use it!). > > - Dave Dykstra > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev-- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin at coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: This is a digitally signed message part Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020110/60a4245c/attachment.bin
On Thu, Jan 10, 2002 at 01:40:29PM -0600, Dave Dykstra wrote:> I don't know if that > would take a protocol change or not but I doubt it because ssh-keyscan has > the ability to scan for both rsa and dsa keys at the same time (and be sure > to scan for both if you do use it!).ssh-keyscan makes 1 connection per key type.
On Thu, Jan 10, 2002 at 01:40:29PM -0600, Dave Dykstra wrote:> I just noticed (at least on OpenSSH 3.0p1) that even though I have both RSA > and DSA keys available in sshd_config on a server, only a ssh-rsa line > shows up in known_hosts on the client side, not a ssh-dss line (that > priority may come from the fact that my RSA key is listed before my DSA key > in sshd_config).no, it comes from HostKeyAlgorithms ssh-rsa,ssh-dss> If I comment out the RSA key in sshd_config and restart > the server, then the next time the client connects it warns that a new key > is being added and adds a ssh-dss line to known_hosts.yes, ssh should always ask.> Isn't that a potential opening for a man-in-the-middle exploit?man-in-the-middle is always possible if ssh sees a new hostkey.> Somebody > could take over a DNS name, offer only a DSA key, and forward traffic to > the real host. SSH users expect that once they've established the identity > of a host they're safe from man-in-the-middle exploits so they may gloss > over the warning of an additional key being added.i think keys should no longer be 'automatically added'. they should not be 'automatically added' for the IP address, if the key matches for the DNS name, but no key is known for the IP address (Niels?).> Maybe the OpenSSH ssh > client should retrieve and store both kinds of host keysnot possible.> if they're missing > from known_hosts and the server has them available.they client could say: server offers an unknown rsa key, but we already have a known dsa key.> I don't know if that > would take a protocol change or not but I doubt it because ssh-keyscan has > the ability to scan for both rsa and dsa keys at the same time (and be sure > to scan for both if you do use it!).ssh-keyscan makes 2 connections if you request 2 different key types.
On Thu, Jan 10, 2002 at 01:40:29PM -0600, Dave Dykstra wrote:> I comment out the RSA key in sshd_config and restart > the server, then the next time the client connects it warns that a new key > is being added and adds a ssh-dss line to known_hosts.Are you sure that ssh just warns and automatically adds the key? I get this: % ssh bla -p1234 The authenticity of host 'bla (10.1.1.1)' can't be established. DSA key fingerprint is 5a:c9:15:95:a2:4f:0a:42:99:8c:63:92:06:36:b4:8d. Are you sure you want to continue connecting (yes/no)? ^C % So I don't see a new potential for a MITM attack, MITM is always possible if ssh says: The authenticity of host 'XXXX' can't be established. (however, ssh could try to list all known keys for this host)