Hot answers tagged root
The red prompt is a good idea, which I also use. Another trick is to put a large ASCII-art warning in the /etc/motd file. Having something like this greet you when you log in should get your attention: _______ _ _ _____ _____ _____ _____ |__ __| | | |_ _|/ ____| |_ _|/ ____| /\ | | | |__| | | | | (___ | | | (___ ...
There's a difference, a crucial one. If you want to decrease the process' priority, the order does not matter. On the other hand, if you want to increase it, you must put sudo before nice. Since you are running the command as a normal user (otherwise you would not bother with sudo at all), you can only decrease the priority of your command. But if you use ...
It's not a good idea to edit /etc/profile for things like this, because you'll lose all your changes whenever CentOS publishes an update for this file. This is exactly what /etc/profile.d is for: # echo 'pathmunge /usr/lib/ruby-enterprise/bin' > /etc/profile.d/ree.sh # chmod +x /etc/profile.d/ree.sh Log back in and enjoy your (safely) updated PATH: # ...
Not quite the same thing, but this web site recommends having your developers wear a pink sombrero when making changes to production systems. You could probably have a similar rule for sshing into them.
The second option is the best one IMHO. Personal accounts, sudo access. Disable root access via SSH completely. We have a few hundred servers and half a dozen system admins, this is how we do it. How does agent forwarding break exactly? Also, if it's such a hassle using sudo in front of every task you can invoke a sudo shell with sudo -s or switch to a ...
Actual password hashes are stored in /etc/shadow, which is not readable by regular users. /etc/passwd holds other information about user ids and shells that must be readable by all users for the system to function.
The biggest I've used is a discrete naming-scheme where prod-systems are named obviously different than test/dev instances. This makes the "Username@Hostname: " style prompt visibly different. And by obvious I mean more than just different words, different formats too: example: PRD-WEB001 vs DEVEL-BOB-WEB001 This has several things going for it: The ...
Everything said so far here is good stuff but there is one 'easy' non technical way that helps negates a rogue sys admin - the four eyes principle which basically requires that two sysadmins be present for any elevated access. EDIT: The two biggest items that I've seen in comments are discussing cost and the possibility of collusion. One of the biggest ...
By default, you can only write to /var/run as a user with an effective user ID of 0 (ie as root). This is for good reasons, so whatever you do, don't go and change the permissions of /var/run... Instead, as root, create a directory under /var/run: # mkdir /var/run/mydaemon Then change its ownership to the user/group under which you wish to run your ...
The inference is to only su or sudo when required. Most everyday tasks don't require a root shell. So it is good practice to use an unprivileged shell as your default behaviour and then only elevate to root when you need to perform special tasks. By doing so you are reducing scope for dangerous mistakes (bad scripting, misplaced wildcards, etc) and ...
From this stackoverflow answer, by skinp :w !sudo tee % I often forget to sudo before editing a file I don't have write permissions on. When I come to save that file and get a permission error, I just issue that vim command in order to save the file without the need to save it to a temp file and then copy it back again.
Redhat user: chown 0:0 /bin/rpm && rpm -qa | xargs rpm --setugids Debian/Ubuntu user: chown 0:0 /bin/* /usr/bin/* chown daemon:daemon /usr/bin/at chown 0:utmp /usr/bin/screen chmod 02755 /usr/bin/screen chmod u+s /bin/fusermount /bin/mount /bin/su /bin/mount chmod u+s /usr/bin/sudo /usr/bin/passwd screen While screen is running do this at ...
The immutable attribute may be set on the file. Remove it with chattr -i
One thing you need to keep in mind is that this needs to be a persistent reminder, not just an indicator at login time. Very often, someone will have several shells running at the same time in different tabs and move between them. Some will be dev, some production. So when you are running a command, you need to have an indicator at that point. So having a ...
The easiest way to do this is to use a client section of the ~/.my.cnf file, and add the credentials there. [client] user=root password=somepassword ... it's a good idea to make that file readable only by root too.
You could reinvent the wheel, but honestly, I use passwordless sudo for this. For example, my monitoring system needs to be able to run a command to check the hardware RAID. This requires root privilege, but I don't want to run the whole monitoring system as root, so instead I have in sudoers a line that says nagios ALL=(root) NOPASSWD: ...
If people truly need admin access to a system then there is little you can do to restrict their activities on that box. What the majority of organisations do is trust, but verify - you might give people access to parts of the system but you use named admin accounts (e.g. you don't give them direct access to root) and then audit their activities to a log ...
Don't forget to change the root password. If any user has UID 0 besides root, they shouldn't. Bad idea. To check: grep 'x:0:' /etc/passwd Again, you shouldn't do this but to check if the user is a member of the root group: grep root /etc/group To see if anyone can execute commands as root, check sudoers: cat /etc/sudoers To check for SUID bit, which ...
You should disable root access from remote so an attacker can't compromise root without first compromising a user then escalating to root. We enable root access at the console only. Plus it creates accountability. :)
To pull the effective uid use this command: id -u If the result is ‘0’ then the script is either running as root, or using sudo. You can run the check by doing something like: if [[ $(/usr/bin/id -u) -ne 0 ]]; then echo "Not running as root" exit fi
If they are using sudo, then it will ask for their password and not root password, therefore no root password change needed. Just be sure to give them proper privileges in /etc/sudoers file.
It's debatable, to me, that disabling root is worth the potential issues. I have never tested a server configured in such a manner. My preference is to allow root local access only. If an attacker has physical access to your server, you can forget everything you've done to "secure" your install anyway. Disable root ssh access by editing ...
If this was a normal binary, you could setuid by running # chmod u+s /path/to/binary Unfortunately, scripts can't be setuid. (Well you can, but it's ignored). The reason for this is that the first line of the script tells the OS what interpreter to run the script under. For example if you had a script with: #!/bin/bash You'd actually end up running ...
To see who is UID 0: getent passwd 0 To see who is in groups root, wheel adm and admin: getent group root wheel adm admin To list all users and the groups they are members of: getent passwd | cut -d : -f 1 | xargs groups
On CentOS 5.2, the man page provided by running man pkill says it would interpret the /? as an extended regular expression for process names or command lines. So the ? means the previous caracter may or may not appear. Since there was only one other character, the /, then pkill killed every process it could. On linux systems, try to remember the man ...
Why password is asked when it is not permitted?! The one of the rules of security is not to tell attacker if something is enabled/disabled. This is just one example. The other is logging in as non-existing user. It will also ask for password. Telling attacker "root is disabled" or "the user does not exists" gives him some information, which you would ...
Without putting yourself into an insane technical mind twist to try and come up with a way to give a sysadmin power without giving them power(its likely doable, but would ultimately be flawed in some way). From a business practice standpoint there is a set of simple solutions. Not cheap solution's, but simple. You mentioned that the pieces of IP you are ...
Check /etc/sudoers.d/cloud-init file, ec2-user default user is there, just delete this file.
sudo vi /etc/ssh/sshd_config Then uncomment or add the following: PermitRootLogin no Then restart sshd: sudo /etc/init.d/sshd restart
Try using the command su -. The - means the new shell will get a environment of the user you have changed to. If you don't use it most of your environment will remain the same. The man page for su says: The optional argument - may be used to provide an environment similar to what the user would expect had the user logged in directly.
Only top voted, non community-wiki answers of a minimum length are eligible