49

I've got a Github repo I want to access from two different Linux machines.

For the first machine, I followed Github's instructions for generating SSH keys, and added the resulting public key to Github. This client works fine.

For the second client, I copied the /home/{user}/.ssh/id_rsa file from the first client. I thought this might be all I had to do, but when I try to connect I get 'Permission denied (publickey).'

What am I missing?

4 Answers 4

54

The same SSH key should be able to be used from multiple clients. I have different SSH keys for different networks and they're actually stored on an encrypted USB drive that I use from several different computers without a problem.

SSH is very picky about file permissions so I would first check all the permissions from /home/{user} all the way down to the id_rsa file itself.

SSH does not really care for group or world write permissions so make sure you chmod go-w your home directory and the ~/.ssh directory for starters. I'd also make sure they're owned by your user chown ${USER}:${USER}.

For the SSH key itself I chmod 600 them...

If you want I've have additional info on how I manage my SSH keys in my answer to another SSH question.

1
  • In my case it was the permission of the private key file, when I copied from another machine, that copied as 664, so all I need to do was to change the permissions of private key file to 600
    – ata
    May 28, 2021 at 6:52
10

If you're getting permission denied from Github's end, it could be that it's not picking up your copied SSH key file, but rather the system default. An easy way around this is to great a ~/.ssh/config file and put the following in it:

Host github.com
  Hostname      github.com
  User          git
  IdentityFile  ~/.ssh/yourkeyfile

This will force your SSH client to use that key for github.com only.

Hope this helps.

0
4

I know this is old, but thought I'd point out that you also need to copy the public key to the second client

(or recompute it with ssh-keygen -y -f ~/.ssh/id_rsa_.. > ~/.ssh/id_rsa...pub)

From 1:

  1. Public Key Authentication Method: "publickey"

The only REQUIRED authentication 'method name' is "publickey"
authentication. All implementations MUST support this method;
however, not all users need to have public keys, and most local
policies are not likely to require public key authentication for all
users in the near future.

With this method, the possession of a private key serves as
authentication. This method works by sending a signature created
with a private key of the user. The server MUST check that the key
is a valid authenticator for the user, and MUST check that the
signature is valid. If both hold, the authentication request MUST be
accepted; otherwise, it MUST be rejected. Note that the server MAY
require additional authentications after successful authentication.

Your ssh client begins the authentication by sending the public key (the signature referenced in bold above) to the server. The server, if the public key is an authorized key, sends a random session ID back to your client. Your client then encodes that session ID with the private key and sends that back to the server. The server decodes that session ID using the public key, and if it matches the original session ID, then authenticates your client.

https://www.openssh.com/txt/rfc4252.txt

0

It's probably because you did not copy the permission of the file on the second client.
But a private key is private, the right way is to create a new private key on the second client and then add its public key to Github

2
  • I was planning on doing 1 keypair-per-user across each user's mutliple clients. But a key-pair for each client of each user just seems to me like it would get out of hand...?
    – Yarin
    Aug 15, 2010 at 14:14
  • If you use the same private key for each users on each machine it seems OK. Just check permission if you copy using scp with -p flag it should be ok
    – radius
    Aug 15, 2010 at 14:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .