Yes, It's a layer of things to check for ssh. Glad you fixed it! On Sun, Jun 19, 2011 at 1:07 AM, Dazed_75 wrote: > Hi back Lisa :) > > sshd seems to be running from > larry@lapdog2:~$ ps aux | grep ssh > larry 1692 0.0 0.0 3368 192 ? Ss 00:20 0:00 > /usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-session gnome-session > --session=ubuntu > larry 2065 0.0 0.1 5296 2292 pts/0 S+ 00:22 0:00 ssh > triggerfish > root 2350 0.0 0.1 5652 2260 ? Ss 00:28 0:00 > /usr/sbin/sshd -D > larry 2519 0.0 0.0 4156 860 pts/1 S+ 00:32 0:00 grep ssh > > > On Sat, Jun 18, 2011 at 8:28 PM, Lisa Kachold wrote: > >> Hi Larry, >> >> Can you get to lapdog2 to stop and restart the /etc/init,d/sshd daemon? >> >> /etc/init.d/sshd restart >> > But > larry@lapdog2:~$ sudo /etc/init.d/sshd restart > sudo: /etc/init.d/sshd: command not found > so I looked into /etc/init.d/ssh and it looked like it also dealt with sshd > so I tried: > larry@lapdog2:~$ sudo /etc/init.d/ssh restart > Rather than invoking init scripts through /etc/init.d, use the service(8) > utility, e.g. service ssh restart > > Since the script you are attempting to invoke has been converted to an > Upstart job, you may also use the stop(8) and then start(8) utilities, > e.g. stop ssh ; start ssh. The restart(8) utility is also available. > ssh stop/waiting > ssh start/running, process 2536 > larry@lapdog2:~$ sudo service sshd restart > sshd: unrecognized service > larry@lapdog2:~$ sudo service ssh restart > ssh start/running, process 2673 > larry@lapdog2:~$ > > > >> >> >> >> If you have verified it is on on that server and listening: >> >> # /etc/init.d/ssh status >> # netstat -ant |grep "22" >> > larry@lapdog2:~$ /etc/init.d/ssh status > * sshd is running > larry@lapdog2:~$ netstat -ant |grep "22" > > tcp 0 0 0.0.0.0:22 0.0.0.0:* > LISTEN > tcp 0 0 192.168.2.124:56162 74.125.225.88:443 > ESTABLISHED > tcp 0 0 192.168.2.124:35927 74.125.225.86:443 > ESTABLISHED > tcp 0 0 192.168.2.124:34110 192.168.2.123:22 > ESTABLISHED > > tcp6 0 0 :::22 :::* > LISTEN > larry@lapdog2:~$ > > > >> >> You can then go to your remote system and run nmap with stealth settings >> to verify that port 22 is not filtered by iptables or something else >> (listening on eth0 instead of wlan1 or eth1). >> >> # nmap -P0 lapdog2 > > larry@triggerfish:~$ nmap -P0 lapdog2 > > Starting Nmap 5.00 ( http://nmap.org ) at 2011-06-19 00:50 MST > All 1000 scanned ports on lapdog2 (192.168.2.124) are filtered > > Nmap done: 1 IP address (1 host up) scanned in 201.30 seconds > larry@triggerfish:~$ ## NOTE: ufw now disabled on lapdog2 > larry@triggerfish:~$ nmap -P0 lapdog2 > > Starting Nmap 5.00 ( http://nmap.org ) at 2011-06-19 00:56 MST > Interesting ports on lapdog2 (192.168.2.124): > Not shown: 999 closed ports > PORT STATE SERVICE > 22/tcp open ssh > > Nmap done: 1 IP address (1 host up) scanned in 0.06 seconds > larry@triggerfish:~$ ssh -v lapdog2 > > Hmmm, now it works Thanks. Still puzzled because it did not work here at > home last night and ufw was definitely disabled then. I verified it here > and at UAT today and then enabled it there. I guess I need to figure out > next how to allow ssh to work even with ufw enabled. And yes, I know it > would be safer to use a non-standard port especially if this were accessible > from the WAN. > > Thanks again to everyone for guiding me through using these unfamiliar > tools so I could discover the problem! > >> >> >> On Sat, Jun 18, 2011 at 4:08 PM, Dazed_75 wrote: >> >>> Supplemental information. I have now done this in two locations (home >>> and at UAT) using 3 machines in each location (lapdog2 in both) and >>> different routers in each. I can ssh from lapdog2 to any other with one >>> exception (see next paragraph). I can also ssh from other machine to any >>> other except lapdog2 and the same exception. >>> >>> The exception is damselfish which is a netbook running ubuntu 11.04 like >>> lapdog2 (a laptop). Ubuntu 11.04 does not seem to be the common thread as >>> hammerhead works both ways and it is a desktop running 11.04. Its hard to >>> imaging laptops being the common thread but ... >>> >>> On Sat, Jun 18, 2011 at 1:02 PM, Joseph Sinclair < >>> plug-discussion@stcaz.net> wrote: >>> >>>> Based on what you're seeing below, I'd suggest looking at the IP setup >>>> on the machines and any router/gateway between the two machines. >>>> It looks like something is allowing the ICMP traffic but blocking or >>>> loosing the TCP connect for port 22. >>>> >>>> It might help to run the following commands on each machine to look for >>>> inconsistencies or errors: >>>> ifconfig -a >>>> ip addr list >>>> ip neigh >>>> ip route >>>> >>> >>> larry@lapdog2:~$ ifconfig -a >>> eth0 Link encap:Ethernet HWaddr 00:16:36:e6:1b:b9 >>> inet addr:192.168.2.124 Bcast:192.168.2.255 >>> Mask:255.255.255.0 >>> inet6 addr: fe80::216:36ff:fee6:1bb9/64 Scope:Link >>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 >>> RX packets:4187 errors:0 dropped:0 overruns:0 frame:0 >>> TX packets:4369 errors:0 dropped:0 overruns:0 carrier:0 >>> collisions:0 txqueuelen:1000 >>> RX bytes:1349793 (1.3 MB) TX bytes:621589 (621.5 KB) >>> Interrupt:18 Memory:da000000-da020000 >>> >>> 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:16436 Metric:1 >>> RX packets:12 errors:0 dropped:0 overruns:0 frame:0 >>> TX packets:12 errors:0 dropped:0 overruns:0 carrier:0 >>> collisions:0 txqueuelen:0 >>> RX bytes:720 (720.0 B) TX bytes:720 (720.0 B) >>> >>> wlan0 Link encap:Ethernet HWaddr 00:19:d2:37:3c:33 >>> 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) >>> >>> larry@lapdog2:~$ ip addr list >>> 1: lo: mtu 16436 qdisc noqueue state UNKNOWN >>> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 >>> inet 127.0.0.1/8 scope host lo >>> inet6 ::1/128 scope host >>> valid_lft forever preferred_lft forever >>> 2: eth0: mtu 1500 qdisc pfifo_fast >>> state UP qlen 1000 >>> link/ether 00:16:36:e6:1b:b9 brd ff:ff:ff:ff:ff:ff >>> inet 192.168.2.124/24 brd 192.168.2.255 scope global eth0 >>> inet6 fe80::216:36ff:fee6:1bb9/64 scope link >>> valid_lft forever preferred_lft forever >>> 3: wlan0: mtu 1500 qdisc noop state DOWN qlen 1000 >>> link/ether 00:19:d2:37:3c:33 brd ff:ff:ff:ff:ff:ff >>> larry@lapdog2:~$ ip neigh >>> 192.168.2.1 dev eth0 lladdr 00:18:f8:3e:19:c1 REACHABLE >>> larry@lapdog2:~$ ip route >>> 192.168.2.0/24 dev eth0 proto kernel scope link src 192.168.2.124 >>> metric 1 >>> 169.254.0.0/16 dev eth0 scope link metric 1000 >>> default via 192.168.2.1 dev eth0 proto static >>> larry@lapdog2:~$ >>> >>>> >>>> Some *possible* causes: >>>> 1) More than one machine thinks it has IP 192.168.2.124 and there is an >>>> ARP conflict. >>> >>> >>> >>>> Verified not true >>>> >>> >>> >>>> 2) You have VLAN's setup on the router and the tagging is off or the >>>> router isn't passing TCP traffic between the VLAN's. >>>> >>> >>> No VLANs >>> >>> >>>> 3) The two machines have subnet masks that make them think they're on >>>> different networks (e.g. 255.255.255.0 and 255.255.255.252 or /24 and /30) >>>> >>> >>> All subnet masks are 255.255.255.0 >>> >>>> >>>> If the machines are DHCP, have both release and renew their lease (and >>>> make sure there's only one DHCP server on the network!). >>>> >>> >>> Verified only one dhcp server >>> >>> >>>> If they're static configured, check /etc/network/interfaces and make >>>> sure the subnet mask is the same on both. >>>> >>> >>> Only one machine (fogtest) is staticly configured )on both routers) as a >>> static IP issued by DHCP >>> >>> >>>> Dig through your router configuration (I assume you only have one >>>> router, if not temporarily remove all but one router) to make sure you don't >>>> have VLAN's setup or that they're properly configured >>>> >>> >>> Only one router in each loaction and they seem correct >>> >>> >>>> Check the ARP tables on the machines and the router ("ip neigh" at the >>>> command line on each machine, router depends on it's interface) to make sure >>>> you don't have duplicates and the MAC address matches for each IP address on >>>> the different machines >>>> >>> >>> I'll have to research how to do that. >>> >>> >>>> example (you may see many more entries than this) (Note that >>>> 10.23.124.104 is visible on both and the MAC value matches): >>>> Machine 1 >>>> 10.23.124.104 dev eth0 lladdr 02:49:5a:9e:e2:6c STALE >>>> 10.23.124.123 dev eth0 lladdr 03:1d:7f:7f:4d:2d STALE >>>> >>>> Machine 2 >>>> 10.23.124.104 dev eth0 lladdr 02:49:5a:9e:e2:6c STALE >>>> 10.23.124.125 dev eth0 lladdr 03:1e:4f:73:29:10 STALE >>>> >>>> There should be only one entry for each IP address in the list on each >>>> machine; for a given IP address, all machines should see the same MAC >>>> address. >>>> >>>> Hopefully that helps. Inconsistent network issues like this are always >>>> difficult to track down. >>>> >>>> <> >>>> > Again, name/ip resolution is not a problem and is always working >>>> correctly. >>>> > BTW, here is an attempt from today: >>>> > larry@fogtest:~$ ssh -v lapdog2 >>>> > OpenSSH_5.3p1 Debian-3ubuntu6, OpenSSL 0.9.8k 25 Mar 2009 >>>> > debug1: Reading configuration data /etc/ssh/ssh_config >>>> > debug1: Applying options for * >>>> > debug1: Connecting to lapdog2 [192.168.2.124] port 22. >>>> > debug1: connect to address 192.168.2.124 port 22: Connection timed out >>>> > ssh: connect to host lapdog2 port 22: Connection timed out >>>> > larry@fogtest:~$ ping -c 3 lapdog2 >>>> > PING lapdog2 (192.168.2.124) 56(84) bytes of data. >>>> > 64 bytes from lapdog2 (192.168.2.124): icmp_seq=1 ttl=64 time=0.587 ms >>>> > 64 bytes from lapdog2 (192.168.2.124): icmp_seq=2 ttl=64 time=0.856 ms >>>> > 64 bytes from lapdog2 (192.168.2.124): icmp_seq=3 ttl=64 time=0.996 ms >>>> > >>>> > --- lapdog2 ping statistics --- >>>> > 3 packets transmitted, 3 received, 0% packet loss, time 2002ms >>>> > rtt min/avg/max/mdev = 0.587/0.813/0.996/0.169 ms >>>> > larry@fogtest:~$ >>>> > >>>> > Clearly the issue seems to be what is blocking communication to port >>>> 22 even >>>> > though sshd is listening on it, iptables seems to allow it and ufw was >>>> > disabled yesterday and being enabled today seems to change nothing. >>>> > >>>> <> >>>> >>>> >>>> --------------------------------------------------- >>>> PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us >>>> To subscribe, unsubscribe, or to change your mail settings: >>>> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss >>>> >>> >>> >>> >>> -- >>> Dazed_75 a.k.a. Larry >>> >>> The spirit of resistance to government is so valuable on certain >>> occasions, that I wish it always to be kept alive. >>> - Thomas Jefferson >>> >>> --------------------------------------------------- >>> PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us >>> To subscribe, unsubscribe, or to change your mail settings: >>> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss >>> >> >> >> >> -- >> (602) 791-8002 Android >> (623) 239-3392 Skype >> (623) 688-3392 Google Voice >> ** >> HomeSmartInternational.com >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> --------------------------------------------------- >> PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us >> To subscribe, unsubscribe, or to change your mail settings: >> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss >> > > > > -- > Dazed_75 a.k.a. Larry > > The spirit of resistance to government is so valuable on certain occasions, > that I wish it always to be kept alive. > - Thomas Jefferson > > --------------------------------------------------- > PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us > To subscribe, unsubscribe, or to change your mail settings: > http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss > -- (602) 791-8002 Android (623) 239-3392 Skype (623) 688-3392 Google Voice ** HomeSmartInternational.com