I have a FreeBSD server with password-based SSH enabled. I would like to enable sudo, but I do not want a potential attacker to be one password away from root access. My current solution is logging in as root using a public key (remote password authentication is disabled for root), and my normal user is not in wheel and sudo is not installed.

In the past, I used one-time passwords for sudo access (I could public-key in to the system, but sudo required a OTP, and had a 30-minute timeout to let me actually get work done without re-authenticating all the time). This is a fair amount of hassle, however, at least with OPIE/S/Key. With a hardware token it might be OK, but I don't have one at this point.

I've been looking for something that would let me authenticate to sudo with an SSH public key via agent forwarding. pam_ssh included with FreeBSD doesn't seem to do this — it only authenticates by seeing if the user can decrypt a private key on the server. I have found pam_ssh_agent_auth, but I find very few references to it elsewhere. It's at 0.9 now, but I'm somewhat hesitant to trust the gateway to root to a program I can't find much evidence of people actually using.

So, my questions are basically 2:

Is pam_ssh_agent_auth used in the wild and reliable?

Is there another good solution to enable sudo while still having a barrier past the login password? I've thought of having a second account with sudo access and no password authentication, but this also seems somewhat cumbersome.

@Brad Gilbert: I'd do that, but I want to be able to log in as my normal user from computers I don't control. I just don't want those computers to be able to root the server. I want root access to be reserved to when I am logging in from a trusted host (either via private key, or some other means that I don't use on untrusted hosts).
–
Michael EkstrandSep 3 '09 at 13:38

2 Answers
2

You already solved this via OTPs (more security = more hoops), and I cannot comment on pam_ssh_agent_auth. But it seems as though your real concern is not with sudo but with network-level access. In other words, you seem concerned with privileges granted to users from a particular host or hosts rather than a particular system account. If that's so, consider implementing a port-knocking scheme in front of your SSH daemon, such that SSH is only accessible from specific IPs and by someone who knows the secret knock. After that, regular old public key authentication from known hosts should be sufficient. If an attacker can still gain shell access at that point, you're probably outmatched anyway.

The only other scenario I can think of is to use an ssh proxy on a trusted host that you can bounce your connections off of when you're on an untrusted network (and since you're in bsdworld, you can even use a jail on your host that does exactly that). As far as I'm concerned, any box that an attacker has shell access on is completely compromised, period. Whether they then get root creds or not is entirely moot. Your effort may best be spent preventing that first successful incursion.

user@workstation:~$ ssh-copy-id destination-server
user@destination-server's password:
Now try logging into the machine, with "ssh 'destination-server'", and check in:
~/.ssh/authorized_keys
to make sure we haven't added extra keys that you weren't expecting.