Setting up centralized authentication for Linux SSH users
I'm starting to wonder if I've selected the wrong tool for the job here. Hoping to gather some guidance, and help. The environment is 99% Linux servers with various Cisco equipment. I was thinking that a Freeradius solution would be a simple approach to get all the SSH devices (Linux and Cisco) pointing to a single server for authentication purposes. I would also like to setup groups, so that our Vendors that also require SSH access can be setup and assigned to specific groups that then can only SSH into specific servers. Am I heading in the right direction by selecting Freeradius to do this job? Here comes the issues I face. I got everything setup on a Linux server, and using MySQL as the backend. I'm also using daloRADIUS as the web frontend for management. I was able to get the test Linux servers PAM configured to point to the Freeradius server, and I can authenticate myself, and the other admins. However, it appears that, by default, all users can SSH into any of the NAS devices I've configured. This is the main issues I'm trying to solve. How, exactly, do I configure Freeradius to only allow certain vendor accounts SSH access into specific NAS devices? Thank you
On Jun 22, 2015, at 12:00 PM, Daniel Bray <dbray925@gmail.com> wrote:
I was thinking that a Freeradius solution would be a simple approach to get all the SSH devices (Linux and Cisco) pointing to a single server for authentication purposes.
RADIUS doesn't do UID, GID, home directory, etc. So it's probably not the correct choice for logging into Linux servers.
Here comes the issues I face. I got everything setup on a Linux server, and using MySQL as the backend. I'm also using daloRADIUS as the web frontend for management. I was able to get the test Linux servers PAM configured to point to the Freeradius server, and I can authenticate myself, and the other admins. However, it appears that, by default, all users can SSH into any of the NAS devices I've configured.
The default configuration of the server is to authenticate users. Which means all known users are allowed in.
This is the main issues I'm trying to solve. How, exactly, do I configure Freeradius to only allow certain vendor accounts SSH access into specific NAS devices?
You have to set up explicit lists of who's allowed to log in where. Put the data into an SQL table, and write a SELECT statement. Then, put that SELECT statement into the FreeRADIUS configuration. e.g. if you have a table of "user, NAS", you can do something like this: if (!"%{SELECT %{User-Name} from nas_control_table WHERE NAS = '%{NAS-IP-Address}' AND USER = '%{User-Name}'}) { reject } Which looks up the user by name and NAS IP. If the SQL statement returns nothing, reject. You'll have to create a correct schema, table, and query, of course. The above is just an example. Alan DeKok.
On Mon, Jun 22, 2015 at 1:52 PM, Alan DeKok <aland@deployingradius.com> wrote:
RADIUS doesn't do UID, GID, home directory, etc. So it's probably not the correct choice for logging into Linux servers.
I can take care of that with either Spacewalk, or other scripted methods. I was mainly looking for a centralized user "database", focusing on AAA. I've seen comparisons to OpenLDAP and other directory services, but I'm just not needing the level of Identity Management that LDAP-based services provide. My main focus is just (security) authorization.
The default configuration of the server is to authenticate users. Which means all known users are allowed in.
Is there any sort of common "trick" to deny users by default? Or, am I just looking at this wrong....which I'm beginning to think I am. If the user does not need access, but needs to be created in the Freeradius database, then I should probably either 1.) reevaluate the real reason they "need" to be created or 2.) explicitly deny/disable that user, leaving all the other admins alone with default access. I'm leaning towards option 2, so that I can just re-enable the vendor when they need to do work, and then disable (or set some sort of timed based authentication) when they are done.
You have to set up explicit lists of who's allowed to log in where. Put the data into an SQL table, and write a SELECT statement. Then, put that SELECT statement into the FreeRADIUS configuration.
And just to be clear. I should configure all of that with the /etc/raddb/sites-enabled/default file right after the authorize -> sql section. Meaning, I should place all my sql if/else statements in that section. Right? Thank you so much for your help and guidance.
On Jun 22, 2015, at 2:10 PM, Daniel Bray <dbray925@gmail.com> wrote:
I can take care of that with either Spacewalk, or other scripted methods. I was mainly looking for a centralized user "database", focusing on AAA.
People typically use LDAP for Linux logins. It's a better fit.
Is there any sort of common "trick" to deny users by default?
No. Unknown users are denied. Known users are authenticated. There's no trick. If you want known users to be rejected, you have to tell the server when to do that. There is no default configuration of "do everything I want"
Or, am I just looking at this wrong....which I'm beginning to think I am. If the user does not need access, but needs to be created in the Freeradius database, then I should probably either 1.) reevaluate the real reason they "need" to be created or 2.) explicitly deny/disable that user, leaving all the other admins alone with default access.
Pretty much.
And just to be clear. I should configure all of that with the /etc/raddb/sites-enabled/default file right after the authorize -> sql section. Meaning, I should place all my sql if/else statements in that section. Right?
Yes. Alan DeKok.
On Mon, Jun 22, 2015 at 2:14 PM, Alan DeKok <aland@deployingradius.com> wrote:
I just looking at this wrong....which I'm beginning to think I am. If the user does not need access, but needs to be created in the Freeradius database, then I should probably either 1.) reevaluate the real reason they "need" to be created or 2.) explicitly deny/disable that user, leaving all the other admins alone with default access.
Pretty much.
And just to be clear. I should configure all of that with the /etc/raddb/sites-enabled/default file right after the authorize -> sql section. Meaning, I should place all my sql if/else statements in that section. Right?
Yes.
Thanks again. In the end, this is the logic I came up with, and appears to be doing what I need it to do: # First, start with the "blanks". Meaning, no group, no NAS IP, no access...get out. if (("%{sql:SELECT `groupname` FROM `radusergroup` WHERE `username`='%{User-Name}'}" == '') || ("%{sql:SELECT `groupname` FROM `radhuntgroup` WHERE `nasipaddress`='%{NAS-IP-Address}'}" == '')) { update reply { Reply-Message := "No known GroupName or NAS IP, get out" } reject } # Check for specific groups and NAS IPs, else default to get out. if ("%{sql:SELECT `username` FROM `radusergroup` WHERE `groupname` = 'Admins' AND `username` = '%{User-Name}'}" != '') { update reply { Reply-Message := "Welcome Admin, you may access any device." } } elsif (("%{sql:SELECT `username` FROM `radusergroup` WHERE `groupname` = 'VendorA' AND `username` = '%{User-Name}'}" != '') && (NAS-IP-Address == "10.0.0.1")) { update reply { Reply-Message := "Welcome VendorA, you may access 10.0.0.1" } } else { update reply { Reply-Message := "No known authorized access, get out." } reject } For future vendors, I see the "elsif" part growing, and changing....and that's about it. So far, all my tests are working, and not working as expected.
On Jun 22, 2015, at 3:03 PM, Daniel Bray <dbray925@gmail.com> wrote:
Thanks again. In the end, this is the logic I came up with, and appears to be doing what I need it to do:
# First, start with the "blanks". Meaning, no group, no NAS IP, no access...get out. if (("%{sql:SELECT `groupname` FROM `radusergroup` WHERE
PLEASE don't change the meaning or contents of the existing tables. That will confuse anyone who expects the standard meaning. If you're going to use the radusergroup table, please read this page, which describes how it works: http://wiki.freeradius.org/modules/Rlm_sql If that functionality matches what you need, then delete your custom queries, and use the standard configuration.
For future vendors, I see the "elsif" part growing, and changing....and that's about it. So far, all my tests are working, and not working as expected.
Databases should store data. If your rules require 10+ if/then/else statements which are all identical but for "vendor"... that data belongs in a database. Create a custom schema of user name, NAS IP, group, and vendor. Then write ONE select statement which pulls information from SQL. It will be much, much, easier to maintain and extend in the future. Alan DeKok.
On Mon, Jun 22, 2015 at 3:22 PM, Alan DeKok <aland@deployingradius.com> wrote:
PLEASE don't change the meaning or contents of the existing tables. That will confuse anyone who expects the standard meaning.
Actually, once I looked at how detailed the below queries could get, I noticed I really didn't need the pre-blanks so I removed all the above.
Databases should store data. If your rules require 10+ if/then/else statements which are all identical but for "vendor"... that data belongs in a database. Create a custom schema of user name, NAS IP, group, and vendor. Then write ONE select statement which pulls information from SQL.
True, and good idea. Right now, we just have 1 or 2 vendors to worry about, so I was doing this as a sort of proof of concept, and also as a means to use what daloRADIUS comes with.
Daniel Bray wrote:
On Mon, Jun 22, 2015 at 1:52 PM, Alan DeKok <aland@deployingradius.com> wrote:
RADIUS doesn't do UID, GID, home directory, etc. So it's probably not the correct choice for logging into Linux servers.
I can take care of that with either Spacewalk, or other scripted methods. I was mainly looking for a centralized user "database", focusing on AAA. I've seen comparisons to OpenLDAP and other directory services, but I'm just not needing the level of Identity Management that LDAP-based services provide. My main focus is just (security) authorization.
At least you have to maintain some Identity Management data somewhere. LDAP solutions are there. Everything else you have to invent yourself. Ciao, Michael.
participants (3)
-
Alan DeKok -
Daniel Bray -
Michael Ströder