Re: ssh host ip/id management for dynamic dns servers [OT?]
On Tue 11 Feb 2014 at 06:52:10 -0700, Paul E Condon wrote: I'm puzzled about the apparent 'security theater' on this topic. Known host checking is done, I think, to defend against 'man in the middle', so when the known host key changes because of some event down in the bowels of dynamic dns, does one have any possibility of determining that it is truly *not* a man-in-the-middle attack? Is there some method for checking up on dynamic dns changes other than merely noting the new value and adapting to it? The IP address of the machine may change but its fingerprint doesn't. So you check that. Some people use 'VisualHostKey yes' as a memory aid. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/12022014130038.4f3b3bd04...@desktop.copernicus.demon.co.uk
Re: ssh host ip/id management for dynamic dns servers [OT?]
I'm puzzled about the apparent 'security theater' on this topic. Known host checking is done, I think, to defend against 'man in the middle', so when the known host key changes because of some event down in the bowels of dynamic dns, does one have any possibility of determining that it is truly *not* a man-in-the-middle attack? Is there some method for checking up on dynamic dns changes other than merely noting the new value and adapting to it? Just puzzled. I don't really expect an answer that I would understand. :-) On 20140211_152226, Lars Noodén wrote: On 02/11/2014 02:56 PM, Zenaan Harkness wrote: On 2/11/14, Brian a...@cityscape.co.uk wrote: On Tue 11 Feb 2014 at 10:10:37 +1100, Zenaan Harkness wrote: I'm wondering: 1) how to easily clean known_hosts ssh-keygen with the -R option. Sounds great! (also, the CheckHostIP = no option looks very useful in this regard, thanks Karl) However - it seems to not work for me? : $ HOST=raptor $ ssh-keygen -r $HOST raptor IN SSHFP 1 1 81488c713a821a5d232fadaaf57ec9699e3e3a5e raptor IN SSHFP 1 2 928b7a09cce6c42e52ded51ad8e49b6bc24afa23adc62c7c51b7507ec30aac31 raptor IN SSHFP 2 1 137e0fd7551bd8485b91935274d8f1afcf6be3ba raptor IN SSHFP 2 2 b2e15796502c956b5ecaf4c66848390b11d79ebe16ecbf5efb838630d5ae3846 raptor IN SSHFP 3 1 a7abbd8e090c23371fd335d7bd01fc8238edd08a raptor IN SSHFP 3 2 5002cd18247173fc72d979ee2f50185d5f5ac72e2e7ecf02f77c7de8b5a6dcc7 $ ssh-keygen -R $HOST /home/justa/.ssh/known_hosts updated. Original contents retained as /home/justa/.ssh/known_hosts.old $ ssh-keygen -r $HOST raptor IN SSHFP 1 1 81488c713a821a5d232fadaaf57ec9699e3e3a5e raptor IN SSHFP 1 2 928b7a09cce6c42e52ded51ad8e49b6bc24afa23adc62c7c51b7507ec30aac31 raptor IN SSHFP 2 1 137e0fd7551bd8485b91935274d8f1afcf6be3ba raptor IN SSHFP 2 2 b2e15796502c956b5ecaf4c66848390b11d79ebe16ecbf5efb838630d5ae3846 raptor IN SSHFP 3 1 a7abbd8e090c23371fd335d7bd01fc8238edd08a raptor IN SSHFP 3 2 5002cd18247173fc72d979ee2f50185d5f5ac72e2e7ecf02f77c7de8b5a6dcc7 So it looks like the host raptor is not removed from known_hosts.. ?? ssh-keygen -r checks the SSHFP record in DNS. Use grep or something to check known_hosts. For me, ssh-keygen -R does not remove all the dynamically generated host keys, however. I've not yet identified what confounds ssh-keygen. Regards, /Lars -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52fa2412.3020...@gmail.com -- Paul E Condon pecon...@mesanetworks.net -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140211135210.ga14...@big.lan.gnu
Re: ssh host ip/id management for dynamic dns servers [OT?]
Paul E Condon: I'm puzzled about the apparent 'security theater' on this topic. Known host checking is done, I think, to defend against 'man in the middle', Exactly. so when the known host key changes because of some event down in the bowels of dynamic dns, does one have any possibility of determining that it is truly *not* a man-in-the-middle attack? DynDNS doesn't have anything to do with your host key. The host key doesn't change. If OpenSSH really alerts you of a changed host key, then you are either not connecting to the system you expected to connect to or its host key really has changed. OpenSSH just records keys of hosts it has connected to using the IP address *and* the name of the host. If the IP changes, OpenSSH doesn't know the new combination of IP address and hosts key and therefore asks to store it (again) in the known_hosts file. CheckHostIP no should take care of that issue. J. -- I worry about people thinking I have lost direction. [Agree] [Disagree] http://www.slowlydownward.com/NODATA/data_enter2.html signature.asc Description: Digital signature
Re: ssh host ip/id management for dynamic dns servers [OT?]
On 02/11/2014 03:52 PM, Paul E Condon wrote: ... Known host checking is done, I think, to defend against 'man in the middle', so when the known host key changes because of some event down in the bowels of dynamic dns, does one have any possibility of determining that it is truly *not* a man-in-the-middle attack? Is there some method for checking up on dynamic dns changes other than merely noting the new value and adapting to it? ... The host key does not change in this case, it's just that with dynamic DNS the same host gets a new IP address. That means that the same key can have multiple entries in known_hosts. known_hosts can get long and unwieldy, filling with ip numbers that will never be used again. In the case where the host key does get changed (system replaced without backing up keys, for example) then StrictHostKeyChecking set to 'yes' or 'ask' shows the fingerprint before adding it to known_hosts. It is also possible to pre-load in advance the user's known_hosts or the system's known host with the appropriate public key. Regards, /Lars -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52fa3a23.3040...@gmail.com
