Tag Info

Hot answers tagged

115

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: _______ _ _ _____ _____ _____ _____ |__ __| | | |_ _|/ ____| |_ _|/ ____| /\ | | | |__| | | | | (___ | | | (___ ...


94

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 ...


60

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.


57

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 ...


49

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.


49

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: # ...


46

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 ...


40

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 ...


33

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.


29

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 ...


27

The immutable attribute may be set on the file. Remove it with chattr -i


27

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: ...


25

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. :)


25

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 ...


24

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.


22

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 ...


22

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


21

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 ...


20

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 ...


18

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.


17

sudo vi /etc/ssh/sshd_config Then uncomment or add the following: PermitRootLogin no Then restart sshd: sudo /etc/init.d/sshd restart


17

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 ...


17

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 ...


17

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 ...


16

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 ...


15

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 ...


15

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 ...


15

Adding the - option affects your environment behavior. For all practical purposes, the environment is completely reset. In general, you likely want to use su - instead of plain su. From the man page: -l Simulate a full login. The environment is discarded except for HOME, SHELL, PATH, TERM, and USER. HOME and SHELL are modified as above. ...


15

The main reason is to create an audit trail. If you need to log into a system as a regular user and then su, it is possible to trace who is responsible for given actions.


15

Yes. You'll need to delete the user's public SSH key to completely remove access. If you're simply trying to remove one user's access to root it's a little tricky. Hopefully you've been using separate private keys, because otherwise you'll have to recreate the file and redistribute the public keys to the authorized users. To remove the entry, you need to ...



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