Cannot ssh out of NN to another machine on my LAN. Other direction works fine.
Delbert Franz
ddf at sonic.net
Fri Sep 14 14:48:17 EDT 2012
On Thu, 13 Sep 2012 10:39:50 +0200
David Kuehling <dvdkhlng at gmx.de> wrote:
> >>>>> "Delbert" == Delbert Franz <ddf at sonic.net> writes:
>
> > Have another thing I cannot get to work on the NN. I can ssh to the
> > NN from other computers in my network. However, so far, I have not
> > been able to ssh from the NN to any other machine in the network.
> > Note: I am not using dropbear but openssh-server and openssh-client.
> > Those seem to work better with Git in my limited experience. The
> > message I get back on the NN when I try to ssh to a host on my LAN is:
>
> > ssh: connect to host <whatever> port 22: Connection timed out.
>
> How is you usb0 network configured? Is it bridged to the LAN? Or is it
> merely routed? How are your routing tables set up at the hosts in
> question? Are you employing NAT somewhere on the route to/from the
> nanonote? Can you ping the other hosts? Have the other hosts an ssh
> server installed (and no firewall interfers)?
>
> cheers,
>
> David
David,
Thanks for the quick reply. I and my wife of nearly 46 years, took a
day off yesterday and spent it on Angel Island in San Francisco Bay
exploring the old Immigration Station which is partially restored. It
was active from 1910-1940 and has a rather sorry history, with its
main purpose being to keep immigrants from China OUT, based on a law
passed in 1882. Different era, different issues and values. Besides
the weather here is gorgeous. I enjoy working with computers but the
outdoors is nice too:-)
Anyway, I apologize for firing something off without the supporting
information. After sending out my "appeal" I switched back to my old
micro SD install, VERSION: 2011-08-27, of more than one year ago ( I
tend to wait a bit before upgrading to a new version.). It did ssh to
my other computers on the LAN with no problems.
So late last night, when I couldn't sleep, I started the process of
finding out what was the cause of the failure now but success before.
I first made sure that /etc/config/network was identical in both, then
that /etc/ssh/ssh_config and /etc/ssh/sshd_config were also identical.
Still no good: the latest image could not ssh nor scp but it could
ping to the names on my LAN.
I then did some fiddling with updating the authorized_keys files on
both computers but that made no difference. Then, I noticed something
that I had overlooked: when I pinged from the NN to my other LAN
machines, the IP addresses were wrong. They were all WAN addresses.
Then my foggy grey matter recalled: "I have seen this before!" There
is a problem with DNS in the /etc/config/network file!
Here is that file, as I had it on both versions:
# Copyright (C) 2006 OpenWrt.org
config interface loopback
option ifname lo
option proto static
option ipaddr 127.0.0.1
option netmask 255.0.0.0
config interface lan
option ifname usb0
option proto static
option ipaddr 192.168.254.101
option netmask 255.255.255.0
option gateway 192.168.254.100
# option dns "192.168.1.1"
option dns "192.168.1.1 208.67.222.222"
Notice that the active "option dns" line has two IP's: first a local
DNS for my LAN and second a global DNS, opendns, for when I am not
connected in my office.
Under VERSION: 2011-08-27, DNS IP's would be accessed in order from
left to right. So, if I was in my office, 192.168.1.1 would give the
proper addresses on my LAN. Outside my office, 192.168.1.1, would
fail to know anything about the machines on my LAN, and 208.67.222.222
would be used.
Here is the part that I overlooked earlier, that is, every one of my
machine names yields a valid WAN address via 208.67.222.222! One of
my machines is named "ac" and on the latest image on the NN the above
"option dns" will get some other machine somewhere in the world!
Usually when I ping, I don't look at the IP address returned, I just
look at there being a response. That appears to be a bad idea.
Then the task was to find out what was wrong in the latest image with
the old "option dns" line. I must say, the documentation for the
network file has some points that should be expanded.
http://wiki.openwrt.org/doc/uci/network, the most detailed discussion
I found on my search, describes the "option dns" in this fashion:
Name Type Required Default Description
dns list of ip addresses no (none) DNS server(s)
However, I found no discussion of how the "list of ip addresses"
should by set up. It may be someplace else on the wiki but I could not
find it. I also could not find cases with more than one IP address in
any example in the above wiki page or elsewhere on the web.
After a bit of trial and error, it appears that just reversing the
order of the IP addresses in the "option dns" gives me what works in
the latest image. So the network file that works for the latest image
is:
# Copyright (C) 2006 OpenWrt.org
config interface loopback
option ifname lo
option proto static
option ipaddr 127.0.0.1
option netmask 255.0.0.0
config interface lan
option ifname usb0
option proto static
option ipaddr 192.168.254.101
option netmask 255.255.255.0
option gateway 192.168.254.100
# option dns "192.168.1.1"
option 'dns' '208.67.222.222 192.168.1.1'
Notice that I have used single quotes here: both double and single
work. Also, all the examples in the above references wiki page, show
the use of single quotes for all responses. For example, instead of
option proto static
it would be
option 'proto' 'static'
However, I don't recall there being any quotes at all in the network
file as it comes in the latest or any earlier version for the NN.
Apparently they are optional.
So the root cause of my problem was that the order of using DNS IP's has
changed and the related cause, was my failure to notice that the ping
responses to my LAN machines were giving WAN IP addresses and not my
LAN IP addresses.
Everything is working now-I can ssh to any machine on my LAN. I also
put in an invalid dns IP for my LAN and I could still ping to machines
outside my LAN. So it seems clear that the addresses are now used in
right to left order.
Hope this helps some one else, after all the dead ends I encountered.
The major conclusion is: LOOK at the IP address returned by a PING.
It just might have a WAN value instead of a LAN value. I have no idea
why a two letter machine name makes sense to a global DNS but it
apparently does:-)
Delbert
More information about the discussion
mailing list