Can I recognize my server using SSH signature?

E

ecnux

if ip and host name is not available or unclear. How can I recognize my server before logon?
Can i use the information when commit an ssh connection?
I wonder if the DSA finger is always the same.

Thanks.
 
ecnux said:
I wonder if the DSA finger is always the same.
Click to expand...
Yes, it's always the same. It also gets stored in ~/.ssh/known_hosts. If the key changes (or you're on a different server) ssh will notify you of this.
 
Maybe DSA fingerprints are not unique across all SSH servers in the world, but the chance that you manage to hit a wrong server with the same fingerprint by mistake is probably negligible.
 
ecnux said:
I wonder if the DSA finger is always the same.
Click to expand...

The RSA / DSA host identification keys should never change (unless you've been doing something to them manually).

ecnux said:
if ip and host name is not available or unclear. How can I recognize my server before logon?
Click to expand...

If you have the host key already saved in the file SirDice mentioned (~/.ssh/known_hosts), then you've got enough info to identify the host. However, if the hostname and IP of the server have changed, your ssh client will not recognize it, and will present you with a dialog to save the new host/IP/key information.

One strategy you could use to see if you really "know" the host in that case is copy the key fingerprint you're presented with, and then grep the following output for it:

% ssh-keygen -l -f ~/.ssh/known_hosts

If the fingerprint is there (under a different name/IP), you should be good to go. If it's not there, you have a problem.
 
anomie said:
The RSA / DSA host identification keys should never change (unless you've been doing something to them manually).
Click to expand...

Some examples of "doing something manually", that will change the host keys:
  • switching from the base /usr/sbin/sshd to ports /usr/local/sbin/sshd
  • upgrading the ports version of OpenSSH
  • re-installing the ports version of OpenSSH using different OPTIONS
  • upgrading the base OS, which includes an upgrade of OpenSSH
 
phoenix said:
Some examples of "doing something manually", that will change the host keys:
  • switching from the base /usr/sbin/sshd to ports /usr/local/sbin/sshd
  • upgrading the ports version of OpenSSH
  • re-installing the ports version of OpenSSH using different OPTIONS
  • upgrading the base OS, which includes an upgrade of OpenSSH
Click to expand...

Is that true about upgrading the OpenSSH port? If so - ouch.

Upgrading the base OS (read: rebuilding world) should absolutely not mess with the sshd host keys. I doubt I've performed as many FreeBSD upgrades as you, but after doing several dozen I have never seen /etc/ssh/ssh_host_* replaced by the process (apart from a clean install without proper backups, of course). I'd go so far as to consider it a "bug" if it did.
 
Are we confusing host keys and host fingerprints here? I think so. What changes is what's in .ssh/known_hosts. So if you're making an ssh connection from A to B right after sshd on B was upgraded or changed, A will complain about B's 'identity' having changed. If you choose to proceed, .ssh/known_hosts will be updated. This has nothing to do with key-based logins.
 
Guys, I feel we're in the Twilight Zone here. Where do you think the host key fingerprint is derived from? The host key! :)

And I'm sorry, but I have to continue to dispute the statement that standard world-rebuilding base system upgrades replace sshd(8)'s host keys (and, by extension, the host identity as presented to clients). I have never seen this behavior before. Are you saying mergemaster(8) is doing this? Or what?
 
To illustrate the host key / host key fingerprint relationship for one of my servers, see this example.

Server side:
Code: 
$ ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub 
2048 d5:1b:94:7e:c4:e4:9b:fa:45:cd:eb:62:2d:e0:9e:95 /etc/ssh/ssh_host_rsa_key.pub (RSA)

Client side:
Code: 
$ ssh blackhole.local
The authenticity of host 'blackhole.local (10.51.114.24)' can't be established.
RSA key fingerprint is d5:1b:94:7e:c4:e4:9b:fa:45:cd:eb:62:2d:e0:9e:95.
Are you sure you want to continue connecting (yes/no)?
 
Doing any of the things I listed will give you the "authenticity can't be established" message, as the RSA/DSA key fingerprint will have changed.
 
@phoenix: I'd like to request that you please pay close attention (server side: mtime / sha1sum, client side: host key id) to your host keys next time you upgrade. I believe what you're saying in this thread is incorrect. If I am wrong, and what you're describing is reproducible, I will eat humble pie.

@ecnux: You're a one-post wonder so far, and my guess is you've abandoned this thread after seeing my lengthy protestations. If so, I apologize. If not, post back if you feel your question wasn't answered.
 
You must log in or register to reply here.
Back
Top