Harry Putnam: > Jochen Spieker <m...@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-sha...@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 <cjwat...@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-...@openssh.com aes256-...@openssh.com arcfour arcfour128 arcfour256 blowfish-cbc cast128-cbc chacha20-poly1...@openssh.com The default is: aes128-ctr,aes192-ctr,aes256-ctr, aes128-...@openssh.com,aes256-...@openssh.com, chacha20-poly1...@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>
signature.asc
Description: Digital signature
