Tag Info

Hot answers tagged

113

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


58

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.


56

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.


45

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


44

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


39

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

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


26

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


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


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.


23

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


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


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


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


16

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

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


15

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


15

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


15

If it were a simple "password lost" issue, I'd follow the other advice. Seeing as it was a hack, the solution would be wipe and restore from known good backup. You'll never know if you fully cleaned it and eliminated rootkits and backdoors.


15

I would actually consider doing a full reinstall of the system. Even if you manage to get most permissions right and that things seem to work there will most likely be some special permissions laying around, just waiting to cause trouble. Alternatively I'd compare the permission with a second, possibly freshly installed, machine. Shouldn't be to hard ...



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