Re: Single User: Password or Certificate

From: Michael Stahnke (mastahnke_at_yahoo.com)
Date: 12/03/04

  • Next message: Jonathan Abbey: "Re: Strange SSH halting problem between Fedora Core 2/Fedora Core 3"
    Date: Fri, 03 Dec 2004 16:12:31 GMT
    
    

    Dale Dellutri wrote:
    > On 3 Dec 2004 06:06:15 -0800, Josh <josh@uronline.net> wrote:
    >
    >>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
    >>passwords?
    >
    >
    > 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
    > directory).
    >
    > 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.
    >
    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.


  • Next message: Jonathan Abbey: "Re: Strange SSH halting problem between Fedora Core 2/Fedora Core 3"

    Relevant Pages

    • Re: Single User: Password or Certificate
      ... > I've read numerous threads debating the merits of client certificates ... > vs. passwords in SSH. ... passphrases acceptable in a practical way and so further enhances security. ...
      (comp.security.ssh)
    • Single User: Password or Certificate
      ... I've read numerous threads debating the merits of client certificates ... vs. passwords in SSH. ... server that uses openssh as a connection protocol. ...
      (comp.security.ssh)
    • Re: What If
      ... :>:file to another individual and the sysadmin baulked because the other ... :>:concern was somewhat justified because the city attorney is supposed ... :> That would be a neat trick, since the passwords AREN'T IN the ... I'm curious why you think they should have been "listening to the ...
      (sci.military.naval)
    • Re: Chage passwords in script without expect
      ... John C. Linford wrote: ... you *are* the sysadmin. ... at your disposal to get default passwords in for the new ...
      (comp.unix.solaris)
    • Re: Passwords on XP accounts
      ... > Specified domain either does not exist or could not be contacted. ... > try again or consult your sysadmin." ... >> I put in five names but no passwords. ...
      (microsoft.public.windowsxp.setup_deployment)