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 <
lisakachold@obnosis.com>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:~$
>
> <sometimes it's ssh not sshd>
>
> 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 <lthielster@gmail.com> 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: <LOOPBACK,UP,LOWER_UP> 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: <BROADCAST,MULTICAST,UP,LOWER_UP> 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: <BROADCAST,MULTICAST> 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.
>>>
>>> <<SNIPSNIPSNIP>>
>>> > 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.
>>> >
>>> <<SNIPSNIPSNIP>>
>>>
>>>
>>> ---------------------------------------------------
>>> 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 <http://www.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
(text/plain)