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 ...
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 ...
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 ...
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 ...
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: ...
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.
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 ...
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 ...
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.
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 ...
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
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.
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 ...
Have a look here for some information on root. The use of the term root for the all-powerful administrative user may have arisen from the fact that root is the only account having write permissions (i.e., permission to modify files) in the root directory. The root directory, in turn, takes its name from the fact that the filesystems ...
sudo vi /etc/ssh/sshd_config Then uncomment or add the following: PermitRootLogin no Then restart sshd: sudo /etc/init.d/sshd restart
Thinking about it logically - without touching on any specific technologies - if it's not your machine and you don't trust root then you have a problem. You really can't do anything about securing screen and irssi. Root will always have permissions to force the attachment of screen sessions, to sniff IRC traffic from the network or potentially to peek into ...
Check /etc/sudoers.d/cloud-init file, ec2-user default user is there, just delete this file.
Use Puppet. Puppet is very flexible, easy to maintain and uses SSL. Might sound a bit overkill and you'll have to put some extra effort to build Puppet system up. But. Most probably this is not the last mass-update you'll be doing to these machines. Puppet will and does save you a lot of time when actual whatever mass-update procedure begins and scripts ...
Typically, the hashed passwords are stored in /etc/shadow on most Linux systems: -rw-r----- 1 root shadow 1349 2011-07-03 03:54 /etc/shadow (They are stored in /etc/master.passwd on BSD systems.) Programs that need to perform authentication still need to run with root privileges: -rwsr-xr-x 1 root root 42792 2011-02-14 14:13 /usr/bin/passwd If you ...
Only top voted, non community-wiki answers of a minimum length are eligible