Kittensoft—Serious talk ab—oooh dust specks!! *pounce*

After a short embarrassment with SSH I decided I needed a bit of xtermcontrol functionality. On the rest of my machines, I use it to automatically switch to a green background when in an SSH session among other things.

As a complete newb, AppleScript syntax is a bit confusing. The idea is clear, the implementation seems somewhat awkward (particularly since I saw no way to dynamically determine properties.) So I chose to use the rb-appscript abstraction, installed through Gems. It enables accessing a high-level AppleScript-equivalent in Ruby. With this, I created the initial frail and simple draft:


# ~/Scripts/iterm.rb

require 'rubygems'
require 'appscript'

include Appscript

# Map some values or just pass-through
def expand(property)
  case property
  when 'bg'
    'background_color'
  else
    property
  end
end

include Appscript
app('iTerm').current_terminal.current_session.send(expand(ARGV.first)).set(ARGV.last)

This allows, for example, changing the background color with `ruby ~/Scripts/iterm.rb bg blue` etc.

To hook it up, I set up a function in my ~/.bashrc.osx (which is sourced in ~/.bashrc obviously):


  ssh() {
    ruby ~/Scripts/iterm.rb bg blue
    command ssh "$@"
    ruby ~/Scripts/iterm.rb bg black
  }

Obviously a lot of room for improvement but it just wraps any ssh invocation by first changing the bg, then launching ssh itself with whatever arguments were given and then switching back when ssh exits (whether requested or through an error.)

Gives me a nice blue background to easily distinguish ssh sessions among my terminals. This is exceptionally handy to use for su sessions if you use those. It is much harder to accidentally leave a bright red terminal session running than a regular-looking one. (I always only use sudo anyway, but not everyone does.)

Colour me paranoid; at least based on my web searches OS X users do not seem to suffer from the same aversion to always running under the Administrator account. The first thing I did when I realised that this was in fact the case was to create myself a new Standard account and then assign a better password to the Administrator account that was so helpfully created for me.

OS X does a good job facilitating running as Standard to a point: any time I need admin privileges, I am asked to authenticate as any of the local Administrator users which works pretty well in the GUI. However, I cannot sudo at the terminal as a Standard user so I needed to fix that. By default, the root account is disabled which is frankly a rather silly precaution since any Administrator can use sudo anyway (at least it was not made NOPASSWD.) Here are the steps:

Enable root
1. Run Directory Utility in /Applications/Utilities/ (or through Finder)
2. Click the lock and authenticate if necessary
3. Menu, Edit > Enable Root User
4. Menu, Edit > Change Root Password (make this something long and different from your Administrator password)
5. Click the lock to relinquish privileges
Configure sudo
1. Open up a terminal session
2. Switch to your Administrator account: login <admin unix name>
3. To edit the sudoers configuration file, use visudo (despite the name, it does respect EDITOR): sudo visudo. You will already have a default file in place with commented sections.
4. Look for the Defaults section and add yourself a few options by inserting a line like this (substitute ‘joe’ with your username): Defaults:joe runaspw, passwd_tries=3, timestamp_timeout=3. The first part specifies that the default only applies to that user (there are group etc. versions too), runaspw means whoever invokes sudo must enter the password for the user account being accessed (you could make this rootpw instead if you prefer) and the rest means that 3 invalid attempts terminate the sudo attempt and that any successful sudo@ authentication persists for 3 minutes without having to re-enter the password. Use the latter ones with normal caution and not at all on publically accessible machines.
5. Under User Privileges (you already see root and %admin there), add a line for yourself: joe ALL=(ALL) ALL. The syntax may look a bit cryptic but the first ALL designates machine IPs this applies to, the (ALL) specifies the user the command can be run as (given with the -u@ flag or guessed) and the last ALL is the set of commands that the user can run with this particular privilege setting. If you are adding programs explicitly instead of giving the ALL privilege, make sure to use full paths to avoid using a fake location.
6. Look at man sudoers for further details.
7. Save and quit
Disable root login
1. login <admin unix name> if you closed the session
2. su
3. chpass (Leopard correctly updates DirectoryService with chpass)
4. Caution: double-check the paths before entering
  1. Change Home Directory to /var/empty
  2. Change Shell to /sbin/nologin
  3. Save and quit
5. ^D
6. In your sshd_config, PermitRootLogin no. Also consider just using key-based authentication
^D
Test it: sudo echo 'hi'

If you ever should need to enable root logins, you can still do sudo chpass.

That should be all! Now you do not need to separately su or rely on the sudo capabilities of your Administrator user.

Kittensoft

Serious talk ab—oooh dust specks!! pounce

Displaying articles with tag sudo

Scripting iTerm with AppleScript

Administrator, root and `sudo` on Mac OS X

Recently

Categories