Key mismatch between Open SSh and F-Secure SSH

[Thomas Lindholm]

Hi,
I'm trying to connect via ssh from one F-secure SSH client to a Open SSH server.
The session just seems to hang.
If I'm running both side in debug mode i got

Client side:
debug: entering event loop
debug: ssh_client_wrap: creating transport protocol
debug: Ssh2Client/sshclient.c:1015: creating userauth protocol

More interesting is server side:
debug1: Client protocol version 2.0; client software version 2.1.0 dss F-SECURE SSH
debug1: match: 2.1.0 dss F-SECURE SSH pat 2.1.0*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-1.99-OpenSSH_3.6p1
debug1: list_hostkey_types: ssh-rsa,ssh-dss
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-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,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,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-group1-sha1
debug2: kex_parse_kexinit: ssh-dss
debug2: kex_parse_kexinit: 3des-cbc,blowfish-cbc,twofish-cbc,arcfour
debug2: kex_parse_kexinit: 3des-cbc,blowfish-cbc,twofish-cbc,arcfour
debug2: kex_parse_kexinit: hmac-sha1,hmac-md5,sha1-8,md5-8,sha1,none
debug2: kex_parse_kexinit: hmac-sha1,hmac-md5,sha1-8,md5-8,sha1,none
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 1
debug2: kex_parse_kexinit: reserved 0
debug2: mac_init: found hmac-sha1
debug1: kex: client->server 3des-cbc hmac-sha1 none
debug2: mac_init: found hmac-sha1
debug1: kex: server->client 3des-cbc hmac-sha1 none
debug2: proposal mismatch: my diffie-hellman-group-exchange-sha1 peer diffie-hellman-group1-sha1
debug2: skipping next packet (type 30)
debug2: dh_gen_key: priv key bits set: 195/384
debug2: bits set: 505/1024
debug1: expecting SSH2_MSG_KEXDH_INIT

I Understand that there is some kind of mismatch between the client & serverside, but how do I solve this?

Regards
Thomas

[Kent Ostby]

Thomas -- I dont know a lot about ssh, but one document on the web had a solution for this type of problem where the user that the connection was trying to be made for was not in the sshd group.

Best regards,

Kent M. Ostby

[Andrew Cowan]

Hi Thomas,

Have you generated your keyset on F-Secure and then copied it to the HP-Server? Assuming you have the normal mistakes are:

1. Wrong permissions on your ~/.ssh directory and/or files.

2. When the key was copied there are some rogue line-breaks or carriage-returns.

3. You have copied your key into the wrong file e.g. "authorized_keys" not "authorized_keys2".

The other thing you have not said is whether you can eventually connect by password? Have you tried deleting your keys and entry in known-hosts, and connecting this way?

If you can tell me this, then I have some more suggestions.

Good luck,
Andrew

[Thomas Lindholm]

Andrew,

Sorry forgot to write that I'm just using plain password auth. Not key authentication.

It works when I connect from another Openssh client.

Regards
Thomas

[Michael Armbrecht]

My idea would be to try to configure the client to use a different protocol. I don't know anything about F-Secure ssh, but I would expect the config files look similar to OpenSSH. As they have problems to agree on diffie-hellman, I'd try something different. Probably it is worth a try to force the client to use ssh protocol 1 instead of 2 and check if it's still the same problem.

[Thomas Lindholm]

Might work, I'd tried with the Windows version of F-secure and changed to Version 1, and that works... Cant figure out of to force the unix client to use ver. 1.
Tried to link the binary but without success!

[Michael Armbrecht]

Thomas,
I had a look at the F-Secure documentation. I had the impression that the config files used by F-Secure SSH are the same files OpenSSH uses.
Check /etc/ssh_config, check that the order of protocols to use is 1,2 (line starting with "Protocol") to make it use the ssh 1 - protocol as default.
Probably you should check the line "Ciphers" as well on both, client and server, to see if they have at least one in common.

[Steven Sim Kok Leong]

Hi,

Kindly ignore the repeats. Thought the submit button was not working and clicked an additional 2 times. :(

Steven Sim Kok Leong

[Thomas Lindholm]

Thanx everybody!
I give up and will remove the F-Secure installations...
Michael:
Got:
warning: Unrecognized configuration parameter protocol
So it didn't work!
R
Thomas

[Andrew Cowan]

Hi Thomas,

Good idea. Just get a free copy of Putty from: http://www.chiark.greenend.org.uk/~sgtatham/putty/

I did extensive testing of SSH for my employer (a large bank) and found Putty to be better than all the commercial offerings.

Andrew