How do you get superuser privileges on machines you administer?
Submitted by dkg on Sat 28 Jul 2007
| log in as root at a vt |
   6% | 117 votes |
| log in as root through an X11 display manager |
0% | 14 votes |
| su |
43% | 821 votes |
| sudo |
32% | 609 votes |
| ssh to root |
12% | 243 votes |
| choose something like "root terminal" from a GUI menu |
1% | 24 votes |
| crack the running kernel |
3% | 59 votes |
| other |
0% | 16 votes |
| Total 1903 votes |
On AIX boxen at work we had sudo for a while on a test system, but the admin couldn't get his head round it, so it's su only on AIX at the moment.
On any box I control you can't remote login as root at all, even users need a key to get in vis SSH.
Once I cracked the kernel on Solaris 2.6 after I forgot the root password. I since installed sudo on the box. One of these days I'll add some more disk to the box and install Debian Etch on it while SPARC32 is still supported.
--
"It's Not Magic, It's Work"
Adam
[ Parent ]
I saw that a while ago and tried it. When I do a sudo su - you get a shell and the normal initialisation, which in my case gives me a visually different prompt amongst other things, sudo -s doesn't do that. I like having my prompts to remind me I'm "god" rather than me.
--
"It's Not Magic, It's Work"
Adam
[ Parent ]
IME that's just what sudo -i does -- to quote the manpage:
-i The -i (simulate initial login) option runs the shell specified in
the passwd(5) entry of the user that the command is being run as.
The command name argument given to the shell begins with a - to
tell the shell to run as a login shell. sudo attempts to change to
that user's home directory before running the shell. It also ini-
tializes the environment, leaving TERM unchanged, setting HOME,
SHELL, USER, LOGNAME, and PATH, and unsetting all other environment
variables. Note that because the shell to use is determined before
the sudoers file is parsed, a runas_default setting in sudoers will
specify the user to run the shell as but will not affect which
shell is actually run.
I certainly use sudo -i quite a bit, and it even picks up my garish bright-red $PS1 which reminds me that I'm playing god at the time...
Cheers.:wq
[ Parent ]
--
"It's Not Magic, It's Work"
Adam
[ Parent ]
[ Send Message | View dkg's Scratchpad | View Weblogs ]
[ Parent ]
I've worked at a company where the wife of the boss said she couldn't administer a Linux server decently without it. Luckily (?) the clients had an even poorer understanding of Linux.
[ Parent ]
[ Parent ]
you might want to take a look at sudo-ldap...
[ Parent ]
[ Send Message | View dkg's Scratchpad | View Weblogs ]
[ Parent ]
Well, I'm only just starting to look at it (it's been on my to-do list for months though ;-), but essentially, it allows you to keep the sudo configuration, basically everything that used to go in /etc/sudoers, in a LDAP directory.
If you're rolling out a centralised infrastructure, it's one less thing that cfengine/puppet needs to sync, and means that there's only one place that you need to mess around with who can do what (as far as sudo is concerned).
In fact, with your mention of libnss-ldap, the sudo-ldap config goes in /etc/libnss-ldap.conf. So if you're using libnss-ldap (which you probaby are anyway if you're messing with LDAP), you don't have to worry about any more files cluttering up your /etc/ tree.
Cheers.
:wq
[ Parent ]
[ Send Message | View dkg's Scratchpad | View Weblogs ]
[ Parent ]
Just habit, while i tell many people to leave the defaults on Ubuntu (sudo for first created user during install) i don't use it myself.
sno
[ Parent ]
Always su.... On my server all root connections are disabled
[ Parent ]
It seems pretty clear to me that doing anything X-related as root is a very bad idea, so the "log in as root through an X11 display manager" should definitely be avoided.
The "su", "sudo", and "choose something like 'root terminal' from a GUI menu" options require remembering a separate root password for each administered machine, which seems like a pain to me. I'm into trying to reduce the number of passwords I have to remember. The beauty of the "ssh to root" option in conjunction with pubkey auth is that you only have to remember a password for the key used to access root on the various machines.
[ Parent ]
Allowing root access vis SSH is considered weak I suppose because there IS a root account and it doesn't lock if you try to brute-force it. A SSH key is a lot more secure than a password over SSH, but then the SSH key is only as secure as the security on another box - which itself could be compromised. I don't allow root over SSH by any method, others do and are able to sleep at night...
--
"It's Not Magic, It's Work"
Adam
[ Parent ]
[ Parent ]
[ Send Message | View dkg's Scratchpad | View Weblogs ]
LogLevel VERBOSEThen it will log the RSA keys used to grant access. The logs look like this:
Jul 31 17:44:00 chimpsky sshd[23418]: Found matching RSA key: 25:cd:3f:6a:79:cb:58:ae:56:6f:b4:aa:b0:57:30:35 Jul 31 17:44:01 chimpsky sshd[23418]: Accepted publickey for root from 127.0.1.1 port 45283 ssh2Note that since OpenSSH 4.4 you can also use the ForceCommand and Match keywords together to achieve something similar to the capabilities granted via sudo.
[ Parent ]
[1] http://www.debian-administration.org/articles/384#comment_7
HTH.
--
Hardik Dalwadi @ GNU/Linux
[ Parent ]
[ Parent ]
[ Parent ]
--
"It's Not Magic, It's Work"
Adam
[ Parent ]
[ Parent ]
[ Parent ]
Besides, Linux had a few possibly still unknown hacks that allow escalated privileges. Redhat had a libc file association hack I used to harrass students with (how would you fix a situation where a student does `chmod a-rwx /bin/chmod` ?) and I thought I read something about invoke-rc.d but I can no longer find it.
http://youve-reached-the.endoftheinternet.org/
[ Parent ]
[ Parent ]
[ Parent ]
x-terminal-emulator -bg darkgreen -fg white -e ssh root@machine
x-terminal-emulator -bg lightgreen -fg black -e ssh machine
The colours are per-machine, which makes it more likely that I run the command on the machine I intended to. I also try to mnemonically associate the colour name with the machine name, and also with the keybinding that starts the shell.
Using this system, I have never accidentally run something as root when I shouldn't have, or run a command on the wrong machine.
[ Parent ]