- CheckMates
- :
- Products
- :
- Quantum
- :
- Security Gateways
- :
- Can RADIUS override the default shell
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Can RADIUS override the default shell
Hello,
I am currently deploying RADIUS to authentication on the firewalls to avoid having to duplicate accounts and synchronise passwords on all systems. The testing with the administrator accounts is fine. We are having the default shell configured as cli.sh
I would also like to use the RADIUS authentication for the WINSCP access to upload and download files. WINSCP does not like the cli.sh and work only with bash.sh. I verified that by changing default shell to bash.sh and WINSCP access works.
We want the remotely authenticated administrators to have cli.sh as their default.
Is there a way (RADIUS attribute) that I can return to the GAIA platform to be able to select what shell is used with the authenticated user?
Many thanks,
Michael
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We did this by adding the following line in CLISH
set aaa radius-servers default-shell /bin/bash
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This seems similar to the GUI option. I do not want to change the default shell for all RADIUS authenticated users. I would like to know there is an attribute that I can use to send back the Shell so that we can do customize per user the Shell used.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Same Challenge here. Hello Checkpoint, any Ideas?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Christian, I reached out to RnD on your behalf. This is not a feature available in R80.30
Code owner responded, stating that currently an option to control what shell user gets via a RADIUS attribute is not on the feature road map. They suggested that you can open an RFE for evaluation of feasibility and effort to get this implemented as a custom hotfix.
If multiple customers desire the same feature, it might be an opportunity for your account managers to pool RFEs together, so always worth a discussion with your Account Manager and Security Engineer.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Have a look here:
sk72940 - How to configure RADIUS authentication on Gaia OS
and
sk93309 - Troubleshooting RADIUS authentication related issues in Gaia
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
ok, so the short version is no you can't that I can see.
The long version is checkpoint is using the pam_radius module. This is most likely the git home for the project.
https://github.com/FreeRADIUS/pam_radius/blob/master/USAGE
Nothing in there brings up setting the shell.
This say this functionality should be coming from ldap and not radius, which doesn't help just throwing it out there.
https://serverfault.com/questions/567628/authenticate-radius-user-using-pam-and-ssh
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
No, you can not, and this feature is not on the road map at the moment.
Just going to point out two things, which might be non-obvious, but are good to keep in mind:
1) Any modification you make to the gateway, that were not at recommendations of support, or by following instructions of an SK, invalidate your configuration. From purely human perspective, you make some changes to the gateway, how do you expect support engineers to know what you did, and what the effects of it are? This is on top of the fact that you are modifying authentication mechanism (pluggable authentication module), which means that if you get it wrong, someone could log in into your gateway, or get permissions you don't want them to.
2) Setting up authentication on the gateway once is fine, but if you have to modify the settings on the gateway each time, you might as well set up local users. Those are supported. If you want new feature, don't kludge it yourself, push to get it as an RFE, then based on success of RFE, push to have it included in Jumbo HFA or new release, and supported out of the box.