First - it doesn't seem that Solaris' sshd supports hostbased
authentication with protocol v2. Can anyone confirm this ? That'd
be a real show-stopper for me, as the only other way (besides using
v1, probably) to provide passwordless connections would be to use
public key based user authentication, and I won't teach users
ssh-agent usage if there's no pressing need.
The second issue is that there seem to be interoperability problems
between ssh.com's implementation and Sun's. When trying to connect
with ssh (SSH Secure Shell 3.1.0) to Sun's sshd (with it's default
configuration) the connection fails with:
client:
warning: Authentication failed.
Disconnected; key exchange or algorithm negotiation failed
(Key exchange failed.).
server:
Disconnecting: Protocol error: expected packet type 21, got 30
Trying the connection with "ssh -v" to "/usr/lib/ssh/sshd -ddd",
reveals the following output (shortened):
client:
debug: Remote host key found from database.
debug: SshProtoTrKex/trkex.c:702/ssh_kex_keycheck_callback:
Signature didn't match.
debug: Ssh2Common/sshcommon.c:155/ssh_common_disconnect:
DISCONNECT received: Key exchange failed.
warning: Authentication failed.
debug: Ssh2/ssh2.c:127/client_disconnect: locally_generated = TRUE
Disconnected; key exchange or algorithm negotiation failed
(Key exchange failed.).
server:
debug1: got kexinit: none,zlib
debug1: got kexinit: none,zlib
debug1: got kexinit:
debug1: got kexinit:
debug1: first kex follow: 1
debug1: reserved: 0
debug1: done
debug2: mac_init: found hmac-sha1
debug1: kex: client->server unable to decide common locale
debug1: kex: client->server aes128-cbc hmac-sha1 none
debug2: mac_init: found hmac-sha1
debug1: kex: server->client unable to decide common locale
debug1: kex: server->client aes128-cbc hmac-sha1 none
debug1: bits set: 519/1024
debug1: Wait SSH2_MSG_KEXDH_INIT.
debug1: bits set: 516/1024
debug1: sig size 20 20
debug1: send SSH2_MSG_NEWKEYS.
debug1: done: send SSH2_MSG_NEWKEYS.
debug1: Wait SSH2_MSG_NEWKEYS.
Disconnecting: Protocol error: expected packet type 21, got 30
debug1: Calling cleanup 0x3f990(0x0)
Seems to be a problem with key signatures. Could this be connected
to ssh.com using a different format (bubble babble) for its key
fingerprints ?
BTW, I've tried all combinations of connections from/to ssh.com, Sun, and
OpenSSH (all with ssh protocol V2) and all but "from ssh.com to Sun" work.
mp.
--
Martin Paul | Systems Administrator
Institute for Software Science | mar...@par.univie.ac.at
University of Vienna, Austria | http://www.par.univie.ac.at/
Martin Paul <mar...@par.univie.ac.at> wrote in message news:<3d198e9f$0$20382$3b21...@news.univie.ac.at>...
Martin Paul <mar...@par.univie.ac.at> wrote in message news:<3d198e9f$0$20382$3b21...@news.univie.ac.at>...
Gerd Marquardt
RRZN / Universitaet Hannover marq...@rrzn.uni-hannover.de
Schlosswender Str. 5 Tel. +49-511-762-4727
D-30159 Hannover fax: +49-511-762-3003
This is a bug that I have reported on March 5th with the S9 beta
refresh that introduced to include SSH.
So far, Sun did not do anything, even the latest versions do not
work, I now use again my self compiled ssh.com
>
>Martin Paul <mar...@par.univie.ac.at> wrote in message news:<3d198e9f$0$20382$3b21...@news.univie.ac.at>...
>> I have two issues with the ssh implementation provided from Sun starting
>> with Solaris 9.
>>
>> First - it doesn't seem that Solaris' sshd supports hostbased
>> authentication with protocol v2. Can anyone confirm this ? That'd
>> be a real show-stopper for me, as the only other way (besides using
>> v1, probably) to provide passwordless connections would be to use
>> public key based user authentication, and I won't teach users
>> ssh-agent usage if there's no pressing need.
>>
>> The second issue is that there seem to be interoperability problems
>> between ssh.com's implementation and Sun's. When trying to connect
>> with ssh (SSH Secure Shell 3.1.0) to Sun's sshd (with it's default
>> configuration) the connection fails with:
>>
>> client:
>> warning: Authentication failed.
>> Disconnected; key exchange or algorithm negotiation failed
>> (Key exchange failed.).
>> server:
>> Disconnecting: Protocol error: expected packet type 21, got 30
--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni) If you don't have iso-8859-1
schi...@fokus.gmd.de (work) chars I am J"org Schilling
URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix
Solaris 9 comes with OpenSSH, but it does not work correctly and Sun seems to
ignore bug reports similar to how it ignored the bug reports for the sd driver
bug that lets a CD writer fail if no readable media is in.
>>
>>It's correct, Solaris9's sshd doesn't support hostbased authentication.
>>We will run OpenSSH further on.
>>
>
> Solaris 9 comes with OpenSSH, but it does not work correctly and Sun seems to
> ignore bug reports similar to how it ignored the bug reports for the sd driver
> bug that lets a CD writer fail if no readable media is in.
>
Is this problem due to bad configuration files or weird settings when
Sun compiled OpenSSH?
Would better config settings fix the problem or was the binary
incorrectly compiled to preclude config file changes?
-Rob
I did several complete installations from scratch in the S 9 Beta program.
It cannot be the keys as they have been created differently everytime.
SuSE Linux seems to have the same problem from reports from my collegues.
I can confirm that using the ssh client v3.2.0 from ssh.com makes it
work.
But, no matter whether the bug is really in ssh.com's implementation
or in Sun's, it doesn't actually fix the problem. If you decide to
run Sun's sshd, you're locking out all incoming users with ssh.com's
ssh < v3.2.0. Might be OK for systems being accessed by a limited
number of external hosts (or if they all are under your control),
but otherwise it's best to use OpenSSH or ssh.com's (>= v3.2.0)
implementation.
This one really shouldn't have slipped through the beta phase ..