# Can I recognize my server using SSH signature?



## ecnux (Dec 31, 2010)

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.


----------



## SirDice (Dec 31, 2010)

ecnux said:
			
		

> I wonder if the DSA finger is always the same.


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.


----------



## DutchDaemon (Dec 31, 2010)

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.


----------



## anomie (Jan 2, 2011)

ecnux said:
			
		

> I wonder if the DSA finger is always the same.



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?



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.


----------



## phoenix (Jan 4, 2011)

anomie said:
			
		

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



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


----------



## anomie (Jan 4, 2011)

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
> ...



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.


----------



## DutchDaemon (Jan 4, 2011)

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.


----------



## anomie (Jan 4, 2011)

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?


----------



## anomie (Jan 4, 2011)

To illustrate the host key / host key fingerprint relationship for one of my servers, see this example. 

Server side: 

```
$ 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: 

```
$ 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)?
```


----------



## phoenix (Jan 4, 2011)

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.


----------



## anomie (Jan 5, 2011)

@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.


----------



## phoenix (Jan 5, 2011)

I'll be finishing off an upgrade from 7.3 to 8.2-RC1 tomorrow, so I'll let you know after that.


----------

