sftp failed after secure shell upgrade

[Grace Li]

After secure shell upgraged to 5.30, my sftp process failed. This process is using "CuteFTP 8.0" software, authenticated by user password.

Syslog shows it ended with "subsystem request for sftp". Please help.

Secure_Shell A.05.30.008
HP-UX titan B.11.23

[Steven Schweda]

I know nothing, but if I were trying to debug
something like this, I'd start by using some
less "Cute" SFTP client program, like, say,
"sftp" on the HP-UX system itself, and adding
"-v" (or "-vv", or ...) to the "sftp" command
line.

Does plain "ssh" work on this system (now)?
If possible, I'd try to get SSH working
before moving onto some SSH-based thing like
SFTP.

[Grace Li]

I can scp / ssh login to unix server via less Graphical software, like winSCP, linux. However, this GUI software failed to login. And I have many scripts to transfer report to the UNIX server under this software. That's why I have to get it fixed.

fyi, it is called "GlobalSCAPT - CuteFTP 8.0 Professional". Since the only change is the upgrade on UNIX side, I work on this direction to check the config of ssh.

[Steven Schweda]

> [...] Since the only change is the upgrade
> on UNIX side, I work on this direction to
> check the config of ssh.

Perhaps, but if there's only one client which
has trouble, then I'd tend to worry about
that client. I'd certainly ask its vendor
about it. At the very least, I'd look for a
way to enable/save some "-v"-style diagnostic
messages from the thing. "my sftp process
failed" is not a very detailed description of
anything by itself.

http://www.cuteftp.com/

[Steven Schweda]

> [...] authenticated by user password.

You're sure that the script is using the
right password? (Of course, one might wonder
if a script using a password is a good idea.
The whole public-key authentication structure
was intended to obviate that sort of security
hole.)

> I can scp / ssh login to unix server via
> less Graphical software, [...]

As the same user which the script uses?
(Using the same password?)

[Tingli]

You can try other sftp software to see whether they work or not.

[Grace Li]

1) password and id is working.
2) because this is gui software, there is loging but it can not be tuned. here is the error log.

Can't connect to "server_name":22. SFTP21 error = #0.

3) check with the software (cuteftp) already, they claim the firewall and config of secure shell on the server side. see below.
/* ---------------------- */
CAUSE
This error is the result of a timeout of an SFTP operation. The first line of error text is irrelevant and should be disregarded. There are two known possible causes for this error:

This problem may be caused by a misconfigured firewall

[Steven E. Protter]

Shalom,

This happens from time to time.

Secure Shell is released with new security features, or flaws fixed and suddenly the client does not work.

You can back out the Secure Shell release or look for an update from the CuteFTP people. If this is being maintained they probably will provide a fix, though you may need to provide them data.

SEP

[Grace Li]

thanks. if i do a swremove, do i need to restart ssh?

[Tingli]

I am not sure whether there is an encryption cipher policy in cuteFTP. If there is, can you move the first one "AES (SSH-2 only)" down and see how it works.

[Grace Li]

before the upgrade (5.30) ssh2 works with cuteftp. we used sftp:22 to download report from unix server.

[Steven Schweda]

> 2) because this is gui software, there is
> loging but it can not be tuned. here is the
> error log.

Is that _your_ opinion, or did that nonsense
come from the CuteFTP people? I've seen many
GUI programs which can provide useful
diagnostic logs.

> This problem may be caused by a
> misconfigured firewall

Running a different SFTP client program on
the same client system could confirm or
disprove that conjecture.

[Grace Li]

Here is the log.

/**** CuteFTP 8.0 - build Feb 6 2007 ****/

STATUS:> [5/25/2010 2:02:01 PM] Getting listing ""...
STATUS:> [5/25/2010 2:02:01 PM] Initializing SFTP21 module...
STATUS:> [5/25/2010 2:02:01 PM] Resolving host name "server_name"...
STATUS:> [5/25/2010 2:02:01 PM] Host name "server_name" resolved: ip = ***.
STATUS:> [5/25/2010 2:02:02 PM] Connecting to SFTP server... "server_name":22 (ip = ***)...
ERROR:> [5/25/2010 2:02:32 PM] The file being transferred in ASCII mode appears to be a Binary file. Proceed anyway?
ERROR:> [5/25/2010 2:02:32 PM] Can't connect to "server_name":22. SFTP21 error = #0.
STATUS:> [5/25/2010 2:02:32 PM] SFTP21 connection closed.

[Tingli]

Can you run:
ldd /opt/ssh/sbin/sshd

and see what it says.

[Grace Li]

/opt/ssh/sbin/sshd:
libpam.1 => /lib/pa20_64/libpam.1
libnsl.1 => /lib/pa20_64/libnsl.1
libxnet.2 => /lib/pa20_64/libxnet.2
libsec.2 => /lib/pa20_64/libsec.2
libgssapi_krb5.sl => /lib/pa20_64/libgssapi_krb5.sl
libkrb5.sl => /lib/pa20_64/libkrb5.sl
libpthread.1 => /lib/pa20_64/libpthread.1
libc.2 => /lib/pa20_64/libc.2
libxti.2 => /usr/lib/pa20_64/libxti.2
libm.2 => /usr/lib/pa20_64/libm.2
libkrb5.sl => /usr/lib/pa20_64/libkrb5.sl
libk5crypto.sl => /usr/lib/pa20_64/libk5crypto.sl
libcom_err.sl => /usr/lib/pa20_64/libcom_err.sl
libc.2 => /usr/lib/pa20_64/libc.2
libdl.1 => /usr/lib/pa20_64/libdl.1

[Tingli]

This is what I found in the web:
CAUSE
This error is the result of a timeout of an SFTP operation. The first line of error text is irrelevant and should be disregarded. There are two known possible causes for this error:

1. This problem may be caused by a misconfigured firewall.

2. This is a known problem when using CuteFTP versions 8.0.0 through 8.0.7 and attempting an SFTP connection to a server computer running Titan FTP Server. This issue was fixed in CuteFTP 8.1.

RESOLUTION
1. Check the firewall settings and ensure that port 22 is open and enabled for SFTP transfers.

2. If you are connecting with a server computer running Titan FTP Server, update to CuteFTP 8.1 or greater.

[D. Jackson_1]

Most likely the host keys got overwritten when you upgraded.
Did you save off the files in /etc/opt/ssh before upgrading? If not pull them from backup tape and see if that helps.
These are the files I am talking about.

-rw------- 1 root sys 668 Jul 18 2006 ssh_host_dsa_key
-rw-r--r-- 1 root sys 602 Jul 18 2006 ssh_host_dsa_key.pub
-rw------- 1 root sys 975 Jul 18 2006 ssh_host_key
-rw-r--r-- 1 root sys 639 Jul 18 2006 ssh_host_key.pub
-rw------- 1 root sys 1675 Jul 18 2006 ssh_host_rsa_key
-rw-r--r-- 1 root sys 394 Jul 18 2006 ssh_host_rsa_key.pub

HTH

[Grace Li]

those files did not get updated. still original time stamp.

[Steven Schweda]

> ERROR:> [5/25/2010 2:02:32 PM] The file
> being transferred in ASCII mode appears to
> be a Binary file. Proceed anyway?

What happens when no one can answer this
question because a script is running, not an
interactive user?

What happens if you try to send a file using
binary mode, or if you try to send a file
which does not appear to be binary?

> Running a different SFTP client program on
> the same client system could confirm or
> disprove that conjecture.

Still true. Or, running the same SFTP
client program interactively, instead of
using some script. When some complex task
fails, it's often useful to fall back to
trying some simple task.



> Most likely the host keys got overwritten
> when you upgraded. [...]

What makes that "most likely"? The fact
that all the error messages fail to mention
the host keys? Or the fact that other SFTP
client programs apparently work?