[SGVLUG] SSH Keys / Trusted Authentication

[Claude Felizardo]

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