Re: ssh Problem using it for SFTP
It helps to explain things, Daniel, but truly, the client in question is horrendously out of date and deprecated for all secure intents and purposes, I'm quite happy to retire it from active support on my server. On Sat, 16 Jan 2016 15:19:33 -0300, you wrote: >Hi, Steve. > >On 14/01/16 13:10, Steve Matzura wrote: > >> Failing connection: >> (...) >> no matching cipher found: client >> aes192-cbc,3des-cbc,blowfish-cbc,aes128-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-...@lysator.liu.se,des-cbc,des-...@ssh.com >> server >> aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com,chacha20-poly1...@openssh.com > >> The rest of the lines show connection run-down, omitted. > >H... Maybe you could fix this by allowing users to choose between >SHA1 and SHA2 hash functions. > >Since the openssh-server version used in Jessie (and presumably the >upstreams of SSHD) now has diffie-hellman-group1-sha1 disabled, this >means that connections some clients could fail. A workaround would be to >add the following in /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,diffie-hellman-group1-sha1 > >But at some point I think the support for diffie-hellman-group1-sha1 >completely disappear instead of being disabled by default. > >I hope this helps. > >Best regards, >Daniel
Re: ssh Problem using it for SFTP
Daniel, On Sat, 16 Jan 2016 14:50:20 -0300, you wrote: >I'm sorry. I Had forgotten of the detail of the accessibility :( No worries. Things are in a sorry state at the moment because of other things I did without realizing I did them, but I've already told my usership that Voyager will have to go. They're OK with it, the ones that use it.
Re: ssh Problem using it for SFTP
Hi, Steve. On 14/01/16 13:10, Steve Matzura wrote: > Failing connection: > (...) > no matching cipher found: client > aes192-cbc,3des-cbc,blowfish-cbc,aes128-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-...@lysator.liu.se,des-cbc,des-...@ssh.com > server > aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com,chacha20-poly1...@openssh.com > The rest of the lines show connection run-down, omitted. H... Maybe you could fix this by allowing users to choose between SHA1 and SHA2 hash functions. Since the openssh-server version used in Jessie (and presumably the upstreams of SSHD) now has diffie-hellman-group1-sha1 disabled, this means that connections some clients could fail. A workaround would be to add the following in /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,diffie-hellman-group1-sha1 But at some point I think the support for diffie-hellman-group1-sha1 completely disappear instead of being disabled by default. I hope this helps. Best regards, Daniel signature.asc Description: OpenPGP digital signature
Re: ssh Problem using it for SFTP
Hi, Steve. On 14/01/16 13:01, Steve Matzura wrote: >> I do not know that client, but if your users are using Firefox, maybe >> you could use FireFTP [1]. I never had problems with it, and we could >> also say that while users use Firefox, you could run it on different >> operating systems. > It would be an administrative nightmare, as I have seventy users, > (oy!) and I'd have to test to see if FireFTP is accessible with a > screenreader, as many of my users are visually impaired. That's why > it's important to stay with what they're using and not force a change > on them if at all possible. However, there may be other things to look > at (see message I just posted re SELinux). Oh, I'm sorry. I Had forgotten of the detail of the accessibility :( In fact it reminds me that in the first message from you I read here, I think you asked about the Debian installer with the screenreader. I'll try to keep that in mind. Tell us how it goes. It also allows us to make recommendations on alternatives to friends or others who need applications that do focus on accessibility. Best regards, Daniel signature.asc Description: OpenPGP digital signature
Re: ssh Problem using it for SFTP
The problem is that the older client doesn't support ciphers newer than CBC and arcfour (both depreciated on the newer server versions of OpenSSH). Lookup how to re-enable these suites using the Cipher directive.
Re: ssh Problem using it for SFTP
One more piece of the puzzle. The working system is Red Hat Fedora 20, the non-working one is Debian 8.2.
Re: ssh Problem using it for SFTP
More info. I used getenforce' and found SELinux is installed but disabled on the system where FTP Voyager can connect using SFTP over ssh, and not installed at all on the system where FTP Voyager cannot connect. In fact, using either the `getenforce' or `'sestatus' on the no-connect system yields `command not found'. Am I on to something?
Re: ssh Problem using it for SFTP
Daniel, On Thu, 14 Jan 2016 09:05:36 -0300, you wrote: >Hi, Steve. > >On 14/01/16 08:45, Steve Matzura wrote: > >> This is clearly the problem area. I tried some ssh option settings in >> Voyager with no success. Should this client be retired? It's not >> *that* old. > >I do not know that client, but if your users are using Firefox, maybe >you could use FireFTP [1]. I never had problems with it, and we could >also say that while users use Firefox, you could run it on different >operating systems. It would be an administrative nightmare, as I have seventy users, (oy!) and I'd have to test to see if FireFTP is accessible with a screenreader, as many of my users are visually impaired. That's why it's important to stay with what they're using and not force a change on them if at all possible. However, there may be other things to look at (see message I just posted re SELinux).
Re: ssh Problem using it for SFTP
I decided to put the two logs from `sshd -d' side-by-side to try to figure out where the differences are. Both logs have the following lines immediately after the connection request: debug1: Client protocol version 2.0; client software version FTP-Voyager-15.2.0.15 debug1: no match: FTP-Voyager-15.2.0.15 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.6.1 The working connection log has this line next: debug1: SELinux support disabled [preauth] Then the two logs continue with the same lines, although some of the parameters may differ. I don't think they're important. debug1: permanently_set_uid: 74/74 [preauth] Now it gets interesting. Working connection: debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519 [preauth] debug1: SSH2_MSG_KEXINIT sent [preauth] debug1: SSH2_MSG_KEXINIT received [preauth] debug1: kex: client->server aes192-cbc hmac-sha1 z...@openssh.com [preauth] debug1: kex: server->client aes192-cbc hmac-sha1 z...@openssh.com [preauth] debug1: expecting SSH2_MSG_KEXDH_INIT [preauth] debug1: SSH2_MSG_NEWKEYS sent [preauth] debug1: expecting SSH2_MSG_NEWKEYS [preauth] debug1: SSH2_MSG_NEWKEYS received [preauth] debug1: KEX done [preauth] Then come lines indicating a successful sign-in, which I omitted. Failing connection: debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519 [preauth] debug1: SSH2_MSG_KEXINIT sent [preauth] debug1: SSH2_MSG_KEXINIT received [preauth] no matching cipher found: client aes192-cbc,3des-cbc,blowfish-cbc,aes128-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-...@lysator.liu.se,des-cbc,des-...@ssh.com server aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com,chacha20-poly1...@openssh.com [preauth] The rest of the lines show connection run-down, omitted. The major difference that I see is that the connection that works has the line `SELinux support disabled [preauth]', and the connection that doesn't work does not have that line. What I know about SELinux is that incorrect usage could have disastrous results, so I haven't done anything with it. Do I need to change anything in my default Debian installation? Suggestions welcome.
Re: ssh Problem using it for SFTP
Hi, Steve. On 14/01/16 08:45, Steve Matzura wrote: > This is clearly the problem area. I tried some ssh option settings in > Voyager with no success. Should this client be retired? It's not > *that* old. I do not know that client, but if your users are using Firefox, maybe you could use FireFTP [1]. I never had problems with it, and we could also say that while users use Firefox, you could run it on different operating systems. Best regards, Daniel [1] https://addons.mozilla.org/en-US/firefox/addon/fireftp/ signature.asc Description: OpenPGP digital signature
Re: ssh Problem using it for SFTP
Lars, On Thu, 14 Jan 2016 12:45:09 +0200, you wrote: >Can you update the client to one that uses the safer ciphers and avoids >the deprecated ones? You and I came to the same conclusion with the same lines of log as evidence at about the same time. Amazing. Many of my users use Voyager version 15 because it's the last accessible one using a screenreader. Yes, there are several other clients, all equally accessible. I think maybe it's time to retire Voyager from my supported clients list. Too bad, really, as it has a very nice and easy-to-read (with a screenreader) file transfer status window, which is why we who use it like it as much as we do.
Re: ssh Problem using it for SFTP
Tomas, On Thu, 14 Jan 2016 05:32:04 -0500, I wrote: >debug1: Enabling compatibility mode for protocol 2.0 >debug1: Local version string SSH-2.0-OpenSSH_6.7p1 Debian-5 >debug1: permanently_set_uid: 107/65534 [preauth] >debug1: list_hostkey_types: >ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519 [preauth] >debug1: SSH2_MSG_KEXINIT sent [preauth] >debug1: SSH2_MSG_KEXINIT received [preauth] >no matching cipher found: client >aes192-cbc,3des-cbc,blowfish-cbc,aes128-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-...@lysator.liu.se,des-cbc,des-...@ssh.com >server >aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com,chacha20-poly1...@openssh.com >[preauth] This is clearly the problem area. I tried some ssh option settings in Voyager with no success. Should this client be retired? It's not *that* old.
Re: ssh Problem using it for SFTP
On 01/14/2016 12:32 PM, Steve Matzura wrote: > debug1: sshd version OpenSSH_6.7, OpenSSL 1.0.1k 8 Jan 2015 >... > debug1: Client protocol version 2.0; client software version > FTP-Voyager-15.2.0.15 > debug1: no match: FTP-Voyager-15.2.0.15 > debug1: Enabling compatibility mode for protocol 2.0 > ... > debug1: SSH2_MSG_KEXINIT received [preauth] > no matching cipher found: client > aes192-cbc,3des-cbc,blowfish-cbc,aes128-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-...@lysator.liu.se,des-cbc,des-...@ssh.com > server > aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com,chacha20-poly1...@openssh.com > [preauth] > ... Can you update the client to one that uses the safer ciphers and avoids the deprecated ones? [since 6.6] "Potentially-incompatible changes * 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..." from http://www.openssh.com/txt/release-6.7 regards, Lars
Re: ssh Problem using it for SFTP
Tomas, On Wed, Jan 13, 2016 at 07:13:57PM -0500, Steve Matzura wrote: >> I hope this isn't off-topic by too much. If it is, a word to me >> privately and I'll wait for responses to queries I've made elsewhere. >I'm not as much of an SSH guru to "get" what's going on by just reading >configs, but as a hint: there is an "-d" option to sshd which starts >it in debug mode. If you then chose a non-standard port (i.e. 2022 or >whatever seems suitable), then you can follow, on the terminal what's >going on, like so: > > sshd -d -p 2022 Brilliant! debug1: sshd version OpenSSH_6.7, OpenSSL 1.0.1k 8 Jan 2015 debug1: private host key: #0 type 1 RSA debug1: private host key: #1 type 2 DSA debug1: private host key: #2 type 3 ECDSA debug1: private host key: #3 type 4 ED25519 debug1: rexec_argv[0]='/usr/sbin/sshd' debug1: rexec_argv[1]='-d' debug1: rexec_argv[2]='-p' debug1: rexec_argv[3]='2022' Set /proc/self/oom_score_adj from 0 to -1000 debug1: Bind to port 2022 on 0.0.0.0. Server listening on 0.0.0.0 port 2022. debug1: Bind to port 2022 on ::. Server listening on :: port 2022. debug1: Server will not fork when running in debugging mode. debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8 debug1: inetd sockets after dupping: 3, 3 Connection from 192.168.1.140 port 54230 on 192.168.1.130 port 2022 debug1: Client protocol version 2.0; client software version FTP-Voyager-15.2.0.15 debug1: no match: FTP-Voyager-15.2.0.15 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.7p1 Debian-5 debug1: permanently_set_uid: 107/65534 [preauth] debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519 [preauth] debug1: SSH2_MSG_KEXINIT sent [preauth] debug1: SSH2_MSG_KEXINIT received [preauth] no matching cipher found: client aes192-cbc,3des-cbc,blowfish-cbc,aes128-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-...@lysator.liu.se,des-cbc,des-...@ssh.com server aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com,chacha20-poly1...@openssh.com [preauth] debug1: do_cleanup [preauth] debug1: monitor_read_log: child log fd closed debug1: do_cleanup debug1: Killing privsep child 7999 I understand the output, but not what's wrong and how to fix it.
Re: ssh Problem using it for SFTP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Jan 13, 2016 at 07:13:57PM -0500, Steve Matzura wrote: > I hope this isn't off-topic by too much. If it is, a word to me > privately and I'll wait for responses to queries I've made elsewhere. > > I maintain two FTP servers and support four Windows-based FTP clients > for users of those servers--FTP Voyager, FlashFXP, Filezilla, and > WinSCP. One server accepts all four clients, the other accepts all but > FTP Voyager, indicating a configuration difference. > > I've asked about this on the comp.security.ssh Usenet newsgroup, but > Usenet being what it is, I might have to wait at least a week before > getting a response of any kind, and my Voyager users are starting to > get restless for an answer as to what I did to break access for > them--i.e., they'd rather fight than switch. > > Here are the two sshd_configs without comments, greatly shortening > what you'll be looking at. I'm not as much of an SSH guru to "get" what's going on by just reading configs, but as a hint: there is an "-d" option to sshd which starts it in debug mode. If you then chose a non-standard port (i.e. 2022 or whatever seems suitable), then you can follow, on the terminal what's going on, like so: sshd -d -p 2022 If you add more "-d" (up to three), verbosity increases. regards - -- t -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlaXXfAACgkQBcgs9XrR2kabawCeOG0jJz31azT07FYqTn5fdy2Q 2EoAnjBr+V3hdioveJljEmB6bNfKtNHA =fY6r -END PGP SIGNATURE-
