Project

General

Profile

Actions
Copy link

Bug #1242

closed

sshd appears to be broken when both host rsa and dsa key file present

Added by dillon almost 16 years ago. Updated over 15 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:

Description

I think YONETANI reported this a few months ago, but it just started
happening to me when I upgraded pkgbox.

Something is ignoring the host DSA key when a host RSA key is presenting,
    causing a mismatch with a pre-existing known_hosts file.
If I were to say 'yes', then RSA host key would be recorded in my
    known_hosts file.
If I remove the RSA host key file on the server and restart sshd, then
    the client properly negotiates using the DSA host key.
Anyone have any ideas?
-Matt

office1:/home/dillon> ssh v -v -v pkgbox
OpenSSH_5.1p1 DragonFly-20080927, OpenSSL 0.9.8j 07 Jan 2009
debug1: Reading configuration data /home/dillon/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug2: ssh_connect: needpriv 0
debug1: Connecting to pkgbox.dragonflybsd.org [216.240.41.27] port 22.
debug1: Connection established.
debug1: identity file /home/dillon/.ssh/identity type -1
debug1: identity file /home/dillon/.ssh/id_rsa type -1
debug3: Not a RSA1 key file /home/dillon/.ssh/id_dsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug2: key_type_from_name: unknown key type 'Proc-Type:'
debug3: key_read: missing keytype
debug2: key_type_from_name: unknown key type 'DEK-Info:'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /home/dillon/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Drago
nFly-20080927
debug1: match: OpenSSH_5.1p1 DragonFly-20080927 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.1p1 DragonFly-20080927
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-g
roup-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour1
28,arcfour256,arcfour,aes192-cbc,aes256-cbc,,aes128-c
tr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour1
28,arcfour256,arcfour,aes192-cbc,aes256-cbc,,aes128-c
tr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,,hmac-ripemd160
,,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,,hmac-ripemd160
,,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,,zlib
debug2: kex_parse_kexinit: none,,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-g
roup-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour1
28,arcfour256,arcfour,aes192-cbc,aes256-cbc,,aes128-c
tr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour1
28,arcfour256,arcfour,aes192-cbc,aes256-cbc,,aes128-c
tr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,,hmac-ripemd160
,,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,,hmac-ripemd160
,,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,
debug2: kex_parse_kexinit: none,
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: found hmac-md5
debug1: kex: server>client aes128-cbc hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 135/256
debug2: bits set: 524/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename /home/dillon/.ssh/known_hosts
debug3: key_read: type mismatch
debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts
debug3: check_host_in_hostfile: filename /home/dillon/.ssh/known_hosts
debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts
debug2: no key of type 0 for host pkgbox.dragonflybsd.org
debug3: check_host_in_hostfile: filename /home/dillon/.ssh/known_hosts2
debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts2
debug3: check_host_in_hostfile: filename /home/dillon/.ssh/known_hosts
WARNING: DSA key found for host pkgbox.dragonflybsd.org
in /home/dillon/.ssh/known_hosts:33
DSA key fingerprint b0:89:61:93:9d:3d:fe:6d:71:c4:0a:f2:14:eb:c1:43.
-[ DSA 2048]--- | E | | o o o o . | | = + + B o | | . + = * + o | | . o S o o . | | . . o | | . o | | . | | |
---------------

The authenticity of host 'pkgbox.dragonflybsd.org (216.240.41.27)' can't be esta
blished
but keys of different type are already known for this host.
RSA key fingerprint is 92:86:a3:c4:99:07:96:46:f1:05:4d:c1:47:9d:ea:49.
Are you sure you want to continue connecting (yes/no)?

Actions
Copy link
 #1

Updated by qhwt+dfly almost 16 years ago

Seems like the import of openssh-5.1 reverted the order of the default
hostkey algorithm proposal, which has been part of FreeBSD-local
preferences for many years:
diff --git a/crypto/openssh-5/myproposal.h b/crypto/openssh-5/myproposal.h
index 8bdad7b..87a9e58 100644
--- a/crypto/openssh-5/myproposal.h
+++ b/crypto/openssh-5/myproposal.h
@ -40,7 +40,7 @
"diffie-hellman-group1-sha1"
#endif

-#define KEX_DEFAULT_PK_ALG    "ssh-dss,ssh-rsa" 
  +#define    KEX_DEFAULT_PK_ALG    "ssh-rsa,ssh-dss" 
   #define    KEX_DEFAULT_ENCRYPT \
      "aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc," \
      "arcfour128,arcfour256,arcfour," \

Note that FreeBSD also got rid of this local change about a month
earlier than we did:
http://docs.freebsd.org/cgi/mid.cgi?200808010253.m712raNF004286

So the quick workaround(if you still prefer DSA over RSA) is
to add the following in /etc/ssh_config on ssh clients

HostKeyAlgorithms    ssh-dsa,ssh-rsa

or to make it per-user, add the following two lines in ~/.ssh/config
Host foo # or use * if you want to apply any hosts
HostKeyAlgorithms ssh-dsa,ssh-rsa

Cheers.

Actions
Copy link
 #2

Updated by jdc almost 16 years ago

This should read:

HostKeyAlgorithms    ssh-dss,ssh-rsa

(-dss, not -dsa).

Actions
Copy link
 #3

Updated by qhwt+dfly almost 16 years ago

Whoops, thanks!

Actions
Copy link
 #4

Updated by dillon almost 16 years ago

:> Seems like the import of openssh-5.1 reverted the order of the default
:> hostkey algorithm proposal, which has been part of FreeBSD-local
:> preferences for many years:
:> diff --git a/crypto/openssh-5/myproposal.h b/crypto/openssh-5/myproposal.h
:> index 8bdad7b..87a9e58 100644
:> --- a/crypto/openssh-5/myproposal.h
:> +++ b/crypto/openssh-5/myproposal.h
:> @ -40,7 +40,7 @
:> "diffie-hellman-group1-sha1"
:> #endif
:>
:> #define KEX_DEFAULT_PK_ALG "ssh-dss,ssh-rsa"
:> +#define KEX_DEFAULT_PK_ALG "ssh-rsa,ssh-dss"
:> #define KEX_DEFAULT_ENCRYPT \
:..
:> HostKeyAlgorithms ssh-dsa,ssh-rsa
:
:This should read:
:
: HostKeyAlgorithms ssh-dss,ssh-rsa
:
:(-dss, not -dsa).
:-
:| Jeremy Chadwick jdc at parodius.com |

That looks like a client-side solution, though, which doesn't
    help fix the server-side defaults.
Does changing KEX_DEFAULT_PK_ALG fix it on the server side?  If
    so I think we may need to re-apply the local change.
-Matt
                    Matthew Dillon 
                    &lt;&gt;
Actions
Copy link
 #5

Updated by vince.dragonfly almost 16 years ago

Would there really be any reason to change it back. I assume they changed RSA
to being the default is because the patent is expired. Also, according to my
notes,

RSA is preferable in most cases, since DSA is slower
    and cannot encrypt in and of itself (DSA is a signing
    algorithm only).  RSA can be used to encrypt files.
Actions
Copy link
 #6

Updated by dillon almost 16 years ago

:Would there really be any reason to change it back. I assume they changed RSA
:to being the default is because the patent is expired. Also, according to my
:notes,
:
: RSA is preferable in most cases, since DSA is slower
: and cannot encrypt in and of itself (DSA is a signing
: algorithm only). RSA can be used to encrypt files.

Yes, because ssh will unexpectedly stop working in automated scripts
    if we change the default as the related keys will not be in the 
    known_hosts file.
-Matt
                    Matthew Dillon 
                    &lt;&gt;
Actions
Copy link
 #7

Updated by jgordeev almost 16 years ago

Matthew Dillon wrote:

The change has already been made in the development version. Time has
passed. Any automated scripts that could break should have done it by now.
We can keep the current order and put a big note in the release notes
for DragonFly 2.2.
I believe that RSA is preferred to DSA as DSA is limited to 1024-bit
keys, while RSA key size is more or less unlimited.

Actions
Copy link
 #8

Updated by corecode almost 16 years ago

The real question for me is, why is the server only offering one key or why is the client not checking for the DSA key it already knows?

cheers
simon

Actions
Copy link
 #9

Updated by jgordeev almost 16 years ago

Simon 'corecode' Schubert wrote:

Configure your client to prefer the other algorithm and run it against a
known server with as many -v options as appropriate.
Read the debug output and the message that ssh displays.

Actions
Copy link
 #10

Updated by corecode almost 16 years ago

And that answers my question... how?

Actions
Copy link
 #11

Updated by qhwt+dfly almost 16 years ago

On 2.0-RELEASE, ssh client and server are patched so that the server
by default offers only DSA host key, and the client prefers DSA host key
by default:
http://docs.FreeBSD.org/cgi/mid.cgi?200206291051.g5TApuaT057463

On -DEVELOPMENT, they aren't.

You don't have this problem when you try to slogin from a -DEVELOPMENT box
to a 2.0-RELEASE box, because the server doesn't offer RSA host key
by default.
You don't have this problem when you try to slogin from a 2.0-RELEASE box
to a -DEVELOPMENT box, because the client prefers DSA over RSA.

You DO have this problem when you try slogin'ing from -DEVEL to -DEVEL,
as the server offers both keys AND the client prefers RSA over DSA.

Which algorithm to use is determined based on the proposal, before looking
at your known_hosts file, hence the warning. If I understand the code
correctly, of course.

Actions
Copy link
 #12

Updated by corecode over 15 years ago

What do we want to do about this? I guess reasonable time (and a release) has
passed, so that we can ignore this issue.

Actions
Copy link
 #13

Updated by dillon over 15 years ago

:Simon 'corecode' Schubert <> added the comment:
:
:What do we want to do about this? I guess reasonable time (and a release) =
:has
:passed, so that we can ignore this issue.

Shrug.  Go with the flow I guess.
-Matt
                    Matthew Dillon 
                    &lt;&gt;
Actions
Copy link

Also available in: Atom PDF