SSH public-key authentication is challenge-response.
Your public and private keys are mathematically related, but computing the private key from the public key is in theory impossible. The key values are chosen such that only someone who possesses the private key can decrypt a message that has been encrypted using the associated public key.
Continuing with the simplified explanation, the authentication sequence goes along the lines of
ek_ny: Hi, I’m ek_ny, and my public key is abc123
.
c9.io: Oh yeah? Well, if you really are ek_ny, then you know what I mean when I send you [encrypts secret message “The magic words are squeamish ossifrage”] 00:01:02:03:aa:...
ek_ny: As a matter of fact, you sent me [decrypts] “The magic words are squeamish ossifrage.”
c9.io: ek_ny, my old buddy! Good to see ya! C’mon in!
With SSH, both users and hosts have keys. This is why SSH asks you to confirm the host’s key the first time you connect. The intent is to detect man-in-the-middle attacks. The entire conversation is encrypted, thanks to Diffie-Hellman that bootstraps the process.
At no point did you actually exchange sensitive information. This is the idea of challenge-response. Say you have a physical key that you claim unlocks a door. To demonstrate this for me, you could give me the key, but I might not give it back. Maybe you don’t even want me to see what is behind the door. Sufficient to prove your claim is being able to crack the door open only slightly, and you never lose possession of your key to do so.
See also: How is using a public-key for logging in to SSH any better than using a password? on Unix & Linux SE.