On 20150419_0826-0600, Paul E Condon wrote:
> On 20150419_0830+0200, Petter Adsen wrote:
> > On Sat, 18 Apr 2015 20:18:17 -0600
> > Paul E Condon <pecon...@mesanetworks.net> wrote:
> >
> > > On 20150418_1905-0500, David Wright wrote:
> > > > 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...
> > >
> > > I don't think I have a problem with exim. I use msmtp to get emails
> > > out onto the web. I tried doing it with exim4 about 2yrs ago. It kept
> > > breaking so I found alternative for a previous stand-alone smtp agent
> > > that was being discontinued due to lack of upstream support at about
> > > the same time that Debian was moving from plain exim to exim4. I
> > > could try again, but after I get ssh working both directions, I hope.
> > >
> > > >
> > > > 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).
> > >
> > > On 'big' ifconfig gives:
> > > root@big:~# ifconfig
> > > eth0 Link encap:Ethernet HWaddr 00:26:18:3d:95:16
> > > inet addr:192.168.1.16 Bcast:192.168.1.255
> > ^^
> > In your previous mail (the one with your /etc/hosts) 'big' had
> > 192.168.1.11, and here it has .16 - edit your hosts files accordingly,
> > or set the address on 'big' back to .11 and you should be fine :)
> >
> > > I don't have a authoritative information as to whether or not these
> > > MAC addresses are correct. I'd like to know how to query each box and
> > > get the MAC address that it is actually using. I think we need that
> > > to go beyond pure theory and get to real practice. But how? Specific
> > > advice needed, please.
> >
> > The field "HWaddr" in the ifconfig output above gives you the MAC
> > address for that interface.
> >
> > > > How are you making sure that your router uses the IP numbers that
> > > > are in your hosts file?
> > >
> > > If I have been told how to make sure of this, I am too dense to
> > > realize it. Please, what tool or utility helps accomplish this?
> > >
> > > I await your reply anxiously ;-)
> >
> > On your router, depending on make and model, there is usually a page in
> > the web interface where you can map MAC addresses to IP addresses, if
> > the router assigns those via DHCP.
> >
> > Sorry for butting in on your discussion like this, but I was up early :)
> Thanks, Petter.
> No need to be sorry. But this router only displays the information that
> it has observed. It offers no edit facility that I can find. We now know
> that there is a disagreement on the IPv4 address of 'big', but the router
> didn't cause the disagreement and is unwilling to help in fixing it.
> There is a 'refresh' button which is intended for use after one thinks
> the problem is fixed. Once I learn where to fix it I think I will change
> it to 192.168.1.10 which I have been using for several years until the
Should be
192.168.1.11
Oh well. Again a typo that makes a hash of what I really meant to say.
> advent of Jessie. Now it is 12:50am here, and I am going to bed.
>
> Thanks again for finding the exact cause of the problem.
> 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/20150419145206.gc7...@big.lan.gnu
