Harry Putnam:
> Jochen Spieker <ml@well-adjusted.de> writes:
>> Harry Putnam:
>>>
>>> harry-on-REMOTE-sol > ssh REMOTE-deb
>>>
>>> no common kex alg: client
>>> 'diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1',
>>> server
>>> 'curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1'
>
>> This means client and server couldn't agree on a key exchange
>> algorithm. If you compare the client's and the server's list you will
>> notice they have nothing in common.
>
> Seems odd that it should fail then since I'm not using a key based
> access. Just password. Perhaps I don't understand how ssh works.
True. :) The connection is encrypted, no matter which authentication
mechanism you use. SSH supports several encryption algorithms so client
and server have to agree on something both parties support. That fails
in your case.
>> What flavor if Debian is the remote host running? The package
>> openssh-server from unstable has this more or less recent changelog
>> entry:
>
> The first line of OP mentions that I'm running `jessie'.
Sorry.
>> openssh (1:6.7p1-1) unstable; urgency=medium
>>
>> * New upstream release (http://www.openssh.com/txt/release-6.7):
>> - sshd(8): The default set of ciphers and MACs has been altered to
>> remove unsafe algorithms. In particular, CBC ciphers and arcfour* are
>> disabled by default. The full set of algorithms remains available if
>> configured explicitly via the Ciphers and MACs sshd_config options.
>> …
>> -- Colin Watson <cjwatson@debian.org> Thu, 09 Oct 2014 14:05:56 +0100
>
> Thanks for the usefull input... I'm now trying to investigate some way
> to get these two versions to comply with each other....
>
> ------- ------- ---=--- ------- -------
>
> Hard to believe that I haven't `full-upgraded' in over a month but
> apparently it is the case.
The date in the changelog entry is not necessarily the date of the
upload to unstable and after that it takes some time for the package to
enter jessie. You can check the date of the upgrade somewhere in
/var/log/apt or /var/log/dpkg.log.
> It seems none of the client list from error output are mentioned as
> being an unsafe alg. but yet it fails.
>
> Seems unreasonable to put such a weak clue in the changelog... neither
> sshd_config on REMOTE or LOCAL have any mention of such options.
On my sid system sshd_config(5) has this paragraph:
Ciphers
Specifies the ciphers allowed for protocol version 2. Multiple
ciphers must be comma-separated. The supported ciphers are:
3des-cbc
aes128-cbc
aes192-cbc
aes256-cbc
aes128-ctr
aes192-ctr
aes256-ctr
aes128-gcm@openssh.com
aes256-gcm@openssh.com
arcfour
arcfour128
arcfour256
blowfish-cbc
cast128-cbc
chacha20-poly1305@openssh.com
The default is:
aes128-ctr,aes192-ctr,aes256-ctr,
aes128-gcm@openssh.com,aes256-gcm@openssh.com,
chacha20-poly1305@openssh.com
The list of available ciphers may also be obtained using the -Q
option of ssh(1).
> I would assume that wheezy has the same version of openssh installed eh?
You don't have to assume, you can look it up:
http://packages.debian.org/openssh
> I'm not at all clear on how one would go about making an adjustment in
> sshd_config to allow the algs used by my REMOTE-sol to be recognized.
>
> REMOTE-sol does not appear to be using OpenSSH .. maybe a solaris
> version of SSH.
You could probably install OpenSSH on Solaris as well.
J.
--
If politics is the blind leading the blind, entertainment is the fucked-
up leading the hypnotised.
[Agree] [Disagree]
<http://www.slowlydownward.com/NODATA/data_enter2.html>
Attachment:
signature.asc
Description: Digital signature