Quoting Paul E Condon (pecon...@mesanetworks.net): > 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.
If you're happy with not hashing, you need only put that in /etc/ssh/ssh_config (underscore, not dot) if you remove all other .ssh/ssh_config files. > 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. When upgrade runs, you'll need to keep your configuration and then run diff against the maintainer's version (suffixed .dpkg-new or .ucf-dist or some such) to fold in any changes they've made (likely to be few to none). > 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. known_hosts and authorized_keys are both text files. Each line is independent. You can cat x >> y to append contents of x to y or insert with an editor. An editor's Insert File is safe, but make sure to reconstruct the lines if cut and paste does any line wrapping, ie ssh-rsa AAAAjhdgkhkAAAAkdjkjnskjn foo@bar needs to be made back into ssh-rsa AAAAjhdgkhkAAAAkdjkjnskjn foo@bar IIRC any line from one hosts's or user's known_hosts file will work for another user and/or host, and the same with authorized_keys (though don't mix them up!). > 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. There's never a problem with wiping out known_hosts and letting it gradually be rebuilt, particularly if you know the fingerprints thusly: > > $ ssh-keygen -l -v -f /etc/ssh/ssh_host_ecdsa_key.pub > .../ssh-fingerprint > 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: > 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 [...] > 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. Well I have tried to keep things as simple as possible and I recently decided to call exim's bluff... Starting MTA:hostname --fqdn did not return a fully qualified name, dc_minimaldns will not work. Please fix your /etc/hosts setup. exim4 ok ...and configure a null domain (ie no dots in /etc/hosts outside of the IP numbers). Everything still works. > 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. It should contain the first two lines exactly the same except substitute big→gq. > Working on 'gq', I cannot ping ['big']. 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. >From what you have posted, I would imagine that big has come up as 192.168.1.X where X is not 11. /sbin/ifconfig will tell you the IP number of the machine it's run on. /usr/sbin/arp -n -a run on gq (during or soon after you have talked to gq on big) will tell you how gq sees big (recognised by its MAC address). > Notice the difference in IP address for localhost and big.lan.gnu . This is > real, > not a typing mistake in transcription. Is it important? Debian's philosophy is outlined at https://lists.debian.org/debian-boot/2005/06/msg00639.html though I mentally delete ".localdomain" as I read it. So much un*x and Internet documentation is written by and for people whose machines have an Internet address, as that's how it used to be. Not so much has been written for people running a network at home, and it tends to be inconsistent precisely because it's only applicable locally. How are you making sure that your router uses the IP numbers that are in your hosts file? Cheers, David. -- 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/20150419000506.GA13938@alum
