The scenario:
You have a FreeBSD server where you are the admin and you can already use su(1) to gain root access by using the root's password. You are using ssh(1) with public keys to authenticate to the server on your non-priviledged user account. You would like to su(1) to root without password by making use of the private SSH key on your client machine.
Requirements:
- Your unpriviledged user is in the wheel group on the server.
- You are using SSH public key authentication to authenticate to the server.
- You have ssh-agent(1) forwarding set up so that the keys on the client machine can be used on the server. See the manual pages of ssh(1) and ssh-agent(1) how to set up the forwarding. If the forwarding is working ssh-add -l run on the server should output the public key part of your SSH key on the client machine.
Software needed:
- Pluggable Authentication Modules PAM, included in base FreeBSD
- sshd(8), included in base FreeBSD.
- security/pam_ssh_agent_auth.
On client machine:
- SSH client that can forward the key agent connection to the server, ssh(1) on Unix type OSes. On MS Windows Putty can be used with Pageant.
Configuration:
Edit /etc/pam.d/su so that it reads:
Note the order of auth modules, pam_group is checked before the pam_ssh_agent_auth
module so the user must be in the wheel group befofe the ssh agent based authentication is tried.
The file=%h/.ssh/authorized_keys parameter above refers to root's .ssh/authorized_keys file. Place the public SSH keys that are allowed to su(1) without password to /root/.ssh/authorized_keys. You can also use a completely separate file for the keys to avoid unintentional ssh access to root. For example this is what I use:
That's basically it. Now you should be able to su(1) to root without being asked the passworld. If su(1) still keeps asking for password check /var/log/auth.log for errors and double check that the ssh-agent(1) forwarding is working on your unpriviledged user account.
Security considerations:
Make sure the authentication socket files under /tmp/ssh-* directories (the ones owned by you) are not readable by anyone else but your unpriviledged user and root. With default settings and proper permissions this should be the case but it's always good to double check.
Issues with the security/pam_ssh_agent_auth port:
The port has some issues when compiled on a recent 9-STABLE. The problem is that a new strnvis(3) function was added to 9-STABLE but it uses a different signature (order of arguments) than the one expected by this port and the workaround in the port is still not working properly. The attached patch has to be applied to the port Makefile to get the port to produce a working PAM plugin on 9-STABLE. 9.1-RELEASE is not affected because it does not have the new function yet.
You have a FreeBSD server where you are the admin and you can already use su(1) to gain root access by using the root's password. You are using ssh(1) with public keys to authenticate to the server on your non-priviledged user account. You would like to su(1) to root without password by making use of the private SSH key on your client machine.
Requirements:
- Your unpriviledged user is in the wheel group on the server.
- You are using SSH public key authentication to authenticate to the server.
- You have ssh-agent(1) forwarding set up so that the keys on the client machine can be used on the server. See the manual pages of ssh(1) and ssh-agent(1) how to set up the forwarding. If the forwarding is working ssh-add -l run on the server should output the public key part of your SSH key on the client machine.
Software needed:
- Pluggable Authentication Modules PAM, included in base FreeBSD
- sshd(8), included in base FreeBSD.
- security/pam_ssh_agent_auth.
On client machine:
- SSH client that can forward the key agent connection to the server, ssh(1) on Unix type OSes. On MS Windows Putty can be used with Pageant.
Configuration:
Edit /etc/pam.d/su so that it reads:
Code:
# auth
auth sufficient pam_rootok.so no_warn
auth sufficient pam_self.so no_warn
auth requisite pam_group.so no_warn group=wheel root_only fail_safe ruser
auth sufficient /usr/local/lib/pam_ssh_agent_auth.so file=%h/.ssh/authorized_keys
auth include system
# account
account include system
# session
session required pam_permit.soNote the order of auth modules, pam_group is checked before the pam_ssh_agent_auth
module so the user must be in the wheel group befofe the ssh agent based authentication is tried.
The file=%h/.ssh/authorized_keys parameter above refers to root's .ssh/authorized_keys file. Place the public SSH keys that are allowed to su(1) without password to /root/.ssh/authorized_keys. You can also use a completely separate file for the keys to avoid unintentional ssh access to root. For example this is what I use:
Code:
auth sufficient /usr/local/lib/pam_ssh_agent_auth.so file=/usr/local/etc/pam_ssh_agent_auth/authorized_keysThat's basically it. Now you should be able to su(1) to root without being asked the passworld. If su(1) still keeps asking for password check /var/log/auth.log for errors and double check that the ssh-agent(1) forwarding is working on your unpriviledged user account.
Security considerations:
Make sure the authentication socket files under /tmp/ssh-* directories (the ones owned by you) are not readable by anyone else but your unpriviledged user and root. With default settings and proper permissions this should be the case but it's always good to double check.
Issues with the security/pam_ssh_agent_auth port:
The port has some issues when compiled on a recent 9-STABLE. The problem is that a new strnvis(3) function was added to 9-STABLE but it uses a different signature (order of arguments) than the one expected by this port and the workaround in the port is still not working properly. The attached patch has to be applied to the port Makefile to get the port to produce a working PAM plugin on 9-STABLE. 9.1-RELEASE is not affected because it does not have the new function yet.
