How to Setup Public-Key Authentication

How do I setup Public-Key Authentication?

If you have SSH installed, you should be able to run..

ssh-keygen

Then go through the steps, you'll have two files, id_rsa and id_rsa.pub (the first is your private key, the second is your public key - the one you copy to remote machines)

Then, connect to the remote machine you want to login to, to the file ~/.ssh/authorized_keys add the contents of your that id_rsa.pub file.

Oh, and chmod 600 all the id_rsa* files (both locally and remote), so no other users can read them:

chmod 600 ~/.ssh/id_rsa*

Similarly, ensure the remote ~/.ssh/authorized_keys file is chmod 600 also:

chmod 600 ~/.ssh/authorized_keys

Then, when you do ssh remote.machine, it should ask you for the key's password, not the remote machine.

To make it nicer to use, you can use ssh-agent to hold the decrypted keys in memory - this means you don't have to type your keypair's password every single time. To launch the agent, you run (including the back-tick quotes, which eval the output of the ssh-agent command)

`ssh-agent`

On some distros, ssh-agent is started automatically. If you run echo $SSH_AUTH_SOCK and it shows a path (probably in /tmp/) it's already setup, so you can skip the previous command.

Then to add your key, you do

ssh-add ~/.ssh/id_rsa

and enter your passphrase. It's stored until you remove it (using the ssh-add -D command, which removes all keys from the agent)

Public Key Authentication

Not sure if this is really a programming question, but:

SSH uses publickey keys to authenticate 'hosts' (servers) always and 'users' (clients) optionally (but often). The commonly used and de-facto standard implementation OpenSSH, for the latter case, uses a file for each user on the server, normally located under the user's home directory as $HOME/.ssh/authorized_keys, which lists the publickeys valid for that user. If the client process specifies a username and a publickey listed in that user's authorized_keys file, and uses the privatekey to sign certain data including a connection secret and nonces, that is considered to prove the identity of the user. (See RFC 4252 for details, but start with 4253 for context.) Other implementations need to have equivalent data, although not necessarily that exact file. The host/server usually allows the user/client to make several attempts, in case it has multiple keys and/or other methods to try, but this is configurable.

SSH by itself mostly doesn't control access; it just establishes the user/client's identity as a username configured on the 'host'. Using that identity to control access -- what security people call authorization as opposed to identification and authentication -- depends on the host. Many SSH hosts are Unix, and for Unix the same rules apply to accessing Unix over SSH as apply to other kinds of connection: this starts with the classic 'chmod bits' on each file allowing read,write,execute to user,group,other, and can include other things like ACLs, SELinux attributes, sudo rules, group match for signalling processes, special configuration of some things like NFS, and so on and so on. If the SSH host/server is NOT Unix, what security rules or policies it applies once you have connected and authenticated it are up to it and may be quite different.

OpenSSH (on a Unix host) also implements a few options in the authorized_keys file that impose additional restrictions on what the client can do (over that connection); see man sshd on your system or here under AUTHORIZED_KEYS FILE FORMAT. In addition, as noted there, OpenSSH supports a level of indirection: instead of directly listing every key in each applicable user's authorized_keys file you can use a (designated) 'CA' key to sign other keys, and then configure authorized_keys to accept any key signed by a listed CA key. These certificates can themselves include some restrictions; see man ssh-keygen under CERTIFICATES. This can be more convenient in a large environment with many users, hosts, or both.

SSH public key authentication

Regardless of the authentication method (password or public-key authentication) two things must happen:

"user" must come up with a password or generate a key pair;
the password hash or the public key must be configured in the server ("xxx.xxx.xxx.xxx") "user" wants to connect to.

If you are an admin (root) of the server (xxx.xxx.xxx.xxx) you can ask "user" to send you his public key and put it in the right place and you don't need to know the password of "user".

If you are "user", you need to connect to "xxx.xxx.xxx.xxx" at least once with your password so that you can upload your public key.
Here I am assuming that the SSH server is using the default OpenSSH configuration where the "authorized_keys" file of each user is in the user's home directory, under his/her control.

If you then want to "force" the authentication method to "public key", an admin will need to edit the configuration of the SSH server to disable password authentication (either for everybody or just for "user").

How does SSH public key authentication work (picking up right keys)

The protocol is bit a more involved than you think. The manpage describes that the client tells the server which key it wants to use:

The file ~/.ssh/authorized_keys lists the public keys that are permitted for logging in. When
the user logs in, the ssh program tells the server which key pair it would like to use for
authentication. The client proves that it has access to the private key and the server checks
that the corresponding public key is authorized to accept the account.

The relevant SSH rfc details that the client actually sends the whole public key with a SSH_MSG_USERAUTH_REQUEST request.

With the public key github should be able to look the corresponding user in the majority of cases. I don't know what happens when two accounts share a key, though.

Setup SFTP to use public-key authentication

In the client you need to generate its public key and add it to server's authorized key list.

The following are the commands you can use.

On client machine

ssh-keygen -t dsa -f id_dsa
mv id_dsa* ~/.ssh/
scp ~/.ssh/id_dsa.pub USER_NAME@SERVER:~/.ssh/HOST_NAME.key

On the server

cat ~/.ssh/HOST_NAME.key >> ~/.ssh/authorized_keys2

SSH authenticate with public key (not private key)

You can't use keys to authenticate in opposite order of private/public, because of the way how asymmetric cryptography works.

The alternative solution for you can be to use openssh certificates as described in manual pages and many how-to's.