Home / server / Questions / 61796
Accepted
Michael Ekstrand
Asked: 2009-09-03 17:54:44 +0800 CST

Easy multi-level authentication for sudo

  • 772

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:

  1. Is pam_ssh_agent_auth used in the wild and reliable?
  2. 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.
authentication ssh freebsd sudo private-key

2 Answers

  1. Michael,

    What you want to achieve can be performed by two ways:

    One as you found is to use pam_ssh_agent_auth or you may want to use its "poor cousin":

    ssh to localhost allied to SSH key forwarding. Step by step instructions in here point to a Ubuntu server but all commands should be ok with your FreeBSD as they are features of OpenSSH itself.

    1. add the key to ssh-agent:

    user@workstation:~$ ssh-add
Identity added: /home/user/.ssh/id_rsa (/home/user/.ssh/id_rsa)

    2. Copy the key to the user account on the target server

    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.

    3. Test the key based login:

    user@workstation:~$ ssh -A destination-server
Welcome to Ubuntu 11.04 (GNU/Linux 2.6.38-10-server x86_64)

 * Documentation:  http://www.ubuntu.com/server/doc

Last login: Mon Aug  8 20:38:48 2011 from 192.168.123.123
user@destination-server:~$

    4. Now we copy the SSH keys to: /root/.ssh/

    user@destination-server:~$ sudo cp ~/.ssh/authorized_keys /root/.ssh/
[sudo] password for user:
user@destination-server:~$ sudo ls -l /root/.ssh/au*
total 4
-rw------- 1 root root 392 2011-08-08 20:44 authorized_keys

    5. Back to the normal user life we check the existence of an SSH Auth Socket:

    $ echo $SSH_AUTH_SOCK 
/tmp/ssh-bUhwiw3004/agent.3004

    6. Fun time! Note: have in mind your SSHd may be configured to deny root access. Remember to enable it

    user@destination-server:~$ ssh root@localhost
Welcome to Ubuntu 11.04 (GNU/Linux 2.6.38-10-server x86_64)

 * Documentation:  http://www.ubuntu.com/server/doc

Last login: Mon Aug  8 21:07:29 2011 from eedev.local
root@destination-server:~# id
uid=0(root) gid=0(root) groups=0(root)

    7. Party is not over... You can chill-out and play with the setup a bit by using using aliases:

    Note: have in mind SSH and tty relationship tends to be troublesome

    user@destination-server:~$ alias sshudo='ssh -4 -t root@localhost'
user@destination-server:~$ sshudo id
uid=0(root) gid=0(root) groups=0(root)
Connection to localhost closed.
user@destination-server:~$ sshudo vi /etc/sudoers

    And voilà!

    Welcome to Ubuntu 11.04 (GNU/Linux 2.6.38-10-server x86_64)

 * Documentation:  http://www.ubuntu.com/server/doc

~                                                                                                                             
~                                                                                                                             
~                                                                                                                             
~                                                                                                                             
~                                                                                                                             
~                                                                                                                             
~                                                                                                                             
~                                                                                                                             
~                                                                                                                             
~                                                                                                                             
~                                                                                                                             
~                                                                                                                             
~                                                                                                                             
~                                                                                                                             
~                                                                                                                             
~                                                                                                                             
~                                                                                                                             
"/etc/motd" 4 lines, 114 characters

    8. Before you go... Fine tune it:

    user@destination-server:~$ sshudo vi /root/.ssh/authorized_keys

    Add the from="localhost" to the front of the SSH key you are using. this will restrict remote user access using that key and test:

    user@destination-server:~$ sshudo id
user@destination-server:~$ uid=0(root) gid=0(root) groups=0(root)
user@destination-server:~$ Connection to localhost closed.

    Logout and test the restriction

    user@destination-server:~$ exit
Connection to destination-server closed.

user@workstation:~$ ssh root@destination-server
root@destination-server's password:

    Hope this helps.

    • 4
  2. Best Answer

    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.

    Cheers, -G

    • 2