Trying to run "cap deploy" with my Rails app; ssh keys

I recently moved my ~/.ssh folder contents to my new laptop in the
typical
~/.ssh folder. I was hoping to be able to use “cap deploy” on my new
laptop
to continue working with a Rails application I already had in production
(it’s the command I’d comfortably use on my old laptop). A little more
background - the application is on GitHub, and I’ve set up the necessary
Rails things on my new computer.

“git push” and “git pull” work fine, but oddly “cap deploy” leads to the
“Permission denied (publickey)” error… which I would think shouldn’t
happen because the ssh keys should be the same. I can even ssh into the
server of my app with no problem on my new comp.

The Rails app is deployed on Linux… Um… oh - please understand that
I’ve
never actually deployed an app myself with capistrano, i.e. with all the
setup with something like Passenger - someone else did it and sort of
left
me with everything :/. I don’t have a deep understanding of how ssh
keys
and capistrano and the deployment system work together…

(I hope this is enough information, and help would REALLY be
appreciated)

David Z. <[email protected]…> writes:

I recently moved my ~/.ssh folder contents to my new laptop in the typical
~/.ssh folder. I was hoping to be able to use “cap deploy” on my new
laptop
to continue working with a Rails application I already had in production
(it’s
the command I’d comfortably use on my old laptop). A little more
background -
the application is on GitHub, and I’ve set up the necessary Rails things
on my
new computer.

“git push” and “git pull” work fine, but oddly “cap deploy” leads to
the “Permission denied (publickey)” error… which I would think
shouldn’t
happen because the ssh keys should be the same. I can even ssh into the
server of my app with no problem on my new comp.

I have been tinkering with such things lately, and learning a lot.
There are
a few things I would check first:

  1. Have a look at the contents of your .ssh/id_rsa.pub key.
  2. Check your config/deploy.rb script to see which host and user it is
    using.
  3. Shell into the above server and check the users .ssh/authorized_keys
    file.
    It should contain a line identical to you local id_rsa.pub key.

This will make sure everything between your laptop and the server is set
up
correctly. Be aware that Capistrano may want to shell to your git
repository,
so ensure the cap user’s id_rsa.pub key on the server also apprears in
the
authorised_key file for the git user.

On Wednesday, June 22, 2011 1:07:45 AM UTC-4, Andrew S. wrote:

I have been tinkering with such things lately, and learning a lot. There
are
a few things I would check first:

  1. Have a look at the contents of your .ssh/id_rsa.pub key.
  1. Check your config/deploy.rb script to see which host and user it is
    using.

Alright. It all looks good.

  1. Shell into the above server and check the users .ssh/authorized_keys
    file.
    It should contain a line identical to you local id_rsa.pub key.

This line - does every part of it needs to be exactly identical to
what I
have in my local id_rsa.pub key? On my new machine, my global git
config
email is different from the email I used to use. So, in
the .ssh/authorized_keys file on the server, the key is exactly the
same,
but the email at the end is different - does this actually matter?

This will make sure everything between your laptop and the server is set up

correctly. Be aware that Capistrano may want to shell to your git
repository,
so ensure the cap user’s id_rsa.pub key on the server also apprears in the
authorised_key file for the git user.

“in the authorised_key file for the git user” - is that in my ~/.ssh
directory on my new computer? I only have id_rsa, id_rsa.pub, and
known_hosts in there.

On Wednesday, June 22, 2011 1:07:45 AM UTC-4, Andrew S. wrote:

  1. Shell into the above server and check the users .ssh/authorized_keys
    file.
    It should contain a line identical to you local id_rsa.pub key.

On the server, it’s actually ~/.ssh/authorized_keys2. That serves the
same
purpose, right?

Also, do the id_rsa, id_rsa.pub, and known_hosts files in the ~/.ssh/ on
the server matter at all? I noticed that the id_rsa.pub file on the
server has the exact same key as I do on my machine except for the email
at
the end. It also has the same key as one listed in authorized_keys2,
except
for the email at the end (the email at the end in the authorized_keys2
file
is actually my old email… I asked above if the email at the end
matters,
and I’m still curious if it does. Should the email at the correspond to
my
git config global email or something? Because it’s changed… :/)

Thanks for your help! Your input is really important to me!

David Z. <[email protected]…> writes:

On the server, it’s actually ~/.ssh/authorized_keys2. That serves the same
purpose, right?

To tell you the truth - I do not know. I would assume so.

Also, do the id_rsa, id_rsa.pub, and known_hosts files in the ~/.ssh/ on
the server matter at all?

They do for the user account they belong to.

I noticed that the id_rsa.pub file on the server has the exact same key as
I do on my machine except for the email at the end.

That should not happen. RSA keys are in pairs - private and public.
The
private key (id_rsa) MUST remain a secret only known to the user. The
public
key (id_rsa.pub) can be spread and wide. When someone wants to encrypt
something that ONLY you can see, they use your public key. The only
private
key in existence that can decode the message is your id_rsa.

If the keys are exactly the same except the email address, something bad
has
happened. I would rename the folder and generate a new key pair:

ssh-keygen

Then copy around the public key as required, placing it into
authorised_key
where needed.

It also has the same key as one listed in authorized_keys2, except for the
email at the end (the email at the end in the authorized_keys2 file is
actually my old email… I asked above if the email at the end matters,
and
I’m still curious if it does. Should the email at the correspond to my
git
config global email or something? Because it’s changed… :/)

As before, the email address is different, so the key will not match.
You
cannot simply edit the email address either - it will not work.

The solution to all of this was to run “ssh-add” in the command line.
“cap
deploy” then worked perfectly.

David Z. <[email protected]…> writes:

On my new machine, my global git config email is different from the email I
used to use. So, in the.ssh/authorized_keys file on the server, the key
is
exactly the same, but the email at the end is different - does this
actually
matter?

Ahh yes - of course it matters. The email address forms part of the
key.
Since it does not match the SSH server is not recongising you.

Add the new key to the authorised_keys file and see what happens.

This will make sure everything between your laptop and the server is set up
correctly. Be aware that Capistrano may want to shell to your git
repository,
so ensure the cap user’s id_rsa.pub key on the server also apprears in
the
authorised_key file for the git user.
“in the authorised_key file for the git user” - is that in my ~/.ssh
directory on my new computer? I only have id_rsa, id_rsa.pub, and
known_hosts
in there.

Here I was referring to a configuration in which you have seperate “git”
and “deploy” users on the server. During the deploy the “deploy” user
will
ssh to the “git” user, thus the “git” user will need the id_rsa.pub key
of the
deploy user in it’s authorised_keys file.

Of course, your set up may be different to what I am assuming.