[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: I need guidance about how to configure a newly installed Jessie



On 20150419_0830+0200, Petter Adsen wrote:
> On Sat, 18 Apr 2015 20:18:17 -0600
> Paul E Condon <pecondon@mesanetworks.net> wrote:
> 
> > On 20150418_1905-0500, David Wright wrote:
> > > Quoting Paul E Condon (pecondon@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
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           
pecondon@mesanetworks.net


Reply to: