CODEWITHSUNDEEP
authenticationgithubssh
automatix
automatix

Reputation: 14532

How does the GitHub authentification work?

If you follow the GitHub HowTo "Generating SSH Keys", you get three files in your ~/.ssh directory: known_hosts, id_rsa, and id_rsa.pub.

The file known_hosts is used for the server authentication, id_rsa is used for the client authentification (here is an article, that explains the difference).

Why should I create / why GitHub does need both -- a host and a user authentification files? How does the GitHub authentification work?

Thx

Upvotes: 1

Views: 2556

Answers (3)

Joachim Isaksson
Joachim Isaksson

Reputation: 180917

  • known_hosts stores the server's identity the first time you connect, so that you know the next time that you're connecting to the same server. This prevents someone from pretending to be the server the next time you connect (but sadly not the first time)

  • id_rsa is your secret key that proves that you are really you. Never give this away.

  • id_rsa.pub is the public key, its purpose for authentication is basically just to prove that you have the secret key without giving it out. This key you can give to anyone what needs it since there's nothing secret about it.

When you connect to the server, SSH first checks that the server has the correct key (ie it should match the one in known hosts. If the client is comfortable that the server is genuine, it uses its private key to sign the following data and sends it to the server;

  string    session identifier
  byte      SSH_MSG_USERAUTH_REQUEST
  string    user name
  string    service name
  string    "publickey"
  boolean   TRUE
  string    public key algorithm name
  string    public key to be used for authentication

The server verifies the signature using the public key (which you earlier uploaded to Github), and if it is correct, the client is authenticated.

Upvotes: 4

Eevee
Eevee

Reputation: 48546

This is just plain old SSH authentication; nothing about it is specific to GitHub.

id_rsa and id_rsa.pub are the two halves of your key: the private key and the public key. Effectively, the public key is the lock for the private key. You put the lock (public key) on whatever servers you want easy access to, without too much worry that someone else will see it, because it's just a lock. You keep the (private) key on your machine, and use it to log into those servers; they see you have a key fitting the lock, and let you in.

(Not to say that you should put your public key on completely untrustworthy machines; there are malicious tricks that can take advantage of shortcuts like ssh -A.)

known_hosts doesn't actually have much to do with this; it's just where ssh stores the fingerprints of all the servers you've connected to, so it can throw up a big scary warning if the fingerprint changes. (That would mean it's not the same machine: either something has changed radically on the server side, or your connection has been hijacked.)

So, anyway, one of the protocols Git itself understands is SSH. When you use [email protected]:... as a repository URL, Git is just connecting over SSH. Of course, GitHub doesn't want you mucking around on their machines, so they only let you do Git things, not get a full shell.

As usual, the Arch wiki has a whole lot more words on this.

Upvotes: 6

shat
shat

Reputation: 212

The known_hosts file is used by ssh whenever you actually connect to a host via SSH. It stores a signed key of sorts for the server. Then, if it changes, you will know.

ssh-keygen -t rsa -C [email protected] is used to generate the SSH key in which you will give the id_rsa.pub to github. Then, when you connect to github you have the private key id_rsa in your ~/.ssh folder which is then used to validate your information with github.

This is a very low-level explanation, but the private key (non .pub) file is your end, the .pub is for github and the known_hosts is for your box to know what is what.

You can also generate a config file in ~/.ssh for use to specify which key goes to which host..

authorized_keys and known_hosts are entirely different..

Your SSH server (sshd, ie) uses authorized_keys, or whatever file is defined within your /etc/ssh/sshd_config/ for knowing the public side of another key. So when a user connects to your server, they pass their private key, your SSH server verifies against the public key it has within authorized_keys and if it doesn't match, it doesn't work.

Github maintains an authorized_keys so-to-speak on their users. Your public key goes into your authorized_keys on your account and then when you connect via ssh to clone,push,etc, it checks your private key you send over with your public key they already know.

Upvotes: 1

Related Questions