SFTP used by 3rd-party software: IP*Works

[Dan Vowell]

I have a mix of HP-UX 11i and RHEL 4 servers that can successfully transfer files securely using "sftp" from the command-line. But, when a scripted login is attempted by a 3rd-party software package (IP*Works), the login fails.

Logfile is attached.

Any thoughts on why the command-line method works and the IP*Works method fails?

Thanks

[Jim Walls]

It could be a buffering issue... or possibly the script is supplying the password too quickly. The Username/Password authentication dialogue is conducted directly with the tty stream and not via STDIN.

It is more common to use SSH keys for automated file transfers with sFTP and SCP.

[Mel Burslan · Accepted solution]

3rd party ssh clients and servers for that matter, sometimes use a different formatted keys and/or different handshake sequences and cause failures like you have encountered. I am not familiar with IP*works suite of tools but we had a very similar issue with ssh and scp in the past where the vendor we were trying to connect to, was using a different and proprietary ssh server, which did not like the authentication attempts from openssh client we were using.

Short of contacting the support for IP*works software vendor, your chances of finding someone here using the same setup, is quite slim, if you ask me.

Good luck

Mel

[Dan Vowell]

Thanks, Mel

I think you're probably right about the key exchange from the IP*Works 3rd-party software, since regular "sftp" sessions from the command-line work fine, regardless of OpenSSH versions and OS-plaforms (HP-UX, Red Hat, etc).

Just needed to validate that I wasn't the one going crazy...... :-)

[RC Park]

Hi, Dan -

Just curious, when you do your command-line work, do you manually have to enter a password, or are you trying to use a script that somehow passes it? I am quite certain that the ssh version on hp servers doesn't support sending passwords via scripts; kinda defeats the whole "secure" thing since your session isn't yet encrypted, and your password would be sent in clear text. Your only "safe" solution is as already suggested, setting up keys. Are you familiar with that process? Once complete, we were able to do some rather complex batch operations using sftp - in automated scripts run by a job-scheduler, so it can be done... with KEYS. If someone has figured out a way to send a password via a script with an ssh/sftp session, please post the answer here!!

-Russ

[Steven Schweda]

> [...] IP*Works [...]

Sounds like a misnomer.

> [...] I am quite certain that the ssh
> version on hp servers doesn't support
> sending passwords via scripts; kinda
> defeats the whole "secure" thing since your
> session isn't yet encrypted, and your
> password would be sent in clear text. [...]

I'm pretty confident that you're wrong. As
"ssh -v" output would suggest, the
cipher/encryption stuff is negotiated between
the client and server before any
authorization activity occurs, so I believe
that password (interactive) authentication is
done over a secure channel. (Thus, I claim,
my "pretty confident" plus actual evidence
beats your "quite certain" with none.)

I haven't tried it, but I also suspect that
one could use a program like "expect" to run
the "ssh" client on HP-UX with simulated
interactive input, allowing one to use ssh
_and_ have a user name and password stored in
a file, no matter how lame an idea that might
be. The "ssh" server, on the other hand,
would have no idea if there's a live user on
the client side, so it wouldn't care, either.

[RC Park]

@Steven
I definitely most certainly could be wrong :)

... but, I will verify what you are saying re the behavior of ssh and the stages where a stored password would be sent - makes some sense, but for the curious, I'll dig a little.

I don't show a star or crown by my name, so none should take me *too* seriously - yet... But I would only argue this - drop 3rd party(? - does hp include this in its apps dvd's?) tools like expect and deal just with what's commonly available via the OS/command line and I'd like to know what one could do to pass a stored password. I've needed this ability in the past, and may yet once again, so if "expect" is the only answer here, then fine, but I wasn't considering it in my comments.

More specifically, I wanted to know what Dan was trying to do (i.e., was the described activity manual, including the entering of a password that he now wants to automate), so clarification from him would be interesting going forward with this thread.

-RCPark

[Dan Vowell]

If I understood the customer correctly, the IP*Works product was submitting the password on behalf of the application (down a secure channel, of course). But the session log still shows it in clear text (oops). I'm in favor of using the OpenSSH product that comes standard with HP-UX, unless the vendor for this 3rd-party package can chime in with "best practices" configuration file(s) guidelines.