Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
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.
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.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Not sure if this is possible, but looking for ideas. Have a few admins (who have ssh), and quite a few user logins for who all ssh is disabled (via /sbin/nlogin in /etc/passwd), but they can ftp in fine and change configs, upload files etc.
Each user has processes run on behalf of them by us. I would like these to run as their own username instead of as an admin, but allow admins to kill the users processes, restart, edit configs etc, which means becoming that user.
In other words what I'd like is a kind of permanent su -lm username (not for root, just so other admins can log in as other users without needing the password, as storing every password in one place to remember seems ineffecient and insecure as well), but using the sudoers type config.
So basically is it possible to login as a user who has ssh disabled without needing their password? Either via sudo (longer than 1 command) or su until you exit their login?
The "sudo -u" allows you to execute a command as if you were another user, but first you have to be granted this privilege in the sudoers file.
This feature can be convenient for programmers who sometimes need to kill processes related to projects they are working on. For example, programmer "peter" is on the team developing a financial package that runs a program called "monthend" as user "accounts". From time to time the application fails, requiring "peter" to stop it with the /bin/kill, /usr/bin/kill or /usr/bin/pkill commands but only as user "accounts". The sudoers entry would look like this:
peter ALL=(accounts) /bin/kill, /usr/bin/kill /usr/bin/pkill
User "peter" would now be allowed to stop the "monthend" process with this command:
Hiya, and thanks bignerd. That was pretty much the state of play I had got to. I've got it so we can use sudo -u xxx pkill process for example as you say with no pass, the main thing I was trying to figure was if there's a time when you know you have a lot of work to do for one persons account for example, if there was a permanent way to be "sudo'd" in to their account (until finished and log out), so every command is like being su'd in, so u dont need to type in sudo -u xxx before absolutely every command (thats the main complaint from admins about using it, they don't want to keep typing that in each time), and can just kill the process, edit configs etc, every command the user has access to, you do, and only have access to that user, then log out when finished with an exit type funtion. Basically a kind of hybrid between su -u and sudo.
Basically su would work fine if the password could be bypassed like in the sudoers file. So admin x can su to any group he has control of without needing their password.
Main problem I think is it seems to take the original users home dir for bash (i.e janes and not teds). I've also tried doing bash --rc which stops some errors, but can't force it as though it comes from the user themself.
Also tried creating a bash script chuser to take $1 as the argument and sudo -u $1 bash --rc etc, then change dir but doesn't work either permission denied as it still thinks I'm the first user at that point. (also any security issues doing it that way as a script, can't see any?).
Thanks a lot for the suggestion, getting closer, if anyone knows an easy way to force it to use the users homedir/shell/profile as well would just about be there I think.
Hiya and thanks, that would be the ideal solution, except that shell access is disabled for all those users and only ftp access allowed, so su username would fail on that being disabled. Thanks though, still giving me avenues to think of restricting in different areas to maybe allow that method.
edit: think the sudo -H might help, just trying that as well.
Ahhh I think thats the nail on the head for me , I actually started off messing with sshd_config, but could never get it to stop people, so thought I'd mess about again after you said that, I never realised it only changed after a kill -HUP, I always thought it reread the config for every login. So I think thats sorted, cheers muchly !
So I've actually got two ways now (I think) and created 2 scripts just to make it easier, something like swuser, just in case it helps anyone else searching in future.
sudo su -l $1 using ssh deny some users, prob quicker
sudo -H -u $1 bash using the /sbin/nologin to deny some.
I don't see any security problems doing it that way just so you can quicky type in "swuser jane" as long as they are in the sudoers file unless anyone else can (making sure in sudoers users are specified so you can't sudo su to root), so should be secure.
Just wanted to thank everyone for their help, knew it was possible and not that tricky, but wouldn't have put it all together without your help.