Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.
share|improve this question
    
I usually disable password logins, opting for key based logins only. –  Brad Gilbert Sep 3 '09 at 3:52
    
@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 Ekstrand Sep 3 '09 at 13:38
add comment

2 Answers 2

up vote 1 down vote accepted

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

share|improve this answer
add comment

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.

share|improve this answer
    
That's a very interesting solution. Thanks! –  Michael Ekstrand Aug 21 '11 at 14:31
3  
If you're going to recommend enabling root SSH access, then please also recommend setting PermitRootLogin to "without-password", which forces use of ssh keys for the root user (it disables password authentication for root only). –  Daniel Lawson Feb 21 '12 at 18:59
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.