Hot answers tagged su
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 ...
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 ...
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 ...
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 ...
I use su - targetuser -s /bin/bash from a root shell.
Have you considered a password-less sudo instead?
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
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 ...
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 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.
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 ...
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.
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 ...
As root you can use su -s /bin/sh $user — the -s option overrides the configured shell for the user.
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)
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 ...
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 ...
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 ...
% 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 ...
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>
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.
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 and su have different configuration files. For sudo to work properly, the non-root user you are logging in should be either explicitly (I mean by user name) or implicitly (either in a UNIX group or in a defined set of users) permitted to run sudo su - If you don't know how this is configured, just follow the examples in the /etc/sudoers file For su, ...
su aegir is what you're looking for, assuming the username is aegir. man su will give you more info on the su command. That user likely won't be able to actually restart Apache if it's running on port 80, unless specifically configured to be allowed to do so. By default, root is the only user that can bind a service to a low port number.
su root (also can be written as su) does not spawn a login shell su - does spawn a login shell. nothing is sourced when using the first (eg. .bash_profile, .profile, etc.)
My thoughts: Set PasswordAuthentication and PermitRootLogin to no Optionally, passphrase your SSH keys (though there's no way to enforce this) Use MFA as Tim's answer suggests to further restrict SSH access (personally, I'd do this via PAM's Google Authenticator plugin) Do not enable passwordless sudo, and ensure strong passwords are set for your users. ...
So far I have disabled PermitRootLogin on SSH and switched the port. I'm not a big fan of running services on non-standard ports; you make interopability harder for yourself and others, for no real gain. With a decent password (or better: key), random SSH scans have no chance of succeeding anyway, and targeted attacks are not phased by a different port. ...
Only top voted, non community-wiki answers of a minimum length are eligible