ssh question

[Joseph Sinclair]

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

Some *possible* causes:
1) More than one machine thinks it has IP 192.168.2.124 and there is an ARP conflict.
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.
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)

If the machines are DHCP, have both release and renew their lease (and make sure there's only one DHCP server on the network!).
If they're static configured, check /etc/network/interfaces and make sure the subnet mask is the same on both.
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
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
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 at 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 at 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 at 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>>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: OpenPGP digital signature
URL: <http://lists.PLUG.phoenix.az.us/pipermail/plug-discuss/attachments/20110618/4e70ebb1/attachment.pgp>