SSH: What's the difference or interplay between /etc/ssh/[host files] and ~/.ssh/[public key]

Question

I'm new to SSH after a decade of dabbling with Ubuntu and other Linux builds. Today I successfully setup SSH, but I had a few hangups and headaches along the way. Although the system is now running properly, I'm not entirely sure how it's working, and that's driving me mad.

The main headache I was running into for awhile was this:

1. I'd SSH into my Ubuntu machine via OS X and the "ssh" command. When I did that, I would get the warning that this was a new host I was connecting to, and I was given an RSA fingerprint.
2. I'd then access my Ubuntu machine (via VNC) and run ssh-keygen -lf [public key], and the fingerprint was different.
3. Frustration.

After poking around for awhile, I discovered the /etc/ssh/ssh_host_rsa_key.pub. Long story short, I checked the fingerprint, and voila, that's where OS X was getting the fingerprint. Inside of the same folder, I see what appears to be a matching private key (verified by checking fingerprint) Excellent.

So now my assumption is that these are pre-made default keys that you can use without having to generate your own keys or any of that. Because I have generated my own (password protected) keys, I wanted to replace them. So then I went into the SSHD_config file and changed the directory for the RSA key to my home directory (~/.ssh/[public key inside of authorized_keys file]). And then I deleted the ssh_host_rsa_key.pub. That didn't work. I rebuilt the host keys, undid the configuration change, left my generated public key in the home directory, and moved the generated private key to the client. The connection works great, and the fingerprint OS X (my client) prompts me with matches the ssh_host_rsa_key.pub.

Moreover, I know the security is working, because if I remove the authorized_keys file from my home/.ssh/, my client can no longer connect.

My questions:

1. If OS X, my client, is telling me that the fingerprint is that of the ssh_host_rsa_key.pub, why am I able to connect without a matching private key?

2. Put differently, what role does the ssh_host key play (without a matching private key being on the client), when I'm also needing the generated private and public key to be properly in place?

3. Is it accurate to say that ssh requires two public keys and one private key to connect properly? Or should I overwrite the contents of /etc/ssh/ssh_host_rsa_key.pub with the contents of my generated public key (which is also in authorized users)? [Edit: I tried replacing the ssh_host_rsa_key.pub and ssh_host_rsa_key with my generated private and public keys (renamed, of course). When I tried restarting SSH service, I get "End must be KEY=VALUE pairs"). So I broke the SSH service.]

Thanks in advance for the help. I've been Googling for hours, and even called my more-tech-savvy friend, who happens to work at Google. And I haven't gotten an answer.

Answer 1

Host keys authenticate the server to you, your keys authenticate you to the server.

The SSH Host Key provides a fingerprint that you can use to validate you're connecting to the server you think you are. You manually verify the public key fingerprint you're presented during your first connection, then you save it. For every connection after that, the server sends you something which proves it holds the private key that matches that public key, so you know it is the server that you manually verified that first time (...because only that server has that private key).

This is completely separate from the key pair that you use to authenticate yourself to the server. They're both key pairs, yes, but held by different entities, for different purposes, at different points in the connection process.

In all, the SSH connection requires two key pairs -

• Your Client software checks the Server's (host) public key against data the server sends encrypted with the host private key. This requires you to have a copy of its public key, which you're handed at the first connection and your client stores if you approve of it.
• The Server checks your authentication data encrypted with your user private key using the copy of your user public key that it has a copy of because you put it there (or had someone put there for you).