Linux - Server This forum is for the discussion of Linux Software used in a server related context. |
Notices |
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Are you new to LinuxQuestions.org? Visit the following links:
Site Howto |
Site FAQ |
Sitemap |
Register Now
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
|
 |
04-11-2011, 01:09 PM
|
#1
|
Member
Registered: Nov 2010
Posts: 33
Rep:
|
SSHD "2 factor" authentication (With Password & public key)
Hey,
I'm trying to lock down a few of our servers and I wondered if it was possible to set up "2 factor" authentication for some accounts on the server.
By 2 factor authentication I mean one could only log on if;
1) the server already had the clients id_rsa.pub in it's authorized keys
and
2) the user knew the password
But I only want to do it for some user accounts (I.E. we have nagios and git accounts which we want to authenticate with public keys only)
Is this even possible? Any advice on where to start?
-Sam
|
|
|
04-11-2011, 04:43 PM
|
#2
|
Member
Registered: Apr 2011
Location: Jakarta, Indonesia
Distribution: Fedora, CentOS
Posts: 122
Rep:
|
Hi Sam,
just to paraphrase your thought; you want your server to only accept any ssh connection from clients that matched 1) private/public key OR 2) password, and you want to deny access from any client that is not explicitly allowed to log in through ssh.
If this is the case, you can add to your server's sshd_config with the following rule :
AllowUsers user1 user2 user3
Hope it may helped you.
----
sibe
|
|
|
04-11-2011, 10:01 PM
|
#3
|
Member
Registered: Nov 2010
Posts: 33
Original Poster
Rep:
|
Quote:
Originally Posted by sibe
Hi Sam,
just to paraphrase your thought; you want your server to only accept any ssh connection from clients that matched 1) private/public key OR 2) password, and you want to deny access from any client that is not explicitly allowed to log in through ssh.
If this is the case, you can add to your server's sshd_config with the following rule :
AllowUsers user1 user2 user3
Hope it may helped you.
----
sibe
|
Sorry maybe I didn't explain clearly enough,
the server should only accept connections from clients that matched both the private/public key in ~/.ssh/authorized-keys AND had the password.
-Sam
|
|
|
04-20-2011, 06:20 PM
|
#4
|
LQ Newbie
Registered: Apr 2011
Posts: 3
Rep:
|
Duo's two-factor auth for SSH
You can use login_duo to add two-factor auth to specific SSH pubkeys you want to add a secondary challenge to:
http://blog.duosecurity.com/2011/04/...tion-for-unix/
Or enable it system-wide, to protect any SSH login (using passwords OR pubkeys, or anything else :-)
|
|
1 members found this post helpful.
|
04-25-2011, 10:55 AM
|
#5
|
Member
Registered: Nov 2010
Posts: 33
Original Poster
Rep:
|
Quote:
Originally Posted by dugsong
You can use login_duo to add two-factor auth to specific SSH pubkeys you want to add a secondary challenge to:
http://blog.duosecurity.com/2011/04/...tion-for-unix/
Or enable it system-wide, to protect any SSH login (using passwords OR pubkeys, or anything else :-)
|
Brilliant!
Exactly what I was looking for, thanks
|
|
|
04-25-2011, 12:57 PM
|
#6
|
LQ Veteran
Registered: Feb 2003
Location: Maryland
Distribution: Slackware
Posts: 7,803
|
Can I ask why a key protected by a passphrase wasn't sufficient?
|
|
|
04-25-2011, 02:16 PM
|
#7
|
Member
Registered: Nov 2010
Posts: 33
Original Poster
Rep:
|
Quote:
Originally Posted by Hangdog42
Can I ask why a key protected by a passphrase wasn't sufficient?
|
Short answer, if it's possible why not?
We have some important servers that contain very sensitive information (Think emails, private internal software, security keys etc.) so we're trying to add every possible security measure. This way the only way to log in is if one has access to computers that have already been authorized and knows the password.
|
|
|
04-25-2011, 06:33 PM
|
#8
|
LQ Veteran
Registered: Feb 2003
Location: Maryland
Distribution: Slackware
Posts: 7,803
|
Quote:
Originally Posted by samarudge
Short answer, if it's possible why not?
We have some important servers that contain very sensitive information (Think emails, private internal software, security keys etc.) so we're trying to add every possible security measure. This way the only way to log in is if one has access to computers that have already been authorized and knows the password.
|
Oh, I do get the need for having decent login security. I guess to my way of thinking, the duo security approach isn't all that different from having keys with strong passphrases. In both cases you need the user to know something besides the computer to login from.
|
|
|
04-25-2011, 09:50 PM
|
#9
|
Senior Member
Registered: Nov 2004
Location: Texas
Distribution: RHEL, Scientific Linux, Debian, Fedora
Posts: 3,935
Rep: 
|
Quote:
Originally Posted by Hangdog42
... the duo security approach isn't all that different from having keys with strong passphrases. In both cases you need the user to know something besides the computer to login from.
|
Depends on circumstances (primarily: how keys are generated and distributed), but the problem is it's not easy to enforce strong passphrases on private keys. With shell account passwords, on the other hand, it is trivial to require and enforce certain criteria -- via pam_passwdqc(8) or pam_cracklib(8).
|
|
|
04-26-2011, 12:47 AM
|
#10
|
LQ Newbie
Registered: Apr 2011
Posts: 3
Rep:
|
SSH keys that call you back
Quote:
Originally Posted by Hangdog42
Can I ask why a key protected by a passphrase wasn't sufficient?
|
I wrote a blog post about this today :-) http://blog.duosecurity.com/2011/04/...call-you-back/
Quick summary: SSH keys are often used in ways that lead to serious breaches (e.g. sharing private keys among admins, or from a shared account on a bastion host). For many scenarios (e.g. managing lots of machines, or multiple admins, or extremely sensitive data), it pays to have a way to centralize management of those credentials.
|
|
|
04-26-2011, 07:22 AM
|
#11
|
LQ Veteran
Registered: Feb 2003
Location: Maryland
Distribution: Slackware
Posts: 7,803
|
Quote:
Originally Posted by anomie
Depends on circumstances (primarily: how keys are generated and distributed), but the problem is it's not easy to enforce strong passphrases on private keys. With shell account passwords, on the other hand, it is trivial to require and enforce certain criteria -- via pam_passwdqc(8) or pam_cracklib(8).
|
I agree, users can't be trusted to create decent passphrases. I was assuming that users would be given pre-made keys so that wouldn't be an issue. That said, centralization via PAM is probably easier on the IT staff.
Quote:
Originally Posted by dugsong
Quick summary: SSH keys are often used in ways that lead to serious breaches (e.g. sharing private keys among admins, or from a shared account on a bastion host). For many scenarios (e.g. managing lots of machines, or multiple admins, or extremely sensitive data), it pays to have a way to centralize management of those credentials.
|
Again, don't get me wrong, I do understand that users are almost always the weakest link in the security chain. I guess what bugs me a little about the login_duo approach is that you're now trusting a 3rd party with part of your critical security. That might be a naive reaction on my part, but it still bugs me.
|
|
|
04-26-2011, 07:38 AM
|
#12
|
LQ Guru
Registered: Aug 2001
Location: Fargo, ND
Distribution: SuSE AMD64
Posts: 15,733
|
I always add an "AllowUsers" line in sshd_config. A nice side effect is that log in attempts from system users is blocked. Something else to look at is a from= field in the authorized keys entries. This will limit where the user can connect from.
Protecting the users private key with a strong passphrase is still important. Unfortunately, this merely unlocks the clients private key, and the user could circumvent it with keygen. Also, users logging in with Putty on Windows may not have the private key user read-only protected.
|
|
|
All times are GMT -5. The time now is 07:41 AM.
|
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
|
Latest Threads
LQ News
|
|