Alex Brelsfoard wrote:
Though I have tried turning on the debug mode, I have not gotten any
different results (though I'm not so sure how to USE the debug mode really).
Are you saying nothing is written to STDOUT or STDERR?
SSH1.pm & SSH2.pm each have the following line:
SSH1.pm: $ssh->fatal_disconnect("Permission denied");
SSH2.pm: $ssh->_login or $ssh->fatal_disconnect("Permission denied");
Are you not sure which SSH protocol version is being used?
Try collecting some data about the target host. Run:
$ telnet host 22
and you should see something like:
Trying 0.0.0.0...
Connected to 0.
Escape character is '^]'.
SSH-2.0-OpenSSH_4.3p2 Debian-9etch2
unless they've obscured the banner, this will tell you what version of
the protocol and what software is being used to implement it. That might
provide some clues when tracking down an incompatibility with the SSH
module. Compare that to the hosts that are working OK.
I'd then check rt.cpan.org for bug reports relating to this for the SSH
module. If you determine that the SSH module is failing to login only
with a specific SSH server implementation, then you should file a bug at
rt.cpan.org.
Try coding up a simple test that uses the SSH module to login. That'll
take the SFTP module out of the picture and make it easier to debug. Try
it with both SSH1.pm and SSH2.pm. Try it first with a known working host.
-Tom
--
Tom Metro
Venture Logic, Newton, MA, USA
"Enterprise solutions through open source."
Professional Profile: http://tmetro.venturelogic.com/
_______________________________________________
Boston-pm mailing list
[email protected]
http://mail.pm.org/mailman/listinfo/boston-pm
