Hot answers tagged


You can use AllowUsers / AllowGroups if you have only a few users/groups that are allowed to login via ssh or DenyUsers / DenyGroups if you have only a few users/groups that are not allowed to login. Note that this only restricts login via ssh, other ways of login (console, ftp, ...) are still possible. You need to add these options to your */etc/ssh/...


You can use the -s switch to su to run a particular shell su -s /bin/bash -c '/path/to/your/script' testuser


I think you want something like this: :w !sudo tee "%" I first saw it on commandlinefu. The quotes are only necessary if the file path contains spaces.


Well, technically you're not redirecting anything here. Calling script /dev/null just makes script save the whole typescript into /dev/null which in practice means discarding the contents. See man script for detailed info and util-linux-ng package for implementation (misc-utils/script.c). This has nothing to do with screen actually. Why this works is ...


With 'su' is probably that request a password, and www-data doesn't have password. I recommend the command sudo: sudo -u www-data command The condition is that your user must be root, or configurated in the sudoers file


I use su - targetuser -s /bin/bash from a root shell.


su - username is interpreted by your su to mean "run username's shell as an interactive login shell" su username - is interpreted by your su to mean "run the following non-interactive command (-) as username" the latter only worked at all because: your su passes trailing arguments to sh for parsing sh takes - to mean "run as a login shell (read /etc/profile,...


It's always better to use sudo, if possible, because then you don't need to know (or give someone) root's password. Set the root password to something long and horrible and then lock it in a safe. If you want to deny someone access later, you just remove their access to sudo, rather than having to teach everyone else a new root password. However - you ...


As root you can use su -s /bin/sh $user — the -s option overrides the configured shell for the user.


The root account is necessary on servers for sure, but I prefer granting sudo rights, especially when there are several users on the machine, and this for several reasons: I don't use sudo only to grant ALL rights for ALL commands, but also to grant specific rights as a specific user to specific commands. By assigning users to functional groups, I can ...


Try sudo. Add the following to your sudoers file (by running visudo): %you ALL= (restricted) NOPASSWD: ALL where you is your username and restricted is your reduced privilege user. You can then run commands as restricted without supplying a password: sudo -u restricted whoami You can also limit what commands can be executed via sudo by replacing the ...


Have you considered a password-less sudo instead?


One way is to launch a shell for that user (explicitly specifying the shell): sudo -u www-data bash This will launch a (bash) shell as the specified user. You can then execute your command(s) and logout (to return to your previous shell)


According to the su manpage if you want to run a command as another user using su, you should use the -c switch. For example: su logostudiotest1 -c /bin/ls


There is no benefit to using sudo su, it's an anachronistic habit from when people were used to using su. People started tacking sudo in front when Linux distros stopped setting a root password and made sudo the only way to access the root account. Rather than change their habits, they just used sudo su. (I was one of them until relatively recently when ...


Use -t to force ssh to allocate a tty: ssh -t -t remote-user su -c dmidecode You might also consider allowing root to ssh directly. If you're using public key authentication, this may be more secure as you won't be passing a password around. If you decide to do this, consider blocking root logins from anywhere except your trusted IP addresses by putting ...


I think you're trying to make sudo work in a way that it is not ment to - you don't want to add the 'simple' user to the sudoers file (please correct me if i'm wrong). In that case sudo isn't the tool you want to use you want to issue su -c <command> this will prompt for the root password, execute the command, then exit.


I agree that sudo is almost always a better answer but to answer the other part of the question... The '-' in 'su -' indicates that you want to emulate a superuser login, rather than just run with superuser priviledges. If you use plain 'su' rather than 'su -' you will stay in the same directory; however you will also be running in the same environment so ...


Yep, the 'wheel' group trick is also available on linux: you just need to configure pam for it and then, only wheel members can run su. On Debian, you have to uncomment the wheel line of /etc/pam.d/su This is definitely the first thing to do on any server, or else, any webserver/ hacked can lead to a root hack.


Let's look your cases: su - will run a /bin/sh as the root user using the root environment. The root password is needed and logging MAY be logged depending on syslog settings (usually is by default to /var/log/auth.log). sudo /bin/sh will run shell as the root user using the current set of environment variables (with some exceptions as would be ...


If you still want su to work, you can use sudo -u [username] or pass -s /bin/bash to su as a temporary shell. They both do the same in absence of a shell in /etc/passwd.


If you use su without the -, it should keep you in your current directory. -, -l or --login tell su to: Provide an environment similar to what the user would expect had the user logged in directly. Or just use sudo, it's got a lot of other advantages. Or ssh keys.


sudo allows one user to run commands with the permissions of another user. By default, on most systems, some users are allowed to use sudo to run commands as root. su requires a user's password to log in as that user, unless it is run by root. Thus, sudo su allows you to pretend to be root in order to log in as root without root's password. PS: sudo -i is ...


Just restarting postgres is not a long term solution, you will hit the limit again, unless you have physical resource constraints on the server such as memory. During the issue the number of processes opened(nproc) by postgres user was 503 and the estimated number of open files(nofile) was 35225 and yet your postgres_limits.conf shows that you have set nproc ...


Do you get any sort of error? It could be that the account has an invalid shell (like /usr/bin/false) in which case it would switch to that user and immediately exit. Try: sudo -u postgres -H bash Which will tell it to switch to the postgres user, set the HOME environment variable appropriately, and execute the bash shell


% sudo ALL = (ALL) NOPASSWD: ALL You have effectively given the users in the sudo group full unrestricted control over your system. Trying to deny them access to the su binary is as others have noted futile as they already have root privilege via sudo and membership of the group. You should analyse the workflow of the users in the sudo group to determine ...


Does otherusername have a valid shell in /etc/passwd? What su does is execute a process as another user. The process it chooses by default is whatever is in the last field in /etc/passwd for the user in question. This is usually a shell such as /bin/sh or /bin/bash. When that process ends, you are dumped back into the original shell you started in, owned ...


sudo -u <username> <command> sudo accepts a user parameter, which will run it as that user. Alternatively, since you are root: su <username> -c <command>


In case it's useful to someone else: I just ran into the same symptoms but the answer had nothing to do with sudo configuration. Instead, it mattered which user I was trying to su to. The target user was a service pseudo-user (jenkins) which had /bin/false as its shell. The fix was to change the shell to a valid one (using chsh).


Per Hadyman5's comment, I ran the following: id MYDOMAIN\\djsumdog ...and saw that my group was actually MYDOMAIN\linuxadmins, all lower case. I then added the following to my sudo configuration: %MYDOMAIN\\linuxadmins ALL=(ALL) ALL And sudo works fine now with the users in that group.

Only top voted, non community-wiki answers of a minimum length are eligible