wdoe999@yahoo.com wrote:
> I want to have scripts that login to a remote linux machine without
> having plain text passwords in the scripts. I just spent an agonizing
> evening trying to get slogin to work (it supposedly works without
> passwords). After all that work, slogin keeps asking me for a
> passphrase. I'm back to square-one with a plain text passphrase in the
> script. Apparently, I can have a script put the passphrase into
> ssh-agent (again back to square-one).
>
> Am I reading things wrong or is it a total fallacy that slogin allows
> you to getaway without a password or passphrase?
>
> I find it bizarre that, after all the work of putting keys on both
> machines, that you have to go all the way back to the passphrase???
> The two keys should be more than secure enough. It's like putting a
> steel vault door on the front of your house, while leaving the back
> door open!!!

Use public key authentication.
Don't put a passphrase on the key.

At 4 Jan 2007 20:01:29 -0800 wdoe999@yahoo.com wrote:

>
> I want to have scripts that login to a remote linux machine without
> having plain text passwords in the scripts. I just spent an agonizing
> evening trying to get slogin to work (it supposedly works without
> passwords). After all that work, slogin keeps asking me for a
> passphrase. I'm back to square-one with a plain text passphrase in the
> script. Apparently, I can have a script put the passphrase into
> ssh-agent (again back to square-one).
>
> Am I reading things wrong or is it a total fallacy that slogin allows
> you to getaway without a password or passphrase?

You need to run ssh-keygen on the source machine and copy/append the
public key file generated to the target machine's .ssh/authorized_keys2
file. Don't enter a passphrase (just press return) when ssh-keygen asks
for one.

You should only do this for trusted machines of course.

>
> I find it bizarre that, after all the work of putting keys on both
> machines, that you have to go all the way back to the passphrase???
> The two keys should be more than secure enough. It's like putting a
> steel vault door on the front of your house, while leaving the back
> door open!!!
>
>

--
Robert Heller -- 978-544-6933
Deepwoods Software -- Linux Installation and Administration
http://www.deepsoft.com/ -- Web Hosting, with CGI and Database
heller@deepsoft.com -- Contract Programming: C/C++, Tcl/Tk

http://www.snailbook.com/faq/no-passphrase.auto.html

--
Richard Silverman
res@qoxp.net

Allen Kistler wrote:

>
> Use public key authentication.
> Don't put a passphrase on the key.

Too dangerous for my liking. Anyone who gets access to the file can
authenticate as you for as long as the keypair exists and never needs to
know a passphrase. ssh-agent or keychain is safer.

Chuck wrote:
> Allen Kistler wrote:
>
>> Use public key authentication.
>> Don't put a passphrase on the key.
>
> Too dangerous for my liking. Anyone who gets access to the file can
> authenticate as you for as long as the keypair exists and never needs to
> know a passphrase. ssh-agent or keychain is safer.

With ssh-agent and keychain, you still need to enter a password to
unlock the key once every time you login. The OP considers once to be
one time too many. He needs zero so automated processes can launch ssh
sessions.

>>>>> "AK" == Allen Kistler writes:

AK> Chuck wrote:
>> Allen Kistler wrote:
>>> Use public key authentication. Don't put a passphrase on the key.
>> Too dangerous for my liking. Anyone who gets access to the file
>> can authenticate as you for as long as the keypair exists and never
>> needs to know a passphrase. ssh-agent or keychain is safer.

AK> With ssh-agent and keychain, you still need to enter a password to
AK> unlock the key once every time you login. The OP considers once
AK> to be one time too many. He needs zero so automated processes can
AK> launch ssh sessions.

Another approach is to have the automated processes use an agent, which is
loaded once by a human with a passphrase. Means someone has to redo that
when the machine reboots, of course.

--
Richard Silverman
res@qoxp.net