Tag Info

Hot answers tagged

110

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


55

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


53

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.


44

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


38

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


38

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


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


26

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


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


21

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


21

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


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.


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


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


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


14

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


14

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


13

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


13

Please do not vote me down for this. I do not recommend implementing this answer, but it is the answer that the rkthkr is asking for. rkthkr said: But it would be nice to have vim restarted and run as root The way to do this is with :!sudo vim % As I mentioned to ipozgaj, a % as an argument (even a sub-argument) gets replaced with the path to the ...


12

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


12

Two points: 1.) Because Root is always there, and the gain would be so high, it is probable an eventual brute force attack would take place against root. For other users, the username would have to be guessed first. And then the users would have to have permissions. Making the brute force just not worth the effort. 2.) Noone should login as root, and you ...


12

Just consider that your second and third ideas help during the initial connection but are of no value when you have multiple terminals open and move from one to another. sysadmin1138's idea of using naming is good when it can be applied but there are plenty of cases where it cannot be. The only thing I've found to be really worthwhile is a coloured prompt. ...


12

As well as the open files problem that commonly causes otherwise free space to be held unavailable, a not uncommon problem is files shielded by mount points. For instance if you have /tmp as a separate logical volume but still have files in the directory /tmp in the root filesystem, those files will be consuming space but will be hidden by the mount. Try ...


11

These are my suggestions: 1) Make sure most commands (rm, chown, chmod, /etc/init.d/* ) on the Production environment require sudo access 2) Use PS1/PS2 to indicate that the user is in a Prod server bash-3.2$ export PS1="[\u@\h \W]\$ " This will show the command prompt as [sridhar@prodappserver901 conf]$ 3) If Using Putty/SSH clients, You can always ...


11

All my servers have the root account disabled (sp_pwdp set to *). This is to require sudo for all root access.[1] The purpose of this is to have all superuser activities audited, so people can see what has been done to the system. For a more hardcore option, you can make sudo write to a log file (as opposed to syslog), and make the file append-only (using ...


11

Dedian and Ubuntu block the old "single user boot" method as this requires the root password too the way these distributions are configured. If you have a user that has wide root privileges via sudo you might be able to set the passord with sudo passwd root though access to passwd like that is usually looked out in sudo configurations. You other option is ...


10

I think you're trying to make sudo work in a way that it is not ment to - you don't want to add the 'simple' user to the sudoers file (please correct me if i'm wrong). In that case sudo isn't the tool you want to use you want to issue su -c <command> this will prompt for the root password, execute the command, then exit.



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