[SGVLUG] SSH Keys / Trusted Authentication

[Emerson, Tom]

Hmmm... I think I see something subtle...

> -----Original Message----- Of Sean O'Donnell
> 
> I did notice a failure when logging in to ssh in verbose 
> mode, that I didn't receive (or perhaps notice) yesterday... 
> 'debug1: PEM_read_PrivateKey failed'
> 
> Here is the log, just in case...
> 
> OpenSSH_4.3p1, OpenSSL 0.9.7e 25 Oct 2004
[...]
> debug1: Authentications that can continue: 
> publickey,password,keyboard-interactive
> debug1: Next authentication method: publickey

OK, so it's going to try the keys you've set up...

> debug1: Offering public key: /home/myid/.ssh/id_rsa
> debug1: Server accepts key: pkalg ssh-rsa blen 277
> debug1: PEM_read_PrivateKey failed

However a straight read of the key file failed, SO...

> debug1: read PEM private key done: type <unknown>
> Enter passphrase for key '/home/myid/.ssh/id_rsa':

THIS IS THE SUBTLE part: note it is asking for the passphrase of your
KEY, not the PASSWORD OF THE REMOTE SERVER...

> debug1: read PEM private key done: type RSA

Here you've entered the key, and *I SUSPECT* the "passphrase" you have
for your key IS ALSO THE PASSWORD you are using on the remote system
[what do I win?]

> debug1: Authentication succeeded (publickey).

THIS TIME the "read" process succeeds, and sure enough the remote server
did indeed use your private key.

Unfortunately, using a private key doesn't avoid a password/passphrase
-- it only transfers which system asks for the information.  In order to
not be prompted, your private key needs to not have a passphrase
associated with it.  [why would anyone do this?  It makes /some/ sense
for automated processes and/or unattended servers.  In these cases, the
private key should only be "readable" by it's creator; and in turn the
"creator" needs to be a process without shell access so a "real person"
cannot log on as that ID and read the file...]

I can't remember offhand, but does SSH have something similar to
gpg-agent?  Gpg-agent acts as a go-between between the user and any
process trying to read your .secring; it caches the "key" for a set
period of time (such as 5 minutes) so that you enter your password once,
and for the next few minutes any process that needs you to "unlock" the
key will succeed without prompting you.  In your example, a checkin/out
operation ends up prompting for the passphrase a half dozen times, which
I would imagine happens over the span of no more than a minute, right?
In this case, an "agent" program would prompt you once and supply the
unlocked private key for the remaining 5 or 6 connections...

[oh, wait, I see that at the end of Claude's response, so...]