[SGVLUG] SSH Keys / Trusted Authentication

Tue May 9 15:05:17 PDT 2006

Thanks for all of your input and help folks.

I was able to get the 'trusted' authentication mechanism back into
place, and it sure has made my day much more productive. 

It has also made things much less strenuous/repetitious for my wrists,
as I don't have to type my password 6+ times when pushing builds to our
qa/production server(s). *yay* =)

I'm afraid that the problem was the .ssh directory permissions, as it
should have been set to 0700 (on both systems). *doh*

Anyhow, lesson learned! =)

Thanks,

Sean O'Donnell
Programmer Analyst (PHP)
Children's Oncology Group (COG) 
CureSearch Technology Group (CTG)

440 E. Huntinton Dr. 2nd Floor
Arcadia, CA 91066

[office] (626) 241-1752
[email] sodonnell at cogmembers.org

PGP Public Key: 0xE6A0E96C
PGP Public Key Server: http://pgp.mit.edu

----
-----Original Message-----
From: sgvlug-bounces at sgvlug.net [mailto:sgvlug-bounces at sgvlug.net] On
Behalf Of Claude Felizardo
Sent: Thursday, May 04, 2006 6:23 PM
To: SGVLUG Discussion List.
Subject: Re: [SGVLUG] SSH Keys / Trusted Authentication

On 5/4/06, Emerson, Tom <Tom.Emerson at wbconsultant.com> wrote:
> 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

note this line.  it says it will try public key first (with possible
pass-phrase, then password of the remote machine, then because you must
have tried this on the console, it will fall back to the keyboard.  if
you connect remotely, you won't get this 3rd option. 
The use of these options are controlled by the various ssh config files.

> > 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...

I'm assuming this is failing here because you have a pass-phrase with
your key and it is not currently cached by ssh-agent or equiv.

> > 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...

right, the publickey failed so it'll try the next one which is the
regular password of the remote machine.

> > 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.

right.  this is accepted so it won't bother with the
keyboard-interactive option.

> 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...]

read up on ssh-agent and ssh-add.

Any child process of the process that is running ssh-agent will be able
to ask the agent for the pass phrase.  You enter this once and not have
to enter the pass-phrase again until you log out or remove the key from
the agent.

There are also ssh-add options to lock/unlock the agent as well as set a
lifetime on  keys.

this is how I currently operate on my linux desktop at work:

1) At login, ssh-agent is run and the X server is started as a child
process.
2) at some point, i run ssh-add from an xterm (or equiv) that is
itself a child process of my X server.   I add my key to the agent. 
If the key has a pass-phrase, it prompts me at this point.
3) whenever i run ssh (including via cvs) in a child process, it gets
the key from the agent.

By caching my key, I can do all the cvs commands I want and not have
to enter a password or pass-phrase for days at a time.   Most of the
people on my team have not gotten this to work so they use 'cvs diff'
as often as I do.

I always use a pass-phrase with all my keys in case a machine get's
broken into and keys are stolen.  This has happened on various unix
clusters and it's a pain to have to go through and replace all the keys.
The last time this happened, as soon as possible, the SA's moved
everyone's .ssh/ssh2 directories out of the way to prevent automatic
logins.

As long as my screenlock kicks in and doesn't crash, i'm pretty secure.
I'm the only one with root on this box.  If I'm going to be away for a
while and don't want to log out of my desktop then I might manually
remove my key using 'ssh-add -d'.

For machines where other people have root, I of course use ssh-keys w/
pass-phrases to connect to other machines in the "cluster" (ie, they
share the same yp/nis ldap info) but I do not use the same key to
connect to my desktop nor for connecting home or to any other non work
related machine.

I do not cache my non work related keys.  When I do offsite backups I
enter pass-phrases manually but most of time I rely on the backups done
by the SA's.

If I ever decided to implement automatic offsite backups, then I'll have
to investigate the use of restricting the ssh command that may be
used and possibly storing the pass-phrase in an encrypted file.   The
point being they'd need more than one file but I have not tried this
yet.

I know one guy, he was so paranoid, he would never enter a pass-phrase
on a machine that he did not self-administer in case someone was logging
keystrokes.  As for myself, I only allow connections from
specific hosts.  At home I also use a non standard port.   One of
these days I'll implement port knocking so i can connect from unexpected
places.

claude