The SSH client plink (from PuTTY), can take the password from the command line... but I guess you will not be able to install that either!
In order to automate the SSH login process, you need to allocate a pair of master/slave pseudo-ttys and set the slave as the controlling terminal of the SSH process.
From Perl this can be done with IO::Pty, usually wrapped by the higher level Expect module. I don't believe you can do the same using core modules only.
| [reply]
[d/l] |
What OS will the client run on? OS for the Server? Which SFTP server?
I just did this but with 3rd party software on both sides in a Microsoft environment. VanDyke is the vendor. I had to use a system call with a command line utility. The passwords get encrypted and saved in a session. The name of the session is passed to the command line tool.
| [reply] |
Client OS is Sun, remote I'm not sure on but since they had been using NcFTP I'm assuming it's Linux but I could be wrong.
| [reply] |
Wow, those are some serious restrictions! So create a batchfile for the sftp comamnds you need to run and then try running sftp like so: 'echo "$password" | <:sftp_command>' and see if you can get away with it. Messy, ugly kludge for a messy, ugly situation.
Elda Taluta; Sarks Sark; Ark Arks
| [reply] |
Cut and paste the code Net::SFTP into the file that you may install. (If you cannot install any file, one wonders why you are being payed...) | [reply] |
(If you cannot install any file, one wonders why you are being payed...)
It's interesting how there are all these rules, suggestions, etc. for security policies with little scientific evidence to back them up and when there is evidence that contradicts the policy that evidence is just ignored. An obvious example is requiring users to have complex passwords that they have to frequently change -- turns out that most users just write the password down on an easy to find post-it note.
Or in this case, instead of relying on fairly robust, mature code, programmers are forced to reinvent the wheel, which in the long run results in a ton of less secure proprietary code. No surprise since the people creating the policies are thinking more about the individual systems instead of how they are networked together. So by trying to keep external code out, in the long run these policies create a new attack vector -- the kludged code that programmers had to write in lieu of the better code they wanted to use.
Not to mention that the OP is going to have to store the password somewhere.... How is is that better than using keybased authentication? Sounds like if someone gets the password, they get a regular shell on the other system. Why not just create a special account there running a restricted shell and use keybased auth? But no, requiring a password is more secure.....
Elda Taluta; Sarks Sark; Ark Arks
| [reply] |