sftp failed after secure shell upgrade

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