ssh Problem using it for SFTP

[Steve Matzura]

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.

First, the one that accepts all four clients:

SyslogFacility AUTHPRIV
PermitRootLogin without-password
AuthorizedKeysFile .ssh/authorized_keys
PermitEmptyPasswords no
PasswordAuthentication yes
ChallengeResponseAuthentication no
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes
UsePAM yes
X11Forwarding yes
Compression delayed
Banner /etc/issue.net
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY
LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE
AcceptEnv XMODIFIERS
Subsystem sftp internal-sftp
ListenAddress ::
ListenAddress 0.0.0.0

Now, the one from the server that won't accept SFTP-over-ssh
connections from FTP Voyager:

Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
UsePrivilegeSeparation yes
KeyRegenerationInterval 3600
ServerKeyBits 1024
SyslogFacility AUTH
LogLevel INFO
LoginGraceTime 120
PermitRootLogin without-password
StrictModes yes
RSAAuthentication yes
PubkeyAuthentication yes
IgnoreRhosts yes
RhostsRSAAuthentication no
HostbasedAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
AcceptEnv LANG LC_*
Subsystem sftp internal-sftp
UsePAM yes
Match Group documenters
ChrootDirectory /home/documenters
AllowTCPForwarding no
X11Forwarding no
ForceCommand internal-sftp

At first, I thought the problem has to do with the stanza beginning
with the MatchGroup directive, so I commented it out. The problem
didn't go away, and I don't perceive any differences between the two
configurations except maybe a few options that are defined explicitly
which are already at their default values according to the ssh
documentation.

Any help greatly appreciated, on- or off-list.

[to...@tuxteam.de]

-----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-----

[Steve Matzura]

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,rijnda...@lysator.liu.se,des-cbc,des...@ssh.com
server
aes128-ctr,aes192-ctr,aes256-ctr,aes12...@openssh.com,aes25...@openssh.com,chacha20...@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.

[Lars Noodén]

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,rijnda...@lysator.liu.se,des-cbc,des...@ssh.com
> server
> aes128-ctr,aes192-ctr,aes256-ctr,aes12...@openssh.com,aes25...@openssh.com,chacha20...@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

[Steve Matzura]

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,rijnda...@lysator.liu.se,des-cbc,des...@ssh.com
>server
>aes128-ctr,aes192-ctr,aes256-ctr,aes12...@openssh.com,aes25...@openssh.com,chacha20...@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.

[Steve Matzura]

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.

[Daniel Bareiro]

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/

[Steve Matzura]

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 zl...@openssh.com
[preauth]
debug1: kex: server->client aes192-cbc hmac-sha1 zl...@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,rijnda...@lysator.liu.se,des-cbc,des...@ssh.com
server
aes128-ctr,aes192-ctr,aes256-ctr,aes12...@openssh.com,aes25...@openssh.com,chacha20...@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.

[Steve Matzura]

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).

[Steve Matzura]

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?

[Steve Matzura]

One more piece of the puzzle. The working system is Red Hat Fedora 20,
the non-working one is Debian 8.2.

[Brandon Vincent]

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.

[Daniel Bareiro]

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

[Daniel Bareiro]

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,rijnda...@lysator.liu.se,des-cbc,des...@ssh.com
> server
> aes128-ctr,aes192-ctr,aes256-ctr,aes12...@openssh.com,aes25...@openssh.com,chacha20...@openssh.com

> The rest of the lines show connection run-down, omitted.

Hmmmm... 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
curve255...@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

[Steve Matzura]

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.

[Steve Matzura]

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.