Phoenix.pm: open sesame

[Kevin Buettner]

On May 19,  8:15pm, Pablo at zunigatech.com wrote:

> Here's what I've tried so far:
> ----------the script:
> 
> #!/usr/bin/perl-wT
> 
> $ENV{"PATH"} = "";
> 
> use strict;
> 
> open(SSH, "| /usr/bin/ssh -c 3des -l username 127.0.0.1");
> print SSH "my_password";
> close(SSH);
> 
> ----------and what I get in response:
> 
> [terminal]# perl s_download_db.cgi  (here I execute the script)
> 
> Pseudo-terminal will not be allocated because stdin is not a terminal.
> username at 127.0.0.1's password: 
> 
> ------------
> 
> I'm wondering how I could "give" SSH the password? 

In order to make this work, you'll need to use IO::Pty.

However, I don't think it's really a good idea to encode your
password or your passphrase in your script.

A better approach (which also won't require the use of IO::Pty) would
be to use ssh-keygen to generate a pair of authentication keys which
are protected by a passphrase.  Once this is done, you can add the
public key to ~/.ssh/authorized_keys on the remote machine.  And then
you can use ssh-agent (and ssh-add) on the local machine to run
commands on the remote machine without being continuously prompted for
a password on the local machine.

Note that you will have to enter a passphrase when you run ssh-add,
but you will do this interactively and it will not appear in any
script.  This means that your passphrase is still protected.  You are
able to run automated scripts because ssh-agent manages your
authentication for you (once the passphrase has been added via
ssh-add).

See the man page for ssh, ssh-keygen, ssh-agent, and ssh-add for
more information.

I have a perl script which finds a running ssh-agent process and sets
up the appropriate environment variables if you're interested.  (This
is useful if you tend to run ssh-agent after you've started your X
session and want several shells to use the same authentication
daemon.  It could also be used by cron scripts to find a preestablished
agent.)  Let me know if you want it.

Finally, I'll note that it is possible to use ssh-keygen to generate a
public/private key that is unprotected by a passphrase.  You will want
to think long and hard about what you're doing before doing this
because this means that if someone compromises an account that has
such a key pair, your account on the remote machine(s) are compromised
as well.  OTOH, with ssh-agent, you have the ability to add and remove
keys at will, so the truly paranoid would run ssh-agent, run the
(possibly automated) ssh commands, and finally run "ssh-add -d" to
remove the identity added by the first ssh-add command.

Kevin

-- 
Kevin Buettner
kev at primenet.com, kevinb at redhat.com