Re: Haven't seen this ssh output before
Le 04.12.2014 11:33, Jochen Spieker a écrit : berenger.mo...@neutralite.org: debsecan. This is a tool which lists CVE (Common Vulnerabilities and Exposures) that the packages you installed contains. I think you might get some hints if you make a diff between the old (you said you have un-upgraded systems) and the new (the system which gaves you problems) systems. Debsecan is a great tool, but to find out whether a specific upgrade contains remedy for a specific CVE the easiest way is usually to just look at the changelog. I would be very surprised if OpenSSH people close security holes without mentioning that explicitly. J. Of course, but this is something which needs to be made by hand, since no apt tool I have heard about will list CVEs in a package. Except debsecan, which can be run by script, for example to send mail to warn on various things. I wonder if it could be doable to warn when the future package will introduce a CVE, before installing it? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/f7a8d33654389dd95d5669d879cd2...@neutralite.org
Re: Haven't seen this ssh output before
berenger.mo...@neutralite.org: debsecan. This is a tool which lists CVE (Common Vulnerabilities and Exposures) that the packages you installed contains. I think you might get some hints if you make a diff between the old (you said you have un-upgraded systems) and the new (the system which gaves you problems) systems. Debsecan is a great tool, but to find out whether a specific upgrade contains remedy for a specific CVE the easiest way is usually to just look at the changelog. I would be very surprised if OpenSSH people close security holes without mentioning that explicitly. J. -- If I was Mark Chapman I would have shot John Lennon with a water pistol. [Agree] [Disagree] http://www.slowlydownward.com/NODATA/data_enter2.html signature.asc Description: Digital signature
Re: Haven't seen this ssh output before
Le 27.11.2014 00:04, Harry Putnam a écrit : Harry Putnam rea...@newsguy.com writes: 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. In light of the comments above; if you have any more info on this and have the time... please post. I managed to get a bit of a solution after careful study of the error output and man sshd_config (Largely from being guided by your post) It shows the default kex algorithems and the possible kex alg. I thought of just adding one that matched the list of my clients available choices to sshd_config on REMOTE-deb like so: KexAlgorithms diffie-hellman-group-exchange-sha1 Then restart sshd. That works, but I was afraid that might mean the defaults would be dropped and only `diffie-hellman-group-exchange-sha1' would be offered. I was afraid that might cause failure on some other hosts. Thanks for sharing the solution, one might needs it someday, especially considering the fact you are using the future debian stable. Any opinions on what I may have created? I'm not a security guy (not even a sysadmin, just a dev, but I am feeling concerned with security of computers anyway...), not that I do not want to learn about it, but it's a very complex thing. But, since you seem to be afraid of security holes, I would like to point to a package I have discovered recently (in a search about netBSD good points, the author was saying that a tool listing CVEs of packages you are trying to install was lacking on other systems, and made an edit because someone gave him this tool's name for Debian): debsecan. This is a tool which lists CVE (Common Vulnerabilities and Exposures) that the packages you installed contains. I think you might get some hints if you make a diff between the old (you said you have un-upgraded systems) and the new (the system which gaves you problems) systems. Now, I can't find any CVE with it on (one of) my computer, which have only openSSH's client installed, so it might not help you. Security is a really complex thing, that I do not understand a lot so the problem might not be caused by any CVE of openSSH itself, but, AFAIK, openSSH is using libssl, which is, according to aptitude: a part of openSSL's implementation for SSL, and with this command: $ debsecan |grep ssl -i I have 2 CVEs (no idea if they apply to you btw): CVE-2014-3566 libssl1.0.0 (remotely exploitable, medium urgency) CVE-2014-3566 openssl (remotely exploitable, medium urgency) Maybe your updated machine have fixed one of them? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/3fec1ace9e30ca3b41723bbc1acb2...@neutralite.org
Re: Haven't seen this ssh output before
Harry Putnam: Harry Putnam rea...@newsguy.com writes: … KexAlgorithms curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1 That also works. Thanks for posting your solution and what you tried. Now, since debian chose to follow the new upstream sshd defaults and limits due to `UNSAFE' alg. I'm wondering if by adding one of those discarded algs back in there... I may be creating a security hole. I am not qualified to give an answer to that, I usually trust upstream's or the maintainer's defaults. You will probably receive the best answers on OpenSSH related mailing lists. Maybe it is even already explained there. But, as far as I understand, if the key exchange algorithm is really unsafe, the risk is probably that someone might eavesdrop on your connection. This is especially problematic since you are using password authentication because the password can be read as well (if the key exchange is unsafe). J. -- I have been manipulated and permanently distorted. [Agree] [Disagree] http://www.slowlydownward.com/NODATA/data_enter2.html signature.asc Description: Digital signature
Re: Haven't seen this ssh output before
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. 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'. 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. 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. I would assume that wheezy has the same version of openssh installed eh? 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. In light of the comments above; if you have any more info on this and have the time... please post. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87tx1lhcmt@newsguy.com
Re: Haven't seen this ssh output before
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
Re: Haven't seen this ssh output before
Harry Putnam rea...@newsguy.com writes: 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. In light of the comments above; if you have any more info on this and have the time... please post. I managed to get a bit of a solution after careful study of the error output and man sshd_config (Largely from being guided by your post) It shows the default kex algorithems and the possible kex alg. I thought of just adding one that matched the list of my clients available choices to sshd_config on REMOTE-deb like so: KexAlgorithms diffie-hellman-group-exchange-sha1 Then restart sshd. That works, but I was afraid that might mean the defaults would be dropped and only `diffie-hellman-group-exchange-sha1' would be offered. I was afraid that might cause failure on some other hosts. It was not clear to me from `man sshd_config' just how exactly to do this. I finally opted for listing all the defaults + diffie-hellman-group-exchange-sha1 Like this (in REMOTE-deb /etc/ssh/sshd_config): KexAlgorithms curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1 That also works. Now, since debian chose to follow the new upstream sshd defaults and limits due to `UNSAFE' alg. I'm wondering if by adding one of those discarded algs back in there... I may be creating a security hole. The REMOTE-deb host is exposed to ssh via the internet... not just through the lan. Any opinions on what I may have created? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87mw7dh8d5@newsguy.com
Haven't seen this ssh output before
Running debian jessie I have one openindiana (solaris) host on my home lan. That host has had no updates or changes recently. Following a `full-upgrade' yesterday on a debian host, I am now seeing an ssh failure with output I have not seen before, when ssh from openindian host to debian host (newly full upgraded). From here on I'll refer to the hosts as LOCAL-sol and REMOTE-deb The LOCAL-sol host can ssh to all other lan hosts without problems, including 2 other debian hosts (not recently upgraded) So cutting to the chase: It appears likely that something changed on REMOTE-deb that is causing incoming ssh from LOCAL-sol to fail. Apparently something in the OS makeup of LOCAL-sol host disagrees with some recent change in REMOTE-deb. I use the following command very often until now: from: LOCAL-sol ssh to REMOTE-deb Note that I do not use any kind of key matching, agents or what not... just straight ssh password access for quite a long time. Also note as posted above... this same LOCAL-sol host can ssh to other (non-upgraded) debian hosts on my lan with no problem. --- --- ---=--- --- --- 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' --- --- ---=--- --- --- (ssh Verbose output is posted futher along). Its possible I've changed something on the LOCAL-sol host... but can't think what it might be. Further, the ssh -vv ouput below is pretty confusing to me, and did not help me debug it. Googling the above error output lead to some similar occurances but from quite a good while ago... 2005-2006 and I did not see the solution. --- --- ---=--- --- --- from LOCAL-sol ssh -vv REMOTE-deb (I've edited host names below, where ever I saw them) Sun_SSH_1.5, SSH protocols 1.5/2.0, OpenSSL 0x0090819f debug1: Reading configuration data /etc/ssh/ssh_config debug1: Rhosts Authentication disabled, originating port will not be trusted. debug1: ssh_connect: needpriv 0 debug1: Connecting to REMOTE-deb [192.168.0.5] port 22. debug1: Connection established. debug1: identity file /home/harry/.ssh/identity type -1 debug1: identity file /home/harry/.ssh/id_rsa type -1 debug1: identity file /home/harry/.ssh/id_dsa type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_6.7p1 Debian-3 debug1: match: OpenSSH_6.7p1 Debian-3 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-Sun_SSH_1.5 debug1: use_engine is 'yes' debug1: pkcs11 engine initialized, now setting it as default for RSA, DSA, and symmetric ciphers debug1: pkcs11 engine initialization complete 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-ctr,aes192-ctr,aes256-ctr,arcfour128,arcfour256,arcfour,aes128-cbc,aes192-cbc,aes256-cbc,blowfish-cbc,3des-cbc debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour128,arcfour256,arcfour,aes128-cbc,aes192-cbc,aes256-cbc,blowfish-cbc,3des-cbc debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: en-US debug2: kex_parse_kexinit: en-US debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug1: Failed to acquire GSS-API credentials for any mechanisms (No credentials were supplied, or the credentials were unavailable or inaccessible ) 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-ctr,aes192-ctr,aes256-ctr,arcfour128,arcfour256,arcfour,aes128-cbc,aes192-cbc,aes256-cbc,blowfish-cbc,3des-cbc debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour128,arcfour256,arcfour,aes128-cbc,aes192-cbc,aes256-cbc,blowfish-cbc,3des-cbc debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: en-US debug2: kex_parse_kexinit: en-US debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519
Re: Haven't seen this ssh output before
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. What flavor if Debian is the remote host running? The package openssh-server from unstable has this more or less recent changelog entry: 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 J. -- When driving at night I find the headlights of oncoming vehicles very attractive. [Agree] [Disagree] http://www.slowlydownward.com/NODATA/data_enter2.html signature.asc Description: Digital signature
