[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 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  Mask:255.255.255.0
          inet6 addr: fe80::226:18ff:fe3d:9516/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:19437844 errors:0 dropped:0 overruns:0 frame:0
          TX packets:9044464 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:6902058999 (6.4 GiB)  TX bytes:614484187 (586.0 MiB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:133796 errors:0 dropped:0 overruns:0 frame:0
          TX packets:133796 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:24013613 (22.9 MiB)  TX bytes:24013613 (22.9 MiB)

root@big:~# 
On 'gq' I get:
root@gq:~# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:04:76:9b:5f:51  
          inet addr:192.168.1.12  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::204:76ff:fe9b:5f51/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:80599171 errors:0 dropped:1593 overruns:0 frame:0
          TX packets:167586093 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:2785863717 (2.5 GiB)  TX bytes:4005779844 (3.7 GiB)
          Interrupt:19 Base address:0x400 

eth1      Link encap:Ethernet  HWaddr 00:c0:a8:88:ca:69  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:61047 errors:0 dropped:0 overruns:0 frame:0
          TX packets:61047 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:54521327 (51.9 MiB)  TX bytes:54521327 (51.9 MiB)

root@gq:~# 
For arp -n -v I get:
root@big:~# arp -n -a
? (192.168.1.13) at 00:14:22:39:df:8a [ether] on eth0
? (192.168.1.10) at 00:13:72:b3:ac:11 [ether] on eth0
? (192.168.1.1) at e0:91:f5:ca:d7:2e [ether] on eth0
? (192.168.1.12) at 00:04:76:9b:5f:51 [ether] on eth0
root@big:~# 
And:
root@gq:~# arp -n -a
? (192.168.1.14) at 00:1f:f3:06:a6:0e [ether] on eth0
? (192.168.1.12) at 00:26:18:3d:95:16 [ether] on eth0
? (192.168.1.11) at <incomplete> on eth0
? (192.168.1.10) at 00:13:72:b3:ac:11 [ether] on eth0
? (192.168.1.1) at e0:91:f5:ca:d7:2e [ether] on eth0
? (192.168.1.13) at 00:14:22:39:df:8a [ether] on eth0
? (192.168.1.16) at 00:26:18:3d:95:16 [ether] on eth0
? (64.93.112.226) at e0:91:f5:ca:d7:2e [ether] on eth0
root@gq:~# 
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.

> 
> > 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

The above discusses a number of options for solving the
problem. IMHO, by now one of these options must surely have been
decided upon, implemented and fully debugged. Which one is it?

> 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. 

Now, I think you understand why I need your help. I have managed to
set up a local area network *without*knowing*what*I*was*doing* and now
it's broken and requires fixing, which I cannot do because I don't know
how it really works, or what tools are available to diagnose and fix it.

> 
> 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 ;-)
-- 
Paul E Condon           
pecondon@mesanetworks.net


Reply to: