New answers tagged su
Does root have SFTP access? Can you sftp root@remote? If so, you should be able to download the /etc/sshd/sshd_config from the remote to your local machine, fix it, and push the corrected version back.
Is this a server you setup, or is it something a hosting provider supplied? If the hosting provider supplied it, do they offer a method of installing Webmin? If not, what exactly did you change in your SSH configuration?
The backticks (``) are command substitution: they are replaced by the result of running the command inside the backticks. Here they run whoami, which prints your username. The - after su makes su run a login shell: a login shell will read certain environment configuration from scratch, among other things. By default it would just run the user's shell as an ...
sudo -s Reads the $SHELL variable and executes the content. If $SHELL contains /bin/bash it invokes sudo /bin/bash. So, /bin/bash is started as non-login shell so all the dot-files are not executed, but bash itself reads .bashrc of the calling user. Your environment stays the same. Your home will not be root's home. So you are root, but in the environment ...
This is a simple syntax problem. su takes a single (optional) command argument, which is parsed by the target user's login shell. Here, the command you're running as root is the argument of -c, which is just chown. Put the command in quotes in your script so that it becomes a single argument. su -c 'chown -R smithb:other ...
Set up sudo to preserve the HOME environment variable. Run visudo to edit the sudo configuration. Make sure that the option always_set_home is not set, and that HOME is present in the env_keep list. Add the following lines: Defaults !always_set_home Defaults env_keep+="HOME" Remove a line like Defaults always_set_home if there is one.
Why don't you create a shell script and do a su - openproject -c "your_shell_script" Be aware of the - before openproject. That will set the environment variables of openproject instead of your user environment variables.
Use sudo -E to preserve your environment: $ export FOO=1 $ sudo -E env | grep FOO FOO=1 That will preserve $HOME and any other environment variables you had, so the same configuration files you started with will be accessed by the programs running as root. You can update sudoers to disable the env_reset setting, which clears out all environment variables ...
I agree with Valmiky that you're going about it the wrong way, but the sudoers line there isn't what I'd recommend. With his line, you are all authorized to sudo to anybody else including root without password. This effectively gives you full access to the server, meaning that the /bin/su part of the line is redundant. If you should only be able to sudo to ...
Do not do that! That will leave your password in your shell's history! If you really have to do that, what I recommend is that you configure your sudoers file to allow a passwordless login. To do that, run the command sudo visudo and add a line like this one: reddy ALL=NOPASSWD: /bin/su - * (where reddy would be your username). If you need to give this ...
The big difference is that - gives you the environment of the user you su'ed to. Chances are that you successfully became the support user, but were in your own home, which would explain why you were unable to create directories.
If using the Gnome environment in Scientific Linux 6 (or presumably RHEL 6), start a terminal. Go to Edit -> Profile Preferences -> "Title and Command" tab. Make sure that the checkbox "Run command as a login shell" is checked. I found that the Gnome terminal application is ignoring my .bash_profile unless I do this.
Yes, it's normal. The root user can do anything (including, say, changing a user's password, logging in as them, and changing it back), so they aren't restricted by su (or sudo). That includes password prompts and any other restrictions. The PAM configuration can be set up to have su present certain prompts to the root user still, for example encryption ...
You may try the sux command: sux user2 sux will handle the $DISPLAY stuff for you. You may need to install it with: sudo apt-get install sux under Debian/Ubuntu.
Running su - erases almost all environment variables. GUI applications need two environment variables to know how to connect to the GUI environment: DISPLAY and XAUTHORITY. See Open a window on a remote X display (why "Cannot open display")? for a more detailed explanation. The command su - retains DISPLAY but not XAUTHORITY. So your GUI ...
As man su notes, /etc/pam.d/su is the default PAM configuration file for su. One of the options is to grant implicit elevated privileges for anyone in the wheel group: # Uncomment the following line to implicitly trust users in the "wheel" group. auth sufficient pam_wheel.so trust use_uid With this line uncommented, when you issue su without any ...
It is really unclear with your question's current state. I believe you have to export the display. export DISPLAY='IP:0.0' See the answer here. Check the server's sshd_config (normally /etc/ssh/sshd_config), and make sure the X11Forwarding option is enabled with the line X11Forwarding yes If X11Forwarding is not specified, the default is no.
You should configure sudo security policy to allow user xyz exec something as user abc. Read 'man sudoers' and use visudo command to configure /etc/sudoers. For example let's allow user xyz exec /usr/bin/whoami as user abc without password. Add this string into /etc/sudoers (with visudo, don't edit /etc/sudoers directly): xyz ALL = (abc) NOPASSWD: ...
This is because sudo is different from su. When you su abc, you become the user abc as far as the system is concerned. You can then do anything that abc can do. On the other hand, sudo is used to allow other users to execute some commands by proxy. In other words, your sudo configuration allows you to do some commands on behalf of abc. If the command you're ...
Top 50 recent answers are included