Allow authentication with SSH key instead of password

[MarkMurphy]

After I created my personal account on the server I added my public github keys to /home/me/.ssh/authorized_keys but all recap tasks contiue to prompt me for password which is highly annoying.

It should instead check if ~/.ssh/authorized_keys exists and assume that no password is then needed and if that fails, then request the password.

FYI, in addition to this you could easily make this part of the setup by asking for Github username and then running this to add their keys:

wget https://github.com/{username}.keys -O ~/.ssh/authorized_keys

[digitalronin]

I don't think it's recap prompting you for your password.

That sounds like SSH falling back to requesting a password because it couldn't use your key to connect. If you just ssh to your server from the command line, does it prompt you for a password?

This can also happen if the permissions on either the .ssh directory, or the .ssh/authorized_keys file are too loose. Try 700 and 644, respectively, if you think that might be the case.

[MarkMurphy]

It works fine when trying directly from the command line. I'll check the permissions.

On Apr 26, 2014, at 1:52 PM, "David Salgado" notifications@github.com wrote:

I don't think it's recap prompting you for your password.

That sounds like SSH falling back to requesting a password because it couldn't use your key to connect. If you just ssh to your server from the command line, does it prompt you for a password?

This can also happen if the permissions on either the .ssh directory, or the .ssh/authorized_keys file are too loose. Try 700 and 644, respectively, if you think that might be the case.

—
Reply to this email directly or view it on GitHub.

[MarkMurphy]

@digitalronin Actually it's not an authentication problem. It connects to the server just fine, that part works as expected, it's when it does something like the following it prompts for password:

* executing "sudo -p 'sudo password: ' su - application -c 'cd . && bundle --version > /dev/null 2>&1'; echo $?"
    servers: ["###.##.###.###"]
    [###.##.###.###] executing command
Password: 

[digitalronin]

Interesting. I think it's the 'su - application...' which is prompting you for the password (because the prompt is "Password:" rather than "sudo password:")

It looks like whatever user you're deploying as might not be able to run "sudo su - application -c ..." without a password prompt. Try something like "sudo su - application -c ls" on the command line to confirm.

I'd suggest having a play with visudo and set your deployment user to have passwordless sudo access for all commands, and see if that works, and then go step by step and reduce the permissions and restrictions to something you're happy with.

[MarkMurphy]

@digitalronin I followed your advice and have confirmed that your assumptions were correct. My deployment user (lets call it "mark") was unable to run sudo su - application -c ls without a password prompt coming up so I added the following as you suggested I try:

# Located at /etc/sudoers.d/mark
mark ALL=(ALL) NOPASSWD:ALL

This did the trick, (after running sudo service sudo restart) I was able to issue the same command while logged in as "mark" without being prompted for a password.

I can confirm that my user is part of the application group as outlined in the recap documentation:

Personal accounts are used to deploy to the server, distinct from the application user. The right to deploy an application is granted simply by adding a user to the application group. Most tasks are run as the application user using sudo su…. To avoid having to enter a password when running them, these lines can be added to /etc/sudoers.d/application (change application to the name of your app).

%application ALL=NOPASSWD: /sbin/start application*
%application ALL=NOPASSWD: /sbin/stop application*
%application ALL=NOPASSWD: /sbin/restart application*
%application ALL=NOPASSWD: /bin/su – application*
%application ALL=NOPASSWD: /bin/su application*

http://gofreerange.com/recap/docs/recap.html

He's also a member of the sudo group, so what am I missing here?

[digitalronin]

If there is a different user account running the application (e.g. "appuser"), as opposed to the user "mark" which is deploying the application, I would try adding the application user to sudo with, initially, full permissions. If that gets you past the current problem, you can reduce permissions later. So, if your application user is "appuser", try adding this to /etc/sudoers

appuser ALL=(ALL) NOPASSWD:ALL

See if that helps, and then reduce the permissions to something less dangerous. If "mark" is both the deployment user and the application user, then I have no idea what's going on, I'm afraid.

[MarkMurphy]

I did this:

# in /etc/sudoers.d/application
%application ALL=NOPASSWD: /sbin/start application*
%application ALL=NOPASSWD: /sbin/stop application*
%application ALL=NOPASSWD: /sbin/restart application*
%application ALL=NOPASSWD: /bin/su – application*
%application ALL=NOPASSWD: /bin/su application*
%application ALL=(ALL) NOPASSWD:ALL

So essentially I believe the last line overrides the others, making anyone in the group "application" have the ability to do anything, which worked.

I'm definitely not one to call myself familiar with permissions so as far as reducing permissions and restrictions to something I'm happy with goes...I'm kind of a deer in the headlights.