Single User: Password or Certificate

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View -

I've read numerous threads debating the merits of client certificates
vs. passwords in SSH.  I'm a novice to SSH and will soon be leasing a
server that uses openssh as a connection protocol.  If there are only
a handful (less than five) technical users who will need direct access
to the box, are there any benefits to using client certificates over

Thank you,

Re: Single User: Password or Certificate

Quoted text here. Click to load it

You don't give a lot of detail, so I'll assume that you'll be the
sysadmin (the only one who knows the root password), and that the
others are normal users, each with his/her own account (username, home

If you use passwords, then as sysadmin you can enforce good password
policy, including length, using special characters, forced changes at
intervals, etc.  However, these passwords are sent over the network
(in encrypted form), and the users could easily give them to others or
write them down and leave them available to others.

If you use ssh key pairs (I assume that's what you mean by
certificates), then as sysadmin you cannot enforce how the user's
private key (the one kept on his/her local machine) is encrypted.
They can have weak or strong passwords, or even no passwords.  If they
have no or weak passwords, then if someone else gets use of the users'
local machine, then they can use that users' account.

However, this password is never sent over the network (instead, the
encrypted key is sent), and giving the key to others is a little more
difficult because it's a file on the users' local machine.

Also, as sysadmin, with keys you could enforce using only certain
commands, which you can't do with passwords.

I think it depends on how much you trust your users to help maintain
a secure operation.

The book _SSH, The Secure Shell_, by Barrett & Silverman (O'Reilly),
is a great intro and reference for all of this.


Re: Single User: Password or Certificate

Dale Dellutri wrote:
Quoted text here. Click to load it
I can tell you that as a Sysadmin, if I trust the user, they are getting
keys.  It is MUCH easier on me and on them.  The user can execute
commands remotely, or in scripts.  I don't have to worry about helpdesk
calls for password resets etc.  Using public-key authentication unlocks
some real power in the form of OpenSSH.

Re: Single User: Password or Certificate

Quoted text here. Click to load it

Yes - not only is it best practice to use PPK's (IMHO) but by mandating the
use of passphrases and deploying Pageant (or ssh-agent etc) you can reduce
the input of the passphrase to a single event.  This in my view makes long
passphrases acceptable in a practical way and so further enhances security.
BTW root should be denied key or no key!

Cheers, Frank.

Re: Single User: Password or Certificate (Josh) writes:
Quoted text here. Click to load it

i tend to strongly favor public/private key for authentication ...
however there can be a big distinction between public/private
key systems and certificate-based systems.

basically you can use current business processes and register public
keys in lieu of passwords. when the far-end gets a digital signature
... they look up the appropriate user, pull out their public key and
verify the digital signature. the validation of the digital
signature implies some form of authentication. ... out of 3-factor

* something you know
* something you have
* something you are

if you have your private key in an encrypted software file ... then
the validation of the digital signature can imply "something you
know" authentication; since you needed to supply the correct
decryption key/phrase to enable the private key. if you have your
private key in a hardware token, then the validation of the digital
signature can imply "something you have" authentication (and possibly
two-factor, "somethin you know" also ... if the hardware token
requires a pin/password).

the validation of the digital signature implies some form of
authentication ... but it is the busines process surrounding the
management of the private key that actually determines what exactly
the validation of the digital signature actually implies.

all of this is pretty much totally orthogonal to the standard use of
certificates. typical use of certificates is where a relying party
(far-end) has some relationship with a certification authority ... but
has absolutely no knowledge about the owner of the public/private key
pair. instead of the far-end (relying-party) registering a public key
in association with something like a userid .... the far-end has had
absolutely no knowledge about the entity originating the digital
signature. for this sort of authentication process ... the originator
packages the digital signature with a certificate and sends it off to
the far end. at the far end ... they valicate the digital certificate
(as having originated from a known, trusted certification authority)
and then rely on the contents of the digital certificate to provide
all information about the originator (w/o even needing predefined
userid or account definition). The certificatation authority that
originates the digital certificate is responsible for supplying all
the information about the originator.

Note however, digital certificates typically still don't deal with
what the validating of a digital signature implies ... as in what
form(s) of authentication can be assumed from validating a digital

random past posts about certificate-less public key operation

Anne & Lynn Wheeler | /

Re: Single User: Password or Certificate

re: Single User: Password or Certificate

for a little more topic drift, i recently saw a demo of the lexus
smartkey, basically if you have it in your pocket ... it lets you open
a (locked) door and turn the ignition. basically it is as much a
form of

* something you have

authentication ... as a regular key. one issue is that it is a lot
larger (and integrated into the remote unlock token). i have no idea
if it is easier or harder to counterfeit than regular key.

basically passwords have been form of

* something you know

authentication and also a "shared-secret"

where every unique security domain has requiremetns about unique
shared-secrets for every unique environment (avoiding cross-security
domain contamination ... like betweeen local garage ISP and your
online banking or employee access).

the issue with real hardware tokens & "shared-secrets" is that the
concept of perpetuating a unique hardware token per environment

I once went around a smartcard show and commented to people in the
booths that if the current smartcard approach (institutional-centric
with unique cards to every individual by every institution) ever
became succesful ... it might be a return to the mid-80s
copy-protection scheme of requiring a unique floppy disk inserted in
the floppy drive for every application (the prospect of being faced
with scores of cards).

the public/private key issue with hardware tokens has a number of

1) the same public key can be registered in different security domains
... and it is not possible for individuals in one security domain,
knowing your public key ... from impersonating you in a different
security domain. this is somewhat a common form of identity theft
where there is heavy reliance of the same (shared) secrets used
in lots of different places.

2) succesful uptake of institutional-centric token paradigm could lead
to individuals requiring scores of institutional specific tokens

a hardware token with a public/private key implementation (which is
totally orthogonal to the issue of whether the paradigm has certificates
or totally certificateless operation) can

1) hardware token represents "something you have" authentication

2) relying party having some certified evidence of hardware token
requiring a PIN to operate, can assume that there has been
"something yoi know" authentication (without the relying party
needing to know what the actual PIN is ... so it can be secret
based w/o it having to be shared-secret based)

3) registration of the public key and being able to validate the
digital signature ... can imply that there has been "something you
have" as well as "something you know" authentication (as long as the
relying party as certified evidence as to the operational
characteristics of the hardware token).

with respect to SSH and public key authentication ... the same
protocol can work whether

* the private key is software-based (and the relying party can only
assume non-shared-secret, but secret pin-based, "something you know"
authentication by validating a digital signature) or

* two-factor authentication and the private key is hardware token

the public/private key protocol part of ssh can address exploit issues
like things related to shared-secret vis-a-vis non-shared-secret and
evesdroping and replay attacks. what the protocol doesn't tell the
relying party is what does the validation of the digital signature
with the public key actually imply with regard to 3-factor
authentication issues.

the trust and assurance that a relying party can place in the
validation of a digital signature ... requires the relying party
having some knowledge of the environment that originated the digital

just validating a digital signature with a public key, by itself,
doesn't establish whether it represents one-factor, two-factor or
possibly even three-factor authentication and/or what of the

* something you have
* something you know
* something you are

might be involved.

so i'm wondering if i can have a single individual-centric smartkey
someday ... where the same smartkey will let me open all possible
doors that i might need to open (vehicle, home, office), use my pc,
perform electronic commerce transactions, etc, ... and possibly even

Anne & Lynn Wheeler | /

Site Timeline