Sftp application error

Rocky Linux General
1

Environment:

cat /etc/os-release

NAME=“Rocky Linux”
VERSION=“8.6 (Green Obsidian)”
ID=“rocky”
ID_LIKE=“rhel centos fedora”
VERSION_ID=“8.6”
PLATFORM_ID=“platform:el8”
PRETTY_NAME=“Rocky Linux 8.6 (Green Obsidian)”
ANSI_COLOR=“0;32”
CPE_NAME=“cpe:/o:rocky:rocky:8:GA”
HOME_URL=“https://rockylinux.org/”
BUG_REPORT_URL=“https://bugs.rockylinux.org/”
ROCKY_SUPPORT_PRODUCT=“Rocky Linux”
ROCKY_SUPPORT_PRODUCT_VERSION=“8”
REDHAT_SUPPORT_PRODUCT=“Rocky Linux”
REDHAT_SUPPORT_PRODUCT_VERSION=“8”

When connecting to a particular sshd host and respond to the password prompt I receive an application error and disconnect as soon as I enter any string and press enter. It does not matter whether the password is correct or not.

debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
hpa3000@fileserver.stromasys.com's password: 
debug3: send packet: type 50
debug2: we sent a password packet, wait for reply
debug3: receive packet: type 1
Received disconnect from 1.2.3.4 port 22:11: Application error
Disconnected from 1.2.3.4 port 22
Connection closed

I can successfully sftp to other password protected remote sites that run a variety of OS’. However, I am informed by another user that they can connect via sftp to 1.2.3.4 without problems from different sites.

I am confused as to what might be happening much less how to solve it. Has anyone got any ideas?

2

Hi,

What client/application are using for SFTP?

Are you able to ssh in?

Thanks Tom.

3 
# command -v sftp
/usr/bin/sftp

Yes, I can ssh/sftp in, however that is not the issue. I can ssh and sftp out, just not to this specific remote host. However, it is reliably reported to me that host is reachable via sftp from other sites.

The versions of local and remote are:

debug1: Local version string SSH-2.0-OpenSSH_8.0
debug1: Remote protocol version 2.0, remote software version mod_sftp/0.9.9
4

The question was: “Can you ssh hpa3000@1.2.3.4?”
Can you do it “from other sites”?

If the Rocky is your client machine, then you could run dnf up, because Rocky 8.7 is out already.

1 Like
5

You might also try to increase the verbosity of your debug. It looks like you pass a single -v, is that correct? If so, you can try logging in with additional verbosity (ie. -vvv) so that the debug is longer, and perhaps more helpful.

6

I used sftp -vvv to conect for the example. I just trimmed off everything before the password section.

7

Logically, there are three suspects:

  • Your client machine has something that fails to negotiate
  • The server has rules about your IP and/or account
  • Someone in between (you apparently can talk some, so should not be issue here)
8

I suspect that there is some sort of firewall issue at the remote end. I tried to connect to that service from a remote host on a different network and the connection times out. NMAP reports p22 as filtered from that origin. When I run NMAP locally the port is open (as logically it must be to connect).

I have connected to the problem host from two different OS’s with exactly the same result. It would be odd if both clients had exactly the same problem.

Different hosts different sftp versions.

debug1: Local version string SSH-2.0-OpenSSH_8.0
debug1: Remote protocol version 2.0, remote software version mod_sftp/0.9.9

debug1: Local version string SSH-2.0-OpenSSH_7.9 FreeBSD-20200214
debug1: Remote protocol version 2.0, remote software version mod_sftp/0.9.9
9

I discovered that this issue is caused by ProFTPD’s mod_sftp. It does not handle the certificate negotiation well. This may be a flaw in coding or a timeout issue being triggered where more than one certificate is offered by the client. In this case the fix was to use the PreferredAuthentications=password option with the sftp client.:

sftp -o PreferredAuthentications=password user@host.domain

2 Likes