> Are you not sure which SSH protocol version is being used?
You should be absolutely certain whether requesting SSH v 1 (do not
use, obsolete, insecure, demonstrably breakable) or SSH v 2, **and**
which the counterparty is supporting. Commandline SSH with -v will
report all that.
> Try collecting some data about the target host. Run:
> $ telnet host 22
... > SSH-2.0-OpenSSH_4.3p2 Debian-9etch2
that will do it too
The one failing server might
* have a different brand SSH server
* or a different version
* or different SSH config
* have a different Unix (or other!) user auth system
* or different PAM settings etc
* not allow "suppress shell"
> unless they've obscured the banner, this will tell you what version of the
and if they *have* obscured it, *that* might wreck havoc with a module
if it mis-diagnoses what it's connected to ?
> I'd then check rt.cpan.org for bug reports relating to this for the SSH
always!
For scripting, SCP with keys is slicker from [kb]a?sh than Perl.
Without keys, with passwords, it's no go without an API, of course,
and dubious with one. I don't use unlocked keys across heterogeneous
organizations except in special circumstances.
In my $DayJob, we only use "approved" implementations of crypto libs,
so a Perl module that neither binds nor wraps the preferred
implementation isn't acceptable. I should try Net::SCP::Expect , as
I'd probably like that better than ksh/bash "expect", and would fit
within approvable use (assuming the license is ok).
--
Bill
[EMAIL PROTECTED] [EMAIL PROTECTED]
_______________________________________________
Boston-pm mailing list
[email protected]
http://mail.pm.org/mailman/listinfo/boston-pm
