How to make Shared Keys .ssh/authorized_keys and sudo work together?

25,398

Solution 1

ssh and sudo have nothing to do with each other. Setting up an ssh authentication method isn't going to do anything for sudo. sudo isn't going to understand an ssh password.

passwd -l is intended to lock a user's account, so that he can no longer authenticate by password. That's pretty much the opposite of what you want, which is letting the user authenticate without a password.

I think what you want is the NOPASSWD option in your sudoers file.

(PS, there's no reason to be running a cd command with sudo. cd does not propagate to parent processes, so as soon as the sudo exits, you're back where you started.)

Edit: You keep saying that you want to lock the account password and want sudo to understand public/private keys. Sorry, sudo isn't going to use ssh keys. It isn't ssh. If you don't want users to be able to log in with their passwords, I think the answer is to disable ssh password authentication, not to lock the account. Then you can retain a password for the users, which they can use to sudo after they log in via ssh authorized_keys.

Solution 2

What you want to do is possible but it will require some experience as you will have to compile a PAM module called pam-ssh-agent-auth.

The process is reasonably simple:

$ sudo aptitude install libssl-dev libpam0g-dev build-essential checkinstall
$ wget "http://downloads.sourceforge.net/project/pamsshagentauth/pam_ssh_agent_auth/v0.9.3/pam_ssh_agent_auth-0.9.3.tar.bz2"
$ tar -xjvf pam_ssh_agent_auth-0.9.3.tar.bz2
$ cd pam_ssh_agent_auth-0.9.3

$ ./configure --libexecdir=/lib/security --with-mantype=man

$ make
$ sudo checkinstall

The edit the sudo configuration:

$ sudo visudo

Add the following:

Defaults env_keep += SSH_AUTH_SOCK

Continue by changing the sudo PAM settings:

$ sudo vi /etc/pam.d/sudo

Add (just above the @include lines):

**auth [success=2 default=ignore] pam_ssh_agent_auth.so file=~/.ssh/authorized_keys**
@include common-auth
@include common-account

Solution 3

Andre de Miranda's answer provides a nice solution using pam_ssh_agent_auth, but parts are out of date. Particularly the /etc/pam.d/sudo instructions when using many current Linux versions.

If you're running Ubuntu 12.04 precise, I've actually simplified the process by providing a pam_ssh_agent_auth build out of a ppa: ppa:cpick/pam-ssh-agent-auth.

You can install the package by running:

sudo add-apt-repository ppa:cpick/pam-ssh-agent-auth
sudo apt-get install pam-ssh-agent-auth

After installation, if you'd like to use this PAM module with sudo you'll have to configure sudo's settings and PAM configuration, in Ubuntu 12.04 precise you can do that by creating the following two files:

/etc/sudoers.d/pam-ssh-agent-auth :

Defaults    env_keep+="SSH_AUTH_SOCK"

/etc/pam.d/sudo :

ent#%PAM-1.0

auth       required   pam_env.so readenv=1 user_readenv=0
auth       required   pam_env.so readenv=1 envfile=/etc/default/locale user_readenv=0
auth       sufficient pam_ssh_agent_auth.so file=/etc/security/authorized_keys
@include common-auth
@include common-account
@include common-session-noninteractive

If you're using chef, the above process can be automated with my cookbook, found at either of the two following locations:
https://github.com/cpick/pam-ssh-agent-auth
http://community.opscode.com/cookbooks/pam-ssh-agent-auth.

The cookbook's files directory contains the /etc/pam.d/sudo and /etc/sudoers.d/pam-ssh-agent-auth files described above that work with Ubuntu 12.04 precise and should be a helpful starting point when using other versions/distros.

Share:
25,398

Related videos on Youtube

mayank
Author by

mayank

Updated on September 17, 2022

Comments

  • mayank
    mayank over 1 year

    I've setup the .ssh/authorized_keys and am able to login with the new "user" using the pub/private key ... I have also added "user" to the sudoers list ... the problem I have now is when I try to execute a sudo command, something simple like:

    $ sudo cd /root
    

    it will prompt me for my password, which I enter, but it doesn't work (I am using the private key password I set)

    Also, I've disabled the user's password using

    $ passwd -l user
    

    What am I missing?

    Somewhere my initial remarks are being misunderstood ...

    I am trying to harden my system ... the ultimate goal is to use pub/private keys to do logins versus simple password authentication. I've figured out how to set all that up via the authorized_keys file.

    Additionally I will ultimately prevent server logins through the root account. But before I do that I need sudo to work for a second user (the user which I will be login into the system with all the time).

    For this second user I want to prevent regular password logins and force only pub/private key logins, if I don't lock the user via" passwd -l user ... then if I don't use a key, I can still get into the server with a regular password.

    But more importantly I need to get sudo to work with a pub/private key setup with a user whose had his/her password disabled.


    Edit: OK, I think I've got it (the solution):

    1) I've adjusted /etc/ssh/sshd_config and set PasswordAuthentication no This will prevent ssh password logins (be sure to have a working public/private key setup prior to doing this

    2) I've adjusted the sudoers list visudo and added

    root      ALL=(ALL) ALL
    dimas     ALL=(ALL) NOPASSWD: ALL
    

    3) root is the only user account that will have a password, I am testing with two user accounts "dimas" and "sherry" which do not have a password set (passwords are blank, passwd -d user)

    The above essentially prevents everyone from logging into the system with passwords (a public/private key must be setup).

    Additionally users in the sudoers list have admin abilities. They can also su to different accounts. So basically "dimas" can sudo su sherry, however "dimas can NOT do su sherry. Similarly any user NOT in the sudoers list can NOT do su user or sudo su user.

    NOTE The above works but is considered poor security. Any script that is able to access code as the "dimas" or "sherry" users will be able to execute sudo to gain root access. A bug in ssh that allows remote users to log in despite the settings, a remote code execution in something like Firefox, or any other flaw that allows unwanted code to run as the user will now be able to run as root. Sudo should always require a password or you may as well log in as root instead of some other user.

  • mayank
    mayank almost 14 years
    ok, but does the fact that the user has no password via: passwd -l user ... cause the sudo command not to work?
  • coneslayer
    coneslayer almost 14 years
    @farinspace Yes, I understand the question better and have substantially expanded my remarks. passwd -l removes the password in the sense that the account is LOCKED--that is, no password will work. You want to turn off password authentication in sudo.
  • mayank
    mayank almost 14 years
    i don't mind using the password, the problem it seems is after i disable the user password via: passwd -l user ... I can still login to the system via the pub/private key (private key has a secure password), when i do an sudo it asks for a password but this is not the password from the private key it seems, where is this password set if ive disabled it for the user (I would rather try to avoid maintaining a password on the ssystem and on the private key)
  • mayank
    mayank almost 14 years
    how is this logic: turning off the password in the sudoers file would still be secure, as the system is hardened via the pub/private key logins ... and again only admin would be able to add users to sudoers list
  • coneslayer
    coneslayer almost 14 years
    "where is this password set if ive disabled it for the user?" Nowhere. There is no password that you can type in that will work, because you have locked the account.
  • Glenn
    Glenn almost 14 years
    You would have to re-enable the account on the remote system and then set the password. Either way, you should certainly maintain the password on both machines. If for no other reason than local logins in case of a fault.
  • mayank
    mayank almost 14 years
    when using a private key is it typical to set a password for it, or is it secure enough to simply not have it set and bypass any password entry on server login
  • Andre de Miranda
    Andre de Miranda over 12 years
  • Andre de Miranda
    Andre de Miranda over 11 years
    @coneslayer this reply is not 100% accurate. As you can see below, sudo can be configured to respect ssh authentication.
  • Christopher Monsanto
    Christopher Monsanto almost 11 years
    This should be the accepted answer
  • Amauche
    Amauche almost 11 years
    These instructions (particularly the /etc/pam.d/sudo instructions) are out of date for current Ubuntu versions. I've provided updated instructions in my answer.