On 20150417_1408-0500, David Wright wrote: > Quoting Paul E Condon (pecon...@mesanetworks.net): > > > I have four desktop machines running Jessie. I try to keep them a;; > > upgraded on whenever new package versions are released. I thought it > > would be fast and simple. I was very wrong. This install behaves very > > differently in the following way: When I attempt to ssh into one of > > the computers that was not re-installed, I get a complaint that: > > > > @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ > > @ WARNING: POSSIBLE DNS SPOOFING DETECTED! @ > > @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ > > The RSA host key for gq has changed, > > and the key for the corresponding IP address 192.168.1.12 > > is unknown. This could either mean that > > DNS SPOOFING is happening or the IP address for the host > > and its host key have changed at the same time. > > This I do not receive, perhaps because my router knows my MAC and > gives me my static IP number. > > > @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ > > @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ > > @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ > > IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! > > Someone could be eavesdropping on you right now (man-in-the-middle attack)! > > It is also possible that a host key has just been changed. > > The fingerprint for the RSA key sent by the remote host is > > 51:cf:52:87:6f:13:43:50:73:29:2c:b4:34:11:cd:5c. > > Please contact your system administrator. > > Add correct host key in /home/pec/.ssh/known_hosts to get rid of this > > message. > > Offending RSA key in /etc/ssh/ssh_known_hosts:3 > > remove with: ssh-keygen -f "/etc/ssh/ssh_known_hosts" -R gq > > RSA host key for gq has changed and you have requested strict checking. > > Host key verification failed. > > This one is very familiar, and is something I wanted to avoid when > installing via ssh and network-console. > > You're presumably running ssh as pec. What I'm not sure about is why > you're using /etc/ssh/ssh_known_hosts rather than > /home/pec/.ssh/known_hosts , because you need root to maintain the > former.
I was running as pec or as root. I forget. Since doing that, I realized that for many years I have been running with my own version of /etc/ssh/ssh.config. Confronted with the evidence, I recall that this was a place I found, through exhaustive search, to turn off the hashing of known_host. I like to be able to identify lines in known_host, because I think each line is a possible access path for a hacker and the sysadmin, namely me, should be able to trace the provenance of all such lines. In short hashing them opens a backdoor more serious than the one it closes, IMHO. I now know that I can put my edits in two places, /home/pec/.ssh/ssh_config and /root/.ssh/ssh_config, and have the same effect. I can envision a different way, but I cannot envision one that does not impact of how Debian wants to configure Jessie. So be it. I have not yet discovered a way to append new known host keys from newly configured hosts into the .ssh/known_hosts files on older computers. I envision that, before I die, all traffic on the web will be monitored by at least one spy organization of another. Maybe it is already so. The job of personal sysadmin will be to allow monitoring by agencies one knows and trusts, and disallows monitoring by others. Frankly I trust the CIA more that the FBI, but both are more trustworthy than Facebook ;-\ Debian has a much bigger problem than I have. But all this comment is just policy without effective implementation. > > > I get this same complaint even after I remove the known_hosts file > > entirely. How can the software retain the information that the offending > > line is the third line? It must be doing more than the documentation > > that I have says its doing, > > There are potentially two files. "the known_hosts file" implies you've > deleted one of them. I think the removed file was the one associated with either pec, or root, which ever was appropriate for a test. Since doing the tests, I have done a complete re-install. With that removing the appropriate known_hosts file gives me the old familiar option of accepting the risk of man-in-the-middle. > > > This is a home lan. I use a hosts file to > > inform the several computers of the IP addresses of all the computers in > > the LAN. The file is identical on all computers and hasn't changed sine > > etch. > > Same here. The router doesn't have a resolver, so I type hostnames and > hosts gives me the static IP numbers. > > > In the past, I was given the option of typing the login password of the > > computer that I want to log into, but not now. > > I'm not sure why you call it an "option". The default is to require > typing a password (of the user, not the computer), and we avoid that > by giving the remote host a "question" (our public key, placed it its > authorized_keys file) to which only we know the "answer" (our private > key, in our id_rsa file). > > > I don't understand what I should do with the RSA 'fingerprint' doesn't > > look at all like a legitimate line in a known_host file. How is it used? > > On the odd occasion that I keep the newly-installed host keys (usually > when I notice a new type of key in /etc/ssh/) I type, for example, > $ ssh-keygen -l -v -f /etc/ssh/ssh_host_ecdsa_key.pub > .../ssh-fingerprint > where ... is the place you keep your configuration records. I have gotten away with not having a place to keep configuration records from when I started with Debian Potato until now. I don't recall using ssh in Potato. Times change. I will, also. > That's the remote hosts's fingerprint you check when you get the > warning. (I don't know how to get a host to send the randomart.) > > > Where is the source of this occult knowledge? > > man ssh-keygen is your friend. Yes. But ... ;-) > > > Why does the author of the WARNING presume that there is a different > > person, other than the person reading the message who is the actual > > 'your system administration'? Has someone in NSA or CIA been assigned > > to monitor me, and this message breaches global security because I > > should not be allowed to know that I am being watch? This should have been marked as a rant. Sorry. > > Because if you were logging in to your unix account at work, say, > you'd pick up the phone and ask the operators what in h*ll's name are > they up to! In other words, ssh assumes the remote host really is > remote. You (local) get the warning, but the host that might have been > compromised (if it's not man-in-the-middle) is the remote one. > > Cheers, > David. As said before, I am working now with a new re-install on my main computer. It is the one on which I am composing this email. This is its /etc/hosts file: root@big:/home/pec# vim /etc/hosts root@big:/home/pec# cat /etc/hosts 127.0.0.1 localhost 127.0.1.1 big.lan.gnu big 192.168.1.1 rtr.lan.gnu rtr # LAN side of router 192.168.1.10 cmn.lan.gnu cmn 192.168.1.11 big.lan.gnu big 192.168.1.12 gq.lan.gnu gq 192.168.1.13 dl2.lan.gnu dl2 192.168.1.15 acr.lan.gnu acr 72.19.128.53 dns1 72.19.128.99 dns2 209.249.170.98 pop.everyone.net 216.200.145.17 smtp.everyone.net The top two lines were provided during the running of netinst CD RC2. The rest were provided by me, after I took the CD out of the computer and rebooted. With this, I can ssh into 'gq' from 'big', which is my main computer with the big flat screen display. I can open and edit files on 'gq' and the edits will be saved. No problem. But, if I sit down the keyboard and screen connected to 'gq', I cannot do the reverse. On 'gq', the /etc/hosts file contains all the lines as on 'big', except for the first two. Working on 'gq', I cannot ping 'gq'. Can you tell be why, and what I can do to make the ping possible. It would be very educational for me, and maybe all other problems will fall away in my basement. Notice the difference in IP address for localhost and big.lan.gnu . This is real, not a typing mistake in transcription. Is it important? Cheers, -- 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: https://lists.debian.org/20150418182211.gb3...@big.lan.gnu
