Does Heartbleed affect ssh keys?
No, Heartbleed doesn't really affect SSH keys, so you probably don't need to replace the SSH keys you've been using.
First, SSL and SSH are two different security protocols for two different uses. Likewise, OpenSSL and OpenSSH are also two completely different software packages, despite the similarities in their names.
Second, the Heartbleed exploit causes the vulnerable OpenSSL TLS/DTLS peer to return a random 64kB of memory, but it's almost certainly limited to memory accessible to that OpenSSL-using process. If that OpenSSL-using process doesn't have access to your SSH private key, then it can't leak it via Heartbleed.
Also, you typically only put your SSH public key on servers you use SSH to connect to, and as the name implies, a public key is a key you can publicize. It doesn't matter who knows it. In fact, you want the public to know your correct public key.
Thanks to @Bob for pointing out that the vulnerability can affect client apps that use vulnerable versions of OpenSSL as their client-side TLS/DTLS library. So if, for example, your web browser or your SSL-based VPN client used a vulnerable version of OpenSSL, and connected to a malicious server, that malicious server could use Heartbleed to see random snippets of that client software's memory. If that client app for some reason had a copy of your SSH private keys in memory, then it could leak via Heartbleed.
Off the top of my head, I'm not thinking of any software besides SSH that could have a copy of your unencrypted SSH private key in memory. Well, that assumes you keep your SSH private keys encrypted on disk. If you don't keep your SSH private keys encrypted on disk, then I suppose you could have used some OpenSSL TLS-using file transfer or backup program to copy or back up your home directory over the network (including your ~/.ssh/id_rsa or other SSH private key), then it could have an unencrypted copy of your SSH private key in memory. Then again, if you were backing up your unencrypted SSH private key to a malicious server, you've probably got bigger worries than Heartbleed. :-)
"Second, the Heartbleed exploit causes the vulnerable OpenSSL TLS/DTLS peer to return a random 64kB of memory, but it's almost certainly limited to memory accessible to that OpenSSL-using process. "
if the machine gets compromised then how can you trust anything on it, including ssh? from heartbleed.com
" What leaks in practice?
We have tested some of our own services from attacker's perspective. We attacked ourselves from outside, without leaving a trace. Without using any privileged information or credentials we were able steal from ourselves the secret keys used for our X.509 certificates, user names and passwords, instant messages, emails and business critical documents and communication. "
someone might have put a private key, with no passphrase, on a server they assumed wasnt malicious... but turned out to be. b/c SSL bug allowed a user's password out, a user who had 'sudo'... its probably not an issue.... but...
people do crazy stuff sometimes
http://blog.visionsource.org/2010/08/28/mining-passwords-from-public-github-repositories/