11:32 a.m.
Wether I run NX (nomachine) or SSH I get the same error message, no
matter what host I try to connect to.
And on the host servers SSHd is running.
And so is the Client box.
Running NX
Error message: ssh: connect to host 70.236.39.98 port 22: Connection
timed out
Running $ ssh jim(a)70.236.39.98
ErrorMessage: ssh: connect to host 70.236.39.98 port 22: Connection
timed out
6:51 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jim wrote:
On 10/02/2010 07:05 PM, JD wrote:
> On 10/02/2010 12:14 PM, Jim wrote:
>> On 10/02/2010 02:52 PM, JD wrote:
>>> On 10/02/2010 11:43 AM, Jim wrote:
>>>> ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW
tcp dpt:22
Have you made sure that the port is open for outbound connections on
the system trying to initiate the ssh connection?
iptables -nL OUTPUT|grep :22
Have you tried running ssh with -vvv for verbose output?
ssh -vvv $user@$host
Have you tried stracing the connection attempt?
strace -ffv -s 300 ssh $user@$host
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJMp8VlAAoJEBgaXYoZ++87CSoH/3DrlF+ZK/aBkyQHka/nHErD
DfX5QvUiTyR288KWwGW2TRBvMSeg1tivtEKkW8noBBywahk4rvjEU9p+BEH5XS/s
rn8IUZkj6Z21MlmlstNDzvH35UuUhSrmT5AfmitYeC590mYvTSNGigvYeVcOColk
hgcKDoEG4neZeNL3sT67i4Rj+Vy/iJw8KpA+RVbaI2Ag6fyHJrWU3680nUcbhxEa
Mtnf/mlAIyaJclK+hAdbmGPcRL2NLC84zc4SbzKWhsk8AoUFM9liu7u+tpBFjr+y
iafRTnIIVDFnPizEcDJX+MxWtxustPaWqRABXZUF0DwUjlKfsHz5xj7zZv3lYJo=
=3L/Q
-----END PGP SIGNATURE-----
5:47 p.m.
On 10/02/2010 06:19 PM, Craig White wrote:
On Sat, 2010-10-02 at 17:42 -0400, Jim wrote:
> What is the 6749 in this command ?
>
>
> # netstat -nltp | grep 22
> tcp 0 0 0.0.0.0:22
> 0.0.0.0:* LISTEN 6749/sshd
> tcp 0 0 0.0.0.0:8822
> 0.0.0.0:* LISTEN 1666/smfpd
> tcp 0 0 :::22
----
try running the command without the 'grep' portion and read the header
at the top of the column
Craig
# netstat -nltp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign
Address State PID/Program name
tcp 0 0 0.0.0.0:33824
0.0.0.0:* LISTEN 1364/rpc.statd
tcp 0 0 0.0.0.0:111
0.0.0.0:* LISTEN 1302/rpcbind
tcp 0 0 0.0.0.0:22
0.0.0.0:* LISTEN 6749/sshd
tcp 0 0 0.0.0.0:8822
0.0.0.0:* LISTEN 1666/smfpd
tcp 0 0 127.0.0.1:631
0.0.0.0:* LISTEN 1418/cupsd
tcp 0 0 127.0.0.1:25
0.0.0.0:* LISTEN 1628/sendmail: acce
tcp 0 0 :::53345
:::* LISTEN 1364/rpc.statd
tcp 0 0 :::111
:::* LISTEN 1302/rpcbind
tcp 0 0 :::22
:::* LISTEN 6749/sshd
tcp 0 0 ::1:631
:::* LISTEN 1418/cupsd
Active Internet connections (only servers) , what netstat command would
be used see if it is also a Client .
This box acts as Server and Client at different times
3:58 p.m.
On 10/02/2010 04:44 PM, Jim wrote:
On 10/02/2010 04:02 PM, Roberto Ragusa wrote:
> Jim wrote:
>> On 10/02/2010 01:11 PM, Roberto Ragusa wrote:
>>> Jim wrote:
>>>> On 10/02/2010 12:32 PM, Jim wrote:
>>>>> Wether I run NX (nomachine) or SSH I get the same error
message, no
>>>>> matter what host I try to connect to.
>>>>>
>>>>> And on the host servers SSHd is running.
>>>>> And so is the Client box.
>>>>>
>>>>> Running NX
>>>>> Error message: ssh: connect to host 70.236.39.98 port 22:
Connection
>>>>> timed out
>>>>>
>>>>> Running $ ssh jim(a)70.236.39.98
>>>>> ErrorMessage: ssh: connect to host 70.236.39.98 port 22:
Connection
>>>>> timed out
>>>>>
>>>> I forgot to add;
>>>>
>>>> These are all FC13 boxes, clients and hosts and the Firewall in each box
>>>> has SSH check as Trusted Service.
>>> Try keeping a running
>>> tcpdump -i eth0 -n -n
>>> in a different terminal before invoking ssh.
>>>
>>> You should be able to see if packets are exchanged between the machines.
>>> If you see your packets but no packet from the other machine, one of the
>>> firewalls is interfering. You can sniff on the other side too for more
>>> information.
>>>
>> Running your command I get a steady output of IP's I have never seen,
>> example below
>>
>> 14:05:10.307914 ARP, Request who-has 69.243.174.143 tell 69.243.168.1,
>> length 46
>> 14:05:10.331512 ARP, Request who-has 69.243.175.116 tell 69.243.168.1,
>> length 46
>> 14:05:10.331695 ARP, Request who-has 71.25.91.72 tell 71.25.88.1, length 46
>> 14:05:10.332746 ARP, Request who-has 69.243.175.114 tell 69.243.168.1,
>> length 46
>> 14:05:10.386862 ARP, Request who-has 69.243.170.149 tell 69.243.168.1,
>> length 46
>> 14:05:10.566254 ARP, Request who-has 69.243.174.15 tell 69.243.168.1,
>> length 46
>> 14:05:10.576918 ARP, Request who-has 73.45.175.36 tell 73.45.168.1,
>> length 46
>> 14:05:10.622413 ARP, Request who-has 69.243.174.176 tell 69.243.168.1,
>> length 46
>> 14:05:10.625877 ARP, Request who-has 73.44.155.236 tell 73.44.152.1,
>> length 46
>> 14:05:10.667900 ARP, Request who-has 69.243.175.116 tell 69.243.168.1,
>> length 46
>> 14:05:10.681633 ARP, Request who-has 69.243.175.114 tell 69.243.168.1,
>> length 46
>>
> Quite strange output: ARP requests for 69.*, 71.* and 73.* networks
> and nothing else. You only pasted 0.3 seconds of activity. Was there
> something for 70.236.39.98 when you tried to ssh?
> What kind of network connections do you have?
> Is the 70.236.39.98 machine supposed to be contacted on eth0?
>
> Would you give us some info about your network connection?
> ifconfig -a
> route -n
>
> Thanks.
# ifconfig -a
eth0 Link encap:Ethernet HWaddr 00:1D:72:A5:DD:B5
inet addr:69.243.171.15 Bcast:69.243.175.255 Mask:255.255.248.0
inet6 addr: fe80::21d:72ff:fea5:ddb5/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:509708 errors:0 dropped:0 overruns:0 frame:0
TX packets:23265 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:59884381 (57.1 MiB) TX bytes:2849745 (2.7 MiB)
Interrupt:28 Base address:0xc000
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:153 errors:0 dropped:0 overruns:0 frame:0
TX packets:153 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:9086 (8.8 KiB) TX bytes:9086 (8.8 KiB)
# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
69.243.168.0 0.0.0.0 255.255.248.0 U 1 0 0 eth0
0.0.0.0 69.243.168.1 0.0.0.0 UG 0 0 0 eth0
# tcpdump -i eth0 -n -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
16:56:59.415664 ARP, Request who-has 69.243.175.114 tell 69.243.168.1,
length 46
16:56:59.586430 ARP, Request who-has 69.243.175.116 tell 69.243.168.1,
length 46
16:56:59.696286 ARP, Request who-has 71.25.90.146 tell 71.25.88.1, length 46
16:56:59.697488 ARP, Request who-has 98.228.201.211 tell 98.228.200.1,
length 46
16:56:59.761074 ARP, Request who-has 69.243.174.73 tell 69.243.168.1,
length 46
16:56:59.773917 ARP, Request who-has 69.243.174.121 tell 69.243.168.1,
length 46
16:56:59.935273 ARP, Request who-has 69.243.173.73 tell 69.243.168.1,
length 46
16:56:59.954552 ARP, Request who-has 69.243.175.116 tell 69.243.168.1,
length 46
16:56:59.979013 ARP, Request who-has 69.243.171.85 tell 69.243.168.1,
length 46
16:57:00.138647 ARP, Request who-has 68.58.104.82 tell 68.58.104.1,
length 46
16:57:00.206853 ARP, Request who-has 98.228.201.200 tell 98.228.200.1,
length 46
16:57:00.247196 ARP, Request who-has 98.228.204.64 tell 98.228.200.1,
length 46
16:57:00.305968 ARP, Request who-has 73.45.170.17 tell 73.45.168.1,
length 46
16:57:00.332147 ARP, Request who-has 69.243.175.116 tell 69.243.168.1,
length 46
16:57:00.369043 ARP, Request who-has 69.243.172.74 tell 69.243.168.1,
length 46
16:57:00.390081 ARP, Request who-has 73.45.168.83 tell 73.45.168.1,
length 46
16:57:00.423539 ARP, Request who-has 69.243.175.114 tell 69.243.168.1,
length 46
16:57:00.434261 ARP, Request who-has 73.45.174.74 tell 73.45.168.1,
length 46
16:57:00.498231 ARP, Request who-has 73.44.154.33 tell 73.44.152.1,
length 46
16:57:00.561708 ARP, Request who-has 68.58.105.101 tell 68.58.104.1,
length 46
16:57:00.571983 ARP, Request who-has 69.243.170.149 tell 69.243.168.1,
length 46
16:57:00.732475 ARP, Request who-has 68.57.226.17 tell 68.57.224.1,
length 46
16:57:00.765076 ARP, Request who-has 68.57.225.3 tell 68.57.224.1, length 46
16:57:00.786518 ARP, Request who-has 98.193.51.254 tell 98.193.50.1,
length 46
16:57:00.842740 ARP, Request who-has 69.243.175.114 tell 69.243.168.1,
length 46
16:57:00.862463 ARP, Request who-has 73.45.172.106 tell 73.45.168.1,
length 46
16:57:01.076169 ARP, Request who-has 68.57.226.85 tell 68.57.224.1,
length 46
16:57:01.186882 ARP, Request who-has 69.243.174.134 tell 69.243.168.1,
length 46
16:57:01.190692 ARP, Request who-has 69.243.175.114 tell 69.243.168.1,
length 46
16:57:01.275670 ARP, Request who-has 68.53.190.62 tell 68.53.188.1,
length 46
16:57:01.382940 ARP, Request who-has 69.243.175.116 tell 69.243.168.1,
length 46
16:57:01.425418 ARP, Request who-has 69.243.174.143 tell 69.243.168.1,
length 46
16:57:01.523246 ARP, Request who-has 98.228.204.64 tell 98.228.200.1,
length 46
16:57:01.525805 ARP, Request who-has 73.45.173.98 tell 73.45.168.1,
length 46
16:57:01.541264 ARP, Request who-has 73.45.175.87 tell 73.45.168.1,
length 46
16:57:01.613350 ARP, Request who-has 68.53.191.125 tell 68.53.188.1,
length 46
16:57:01.851911 ARP, Request who-has 69.243.175.116 tell 69.243.168.1,
length 46
16:57:01.960023 IP 69.243.171.15.54421 > 192.168.1.127.161:
GetRequest(34) .1.3.6.1.4.1.236.11.5.1.1.1.26.0
16:57:01.966901 ARP, Request who-has 68.57.227.212 tell 68.57.224.1,
length 46
16:57:01.995638 ARP, Request who-has 69.243.168.136 tell 69.243.168.1,
length 46
16:57:02.210621 ARP, Request who-has 69.243.175.114 tell 69.243.168.1,
length 46
16:57:02.307585 ARP, Request who-has 69.243.175.116 tell 69.243.168.1,
length 46
16:57:02.342761 ARP, Request who-has 71.25.90.72 tell 71.25.88.1, length 46
16:57:02.371070 ARP, Request who-has 71.25.89.116 tell 71.25.88.1, length 46
16:57:02.427713 ARP, Request who-has 68.57.226.158 tell 68.57.224.1,
length 46
16:57:02.723353 ARP, Request who-has 69.243.175.114 tell 69.243.168.1,
length 46
16:57:02.824176 ARP, Request who-has 69.243.175.158 tell 69.243.168.1,
length 46
16:57:02.875673 ARP, Request who-has 69.243.174.157 tell 69.243.168.1,
length 46
16:57:02.881652 ARP, Request who-has 68.53.189.106 tell 68.53.188.1,
length 46
16:57:03.061478 IP 69.243.171.15.54230 > 192.168.1.127.161:
GetRequest(34) .1.3.6.1.4.1.236.11.5.1.1.1.26.0
16:57:03.068325 ARP, Request who-has 69.243.175.114 tell 69.243.168.1,
length 46
16:57:03.092348 ARP, Request who-has 69.243.169.194 tell 69.243.168.1,
length 46
16:57:03.100920 ARP, Request who-has 73.45.174.77 tell 73.45.168.1,
length 46
16:57:03.110783 ARP, Request who-has 98.228.203.213 tell 98.228.200.1,
length 46
16:57:03.330489 ARP, Request who-has 69.243.175.205 tell 69.243.168.1,
length 46
16:57:03.533885 ARP, Request who-has 68.58.105.101 tell 68.58.104.1,
length 46
16:57:03.575908 ARP, Request who-has 68.57.224.67 tell 68.57.224.1,
length 46
16:57:03.622667 ARP, Request who-has 69.243.175.116 tell 69.243.168.1,
length 46
16:57:03.712073 IP 96.183.220.1.67 > 255.255.255.255.68: BOOTP/DHCP,
Reply, length 300
16:57:03.842789 ARP, Request who-has 73.45.172.106 tell 73.45.168.1,
length 46
16:57:03.892976 ARP, Request who-has 68.58.106.175 tell 68.58.104.1,
length 46
16:57:03.928588 ARP, Request who-has 68.53.191.87 tell 68.53.188.1,
length 46
16:57:03.981374 ARP, Request who-has 69.243.170.149 tell 69.243.168.1,
length 46
16:57:03.997267 ARP, Request who-has 68.58.105.232 tell 68.58.104.1,
length 46
16:57:04.000236 ARP, Request who-has 69.243.175.116 tell 69.243.168.1,
length 46
16:57:04.076238 ARP, Request who-has 69.243.175.114 tell 69.243.168.1,
length 46
16:57:04.119096 ARP, Request who-has 73.45.173.22 tell 73.45.168.1,
length 46
16:57:04.163089 IP 69.243.171.15.45487 > 192.168.1.127.161:
GetRequest(34) .1.3.6.1.4.1.236.11.5.1.1.1.26.0
16:57:04.286451 ARP, Request who-has 68.57.225.3 tell 68.57.224.1, length 46
16:57:04.307887 ARP, Request who-has 73.45.174.24 tell 73.45.168.1,
length 46
16:57:04.432330 ARP, Request who-has 69.243.175.114 tell 69.243.168.1,
length 46
16:57:04.442184 ARP, Request who-has 69.243.175.116 tell 69.243.168.1,
length 46
16:57:04.486383 ARP, Request who-has 68.53.190.183 tell 68.53.188.1,
length 46
16:57:04.505693 ARP, Request who-has 73.45.173.98 tell 73.45.168.1,
length 46
16:57:04.534011 ARP, Request who-has 68.53.191.125 tell 68.53.188.1,
length 46
16:57:04.585934 ARP, Request who-has 69.243.173.73 tell 69.243.168.1,
length 46
16:57:04.689344 ARP, Request who-has 73.45.170.30 tell 73.45.168.1,
length 46
16:57:04.782448 ARP, Request who-has 69.243.175.114 tell 69.243.168.1,
length 46
16:57:04.821479 ARP, Request who-has 68.57.227.212 tell 68.57.224.1,
length 46
16:57:04.958797 ARP, Request who-has 69.243.169.194 tell 69.243.168.1,
length 46
16:57:04.976388 ARP, Request who-has 69.243.168.136 tell 69.243.168.1,
length 46
16:57:05.091387 ARP, Request who-has 73.45.175.28 tell 73.45.168.1,
length 46
16:57:05.229113 ARP, Request who-has 71.25.89.116 tell 71.25.88.1, length 46
16:57:05.264500 IP 69.243.171.15.42038 > 192.168.1.127.161:
GetRequest(34) .1.3.6.1.4.1.236.11.5.1.1.1.26.0
16:57:05.314496 ARP, Request who-has 68.57.226.125 tell 68.57.224.1,
length 46
16:57:05.455233 ARP, Request who-has 68.57.227.212 tell 68.57.224.1,
length 46
16:57:05.493832 ARP, Request who-has 68.57.226.158 tell 68.57.224.1,
length 46
16:57:05.547908 ARP, Request who-has 69.243.175.116 tell 69.243.168.1,
length 46
16:57:05.611407 ARP, Request who-has 69.243.175.205 tell 69.243.168.1,
length 46
16:57:05.668042 ARP, Request who-has 69.243.175.187 tell 69.243.168.1,
length 46
16:57:05.695922 ARP, Request who-has 71.25.89.79 tell 71.25.88.1, length 46
16:57:05.711371 ARP, Request who-has 98.228.201.211 tell 98.228.200.1,
length 46
16:57:05.729392 ARP, Request who-has 73.45.174.78 tell 73.45.168.1,
length 46
16:57:05.760292 ARP, Request who-has 69.243.174.73 tell 69.243.168.1,
length 46
16:57:05.784735 ARP, Request who-has 69.243.175.114 tell 69.243.168.1,
length 46
16:57:05.857692 ARP, Request who-has 69.243.173.40 tell 69.243.168.1,
length 46
16:57:05.979124 ARP, Request who-has 69.243.175.116 tell 69.243.168.1,
length 46
16:57:06.055927 ARP, Request who-has 98.228.200.238 tell 98.228.200.1,
length 46
16:57:06.240130 ARP, Request who-has 68.57.227.158 tell 68.57.224.1,
length 46
16:57:06.280316 ARP, Request who-has 69.243.175.114 tell 69.243.168.1,
length 46
16:57:06.355133 ARP, Request who-has 69.243.174.162 tell 69.243.168.1,
length 46
16:57:06.365532 IP 69.243.171.15.44654 > 192.168.1.127.161:
GetRequest(34) .1.3.6.1.4.1.236.11.5.1.1.1.26.0
16:57:06.400468 ARP, Request who-has 73.45.174.46 tell 73.45.168.1,
length 46
16:57:06.421898 ARP, Request who-has 24.14.75.28 tell 24.14.74.1, length 46
16:57:06.469113 ARP, Request who-has 68.57.224.67 tell 68.57.224.1,
length 46
16:57:06.472956 ARP, Request who-has 69.243.175.116 tell 69.243.168.1,
length 46
16:57:06.518062 ARP, Request who-has 73.44.154.33 tell 73.44.152.1,
length 46
16:57:06.561369 ARP, Request who-has 69.243.172.74 tell 69.243.168.1,
length 46
16:57:06.606415 ARP, Request who-has 71.25.88.120 tell 71.25.88.1, length 46
16:57:06.635600 ARP, Request who-has 69.243.175.114 tell 69.243.168.1,
length 46
16:57:06.827390 ARP, Request who-has 69.243.173.244 tell 69.243.168.1,
length 46
16:57:06.980999 ARP, Request who-has 69.243.170.149 tell 69.243.168.1,
length 46
16:57:07.020457 ARP, Request who-has 68.57.226.85 tell 68.57.224.1,
length 46
16:57:07.078826 ARP, Request who-has 73.45.173.22 tell 73.45.168.1,
length 46
16:57:07.146609 ARP, Request who-has 69.243.171.85 tell 69.243.168.1,
length 46
16:57:07.253030 ARP, Request who-has 73.45.170.35 tell 73.45.168.1,
length 46
16:57:07.333689 ARP, Request who-has 68.58.105.115 tell 68.58.104.1,
length 46
16:57:07.466482 IP 69.243.171.15.36786 > 192.168.1.127.161:
GetRequest(34) .1.3.6.1.4.1.236.11.5.1.1.1.26.0
16:57:07.492448 ARP, Request who-has 98.228.204.64 tell 98.228.200.1,
length 46
16:57:07.565820 ARP, Request who-has 73.45.169.103 tell 73.45.168.1,
length 46
16:57:07.605718 ARP, Request who-has 69.243.172.74 tell 69.243.168.1,
length 46
16:57:07.608225 ARP, Request who-has 68.57.224.71 tell 68.57.224.1,
length 46
16:57:07.631456 ARP, Request who-has 68.57.226.27 tell 68.57.224.1,
length 46
16:57:07.641751 ARP, Request who-has 69.243.175.114 tell 69.243.168.1,
length 46
16:57:07.673072 ARP, Request who-has 98.193.50.124 tell 98.193.50.1,
length 46
16:57:07.700956 ARP, Request who-has 69.243.175.116 tell 69.243.168.1,
length 46
16:57:07.716840 ARP, Request who-has 73.45.170.30 tell 73.45.168.1,
length 46
16:57:07.743873 ARP, Request who-has 69.243.169.194 tell 69.243.168.1,
length 46
16:57:07.794076 ARP, Request who-has 68.53.191.86 tell 68.53.188.1,
length 46
16:57:07.861456 ARP, Request who-has 69.243.175.138 tell 69.243.168.1,
length 46
16:57:07.912922 ARP, Request who-has 98.228.201.16 tell 98.228.200.1,
length 46
16:57:07.982013 ARP, Request who-has 73.45.175.28 tell 73.45.168.1,
length 46
16:57:08.033071 ARP, Request who-has 69.243.175.114 tell 69.243.168.1,
length 46
16:57:08.034293 ARP, Request who-has 69.243.173.171 tell 69.243.168.1,
length 46
16:57:08.142485 ARP, Request who-has 73.45.171.99 tell 73.45.168.1,
length 46
16:57:08.211986 ARP, Request who-has 69.243.175.116 tell 69.243.168.1,
length 46
16:57:08.317543 ARP, Request who-has 68.57.226.125 tell 68.57.224.1,
length 46
16:57:08.318758 ARP, Request who-has 68.57.225.126 tell 68.57.224.1,
length 46
16:57:08.366884 ARP, Request who-has 69.243.175.99 tell 69.243.168.1,
length 46
16:57:08.367070 ARP, Request who-has 73.45.183.117 tell 73.45.176.1,
length 46
16:57:08.371155 ARP, Request who-has 69.243.175.114 tell 69.243.168.1,
length 46
16:57:08.430391 ARP, Request who-has 69.243.168.198 tell 69.243.168.1,
length 46
16:57:08.550532 ARP, Request who-has 69.243.175.116 tell 69.243.168.1,
length 46
16:57:08.556949 ARP, Request who-has 73.45.175.106 tell 73.45.168.1,
length 46
16:57:08.583990 ARP, Request who-has 68.57.227.247 tell 68.57.224.1,
length 46
16:57:08.731170 ARP, Request who-has 68.53.190.183 tell 68.53.188.1,
length 46
16:57:08.732404 ARP, Request who-has 73.45.174.78 tell 73.45.168.1,
length 46
16:57:08.732813 ARP, Request who-has 69.243.175.138 tell 69.243.168.1,
length 46
16:57:08.765486 ARP, Request who-has 71.25.89.79 tell 71.25.88.1, length 46
16:57:09.345289 ARP, Request who-has 24.14.75.28 tell 24.14.74.1, length 46
16:57:09.353727 ARP, Request who-has 73.45.174.46 tell 73.45.168.1,
length 46
16:57:09.392379 ARP, Request who-has 69.243.175.114 tell 69.243.168.1,
length 46
16:57:09.440844 ARP, Request who-has 68.53.190.15 tell 68.53.188.1,
length 46
16:57:09.545543 ARP, Request who-has 69.243.172.74 tell 69.243.168.1,
length 46
16:57:09.721029 ARP, Request who-has 71.25.89.101 tell 71.25.88.1, length 46
16:57:09.743761 ARP, Request who-has 69.243.175.116 tell 69.243.168.1,
length 46
16:57:09.900810 ARP, Request who-has 69.243.170.207 tell 69.243.168.1,
length 46
16:57:09.955301 ARP, Request who-has 69.243.175.114 tell 69.243.168.1,
length 46
16:57:09.961294 ARP, Request who-has 68.53.191.204 tell 68.53.188.1,
length 46
16:57:09.991327 ARP, Request who-has 71.25.89.84 tell 71.25.88.1, length 46
16:57:10.209747 ARP, Request who-has 69.243.173.73 tell 69.243.168.1,
length 46
16:57:10.252649 ARP, Request who-has 68.57.226.158 tell 68.57.224.1,
length 46
16:57:10.270273 ARP, Request who-has 73.45.170.35 tell 73.45.168.1,
length 46
16:57:10.282667 ARP, Request who-has 68.58.105.115 tell 68.58.104.1,
length 46
16:57:10.329025 ARP, Request who-has 69.243.175.114 tell 69.243.168.1,
length 46
16:57:10.343615 ARP, Request who-has 73.45.175.119 tell 73.45.168.1,
length 46
16:57:10.382221 ARP, Request who-has 69.243.175.116 tell 69.243.168.1,
length 46
16:57:10.517386 ARP, Request who-has 68.53.190.119 tell 68.53.188.1,
length 46
16:57:10.542693 ARP, Request who-has 69.243.175.239 tell 69.243.168.1,
length 46
16:57:10.567569 ARP, Request who-has 73.45.172.23 tell 73.45.168.1,
length 46
16:57:10.579155 ARP, Request who-has 73.45.173.51 tell 73.45.168.1,
length 46
16:57:10.599762 ARP, Request who-has 68.57.226.27 tell 68.57.224.1,
length 46
^C
172 packets captured
172 packets received by filter
0 packets dropped by kernel
2:21 p.m.
On 10/02/2010 02:52 PM, JD wrote:
On 10/02/2010 11:43 AM, Jim wrote:
> ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22
OK, So port 22 is open.
Is this on the server where sshd is running or is this
on the client where you are invoking /usr/bin/ssh ??
If on the server, then take a look at the contents of
the server's
/var/log/secure
/var/log/iptables (if you have configured iptables to log there)
/var/log/messages
and search for any messages pertaining to ssh or port 22 ...etc
Forgot to add in /var/log/messages.
These two lines are the only entering, and they appear a number of
different times and dates
avahi-daemon[1319]: Service "Acer" (/services/ssh.service) successfully
established.
avahi-daemon[1334]: Loading service file /services/ssh.service.
1:28 p.m.
On 10/02/2010 02:09 PM, JD wrote:
On 10/02/2010 09:32 AM, Jim wrote:
> Wether I run NX (nomachine) or SSH I get the same error message, no
> matter what host I try to connect to.
>
> And on the host servers SSHd is running.
> And so is the Client box.
>
> Running NX
> Error message: ssh: connect to host 70.236.39.98 port 22: Connection
> timed out
>
> Running $ ssh jim(a)70.236.39.98
> ErrorMessage: ssh: connect to host 70.236.39.98 port 22: Connection
> timed out
>
Check your firewalls???
I did and port 22 is a Trusted Service
12:11 p.m.
Jim wrote:
On 10/02/2010 12:32 PM, Jim wrote:
> Wether I run NX (nomachine) or SSH I get the same error message, no
> matter what host I try to connect to.
>
> And on the host servers SSHd is running.
> And so is the Client box.
>
> Running NX
> Error message: ssh: connect to host 70.236.39.98 port 22: Connection
> timed out
>
> Running $ ssh jim(a)70.236.39.98
> ErrorMessage: ssh: connect to host 70.236.39.98 port 22: Connection
> timed out
>
I forgot to add;
These are all FC13 boxes, clients and hosts and the Firewall in each box
has SSH check as Trusted Service.
Try keeping a running
tcpdump -i eth0 -n -n
in a different terminal before invoking ssh.
You should be able to see if packets are exchanged between the machines.
If you see your packets but no packet from the other machine, one of the
firewalls is interfering. You can sniff on the other side too for more
information.
--
Roberto Ragusa mail at robertoragusa.it
11:45 a.m.
On 10/02/2010 12:32 PM, Jim wrote:
Wether I run NX (nomachine) or SSH I get the same error message,
no
matter what host I try to connect to.
And on the host servers SSHd is running.
And so is the Client box.
Running NX
Error message: ssh: connect to host 70.236.39.98 port 22: Connection
timed out
Running $ ssh jim(a)70.236.39.98
ErrorMessage: ssh: connect to host 70.236.39.98 port 22: Connection
timed out
I forgot to add;
These are all FC13 boxes, clients and hosts and the Firewall in each box
has SSH check as Trusted Service.
6:25 p.m.
On 10/03/2010 02:31 PM, JD wrote:
On 10/03/2010 08:15 AM, Jim wrote:
> From the Client to Server ssh george(a)61.243.171.16 and the Client timed
> out and nothing has shown up on Server debug.
>
> I can ssh to any of my laptops on my local lan but not across the internet.
>
> if I knew that when I went from FC12 to 13 I would have stayed with F12.
> oh Well FC14 comes out in another month, i hope I have better luck.
>
> Below is all i get on the debug below, it just sits there listening .
>
> # service sshd restart
> Stopping sshd: [FAILED]
> Starting sshd: debug1: sshd version OpenSSH_5.4p1
> debug1: read PEM private key done: type RSA
> debug1: private host key: #0 type 1 RSA
> debug1: read PEM private key done: type DSA
> debug1: private host key: #1 type 2 DSA
> debug1: rexec_argv[0]='/usr/sbin/sshd'
> debug1: rexec_argv[1]='-d'
> Set /proc/self/oom_adj from 0 to -17
> debug1: Bind to port 22 on 0.0.0.0.
> Server listening on 0.0.0.0 port 22.
> debug1: Bind to port 22 on ::.
> Server listening on :: port 22.
Jim, I do not think the problem in your client machine's F13.
So please do not assume F13 is the culprit.
The "block" is somewhere between your gateway and the remote server.
That's you should be investigating.
As a test, can someone on the remote server ssh to your
F13 client?
I tried that today from my sister's Fedora 12 computer to mine, Fedora
13, and I get the same error; ssh: connect to host 69.58.52.206 port
22: Connection timed out.
She is setting behind a Linksys router and i'am not.
What about changing the Port 22 to something else ?
4:42 p.m.
What is the 6749 in this command ?
# netstat -nltp | grep 22
tcp 0 0 0.0.0.0:22
0.0.0.0:* LISTEN 6749/sshd
tcp 0 0 0.0.0.0:8822
0.0.0.0:* LISTEN 1666/smfpd
tcp 0 0 :::22
:::* LISTEN 6749/sshd
10:15 a.m.
On 10/02/2010 08:38 PM, JD wrote:
On 10/02/2010 04:35 PM, Jim wrote:
> On 10/02/2010 07:05 PM, JD wrote:
>> On 10/02/2010 12:14 PM, Jim wrote:
>>> On 10/02/2010 02:52 PM, JD wrote:
>>>> On 10/02/2010 11:43 AM, Jim wrote:
>>>>> ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state
NEW tcp dpt:22
>>>> OK, So port 22 is open.
>>>> Is this on the server where sshd is running or is this
>>>> on the client where you are invoking /usr/bin/ssh ??
>>>>
>>>> If on the server, then take a look at the contents of
>>>> the server's
>>>> /var/log/secure
>>>> /var/log/iptables (if you have configured iptables to log there)
>>>> /var/log/messages
>>>>
>>>> and search for any messages pertaining to ssh or port 22 ...etc
>>>>
>>> /var/log/secure
>>>
>>> This is the only entries, and they repeated a number of different times.
>>>
>>> Sep 29 09:34:19 Acer sshd[1564]: Server listening on 0.0.0.0 port 22.
>>> Sep 29 09:34:19 Acer sshd[1564]: Server listening on :: port 22.
>>>
>>>
>>> /var/log/iptables
>>>
>>> There is no /var/log/iptables on server.
>>>
>>>
>>>
>>> /var/log/messages
>>>
>>> There is no entries in /var/log/messages for port 22.
>> If you have admin privs on the server, can you edit
>> /etc/init.d/sshd and modify the line
>>
>> $SSHD $OPTIONS&& success || failure
>> to
>> $SSHD $OPTIONS -d&& success || failure
>>
>> The -d will turn on debug.
>>
>> You will look for messages in the debug output where
>> an incoming connection request is getting dropped.
>>
>>
>>
> I guess the debug output will show up in /var/log/messages ?
No.
On the sshd server, you open a terminal.
Edit that script in the terminal, then
sudo service sshd restart
and all debug will come out on that terminal.
Do not hit control-c or do not interrupt the service.
Now go to the client machine and try to ssh into
the server where you just restarted the sshd service.
and observe what the debug output is saying.
Here is a sample debug output when I ssh into the server where
the -d flag is set:
debug1: Server will not fork when running in debugging mode.
debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8
debug1: inetd sockets after dupping: 3, 3
Connection from ::1 port 53426
debug1: Client protocol version 2.0; client software version OpenSSH_5.4
debug1: match: OpenSSH_5.4 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.4
debug1: permanently_set_uid: 74/74
debug1: list_hostkey_types: ssh-rsa,ssh-dss
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: KEX done
debug1: userauth-request for user jd service ssh-connection method none
debug1: attempt 0 failures 0
debug1: PAM: initializing for "jd"
debug1: PAM: setting PAM_RHOST to "localhost"
debug1: PAM: setting PAM_TTY to "ssh"
debug1: userauth-request for user jd service ssh-connection method password
debug1: attempt 1 failures 0
debug1: PAM: password authentication accepted for jd
debug1: do_pam_account: called
Accepted password for jd from ::1 port 53426 ssh2
debug1: monitor_child_preauth: jd has been authenticated by privileged
process
debug1: temporarily_use_uid: 1008/1008 (e=0/0)
debug1: ssh_gssapi_storecreds: Not a GSSAPI mechanism
debug1: restore_uid: 0/0
debug1: SELinux support disabled
debug1: PAM: establishing credentials
User child is on pid 12452
debug1: PAM: establishing credentials
debug1: permanently_set_uid: 1008/1008
debug1: Entering interactive session for SSH2.
debug1: server_init_dispatch_20
debug1: server_input_channel_open: ctype session rchan 0 win 1048576 max
16384
debug1: input_session_request
debug1: channel 0: new [server-session]
debug1: session_new: session 0
debug1: session_open: channel 0
debug1: session_open: session 0: link with channel 0
debug1: server_input_channel_open: confirm session
debug1: server_input_global_request: rtype no-more-sessions(a)openssh.com
want_reply 0
debug1: server_input_channel_req: channel 0 request pty-req reply 1
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req pty-req
debug1: Allocating pty.
debug1: session_new: session 0
debug1: session_pty_req: session 0 alloc /dev/pts/2
debug1: server_input_channel_req: channel 0 request env reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req env
debug1: server_input_channel_req: channel 0 request env reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req env
debug1: server_input_channel_req: channel 0 request shell reply 1
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req shell
debug1: Setting controlling tty using TIOCSCTTY.
From the Client to Server ssh george(a)61.243.171.16 and the Client timed
out and nothing has shown up on Server debug.
I can ssh to any of my laptops on my local lan but not across the internet.
if I knew that when I went from FC12 to 13 I would have stayed with F12.
oh Well FC14 comes out in another month, i hope I have better luck.
Below is all i get on the debug below, it just sits there listening .
# service sshd restart
Stopping sshd: [FAILED]
Starting sshd: debug1: sshd version OpenSSH_5.4p1
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-d'
Set /proc/self/oom_adj from 0 to -17
debug1: Bind to port 22 on 0.0.0.0.
Server listening on 0.0.0.0 port 22.
debug1: Bind to port 22 on ::.
Server listening on :: port 22.
7:38 p.m.
On 10/02/2010 04:35 PM, Jim wrote:
On 10/02/2010 07:05 PM, JD wrote:
> On 10/02/2010 12:14 PM, Jim wrote:
>> On 10/02/2010 02:52 PM, JD wrote:
>>> On 10/02/2010 11:43 AM, Jim wrote:
>>>> ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW
tcp dpt:22
>>> OK, So port 22 is open.
>>> Is this on the server where sshd is running or is this
>>> on the client where you are invoking /usr/bin/ssh ??
>>>
>>> If on the server, then take a look at the contents of
>>> the server's
>>> /var/log/secure
>>> /var/log/iptables (if you have configured iptables to log there)
>>> /var/log/messages
>>>
>>> and search for any messages pertaining to ssh or port 22 ...etc
>>>
>> /var/log/secure
>>
>> This is the only entries, and they repeated a number of different times.
>>
>> Sep 29 09:34:19 Acer sshd[1564]: Server listening on 0.0.0.0 port 22.
>> Sep 29 09:34:19 Acer sshd[1564]: Server listening on :: port 22.
>>
>>
>> /var/log/iptables
>>
>> There is no /var/log/iptables on server.
>>
>>
>>
>> /var/log/messages
>>
>> There is no entries in /var/log/messages for port 22.
> If you have admin privs on the server, can you edit
> /etc/init.d/sshd and modify the line
>
> $SSHD $OPTIONS&& success || failure
> to
> $SSHD $OPTIONS -d&& success || failure
>
> The -d will turn on debug.
>
> You will look for messages in the debug output where
> an incoming connection request is getting dropped.
>
>
>
I guess the debug output will show up in /var/log/messages ?
No.
On the sshd server, you open a terminal.
Edit that script in the terminal, then
sudo service sshd restart
and all debug will come out on that terminal.
Do not hit control-c or do not interrupt the service.
Now go to the client machine and try to ssh into
the server where you just restarted the sshd service.
and observe what the debug output is saying.
Here is a sample debug output when I ssh into the server where
the -d flag is set:
debug1: Server will not fork when running in debugging mode.
debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8
debug1: inetd sockets after dupping: 3, 3
Connection from ::1 port 53426
debug1: Client protocol version 2.0; client software version OpenSSH_5.4
debug1: match: OpenSSH_5.4 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.4
debug1: permanently_set_uid: 74/74
debug1: list_hostkey_types: ssh-rsa,ssh-dss
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: KEX done
debug1: userauth-request for user jd service ssh-connection method none
debug1: attempt 0 failures 0
debug1: PAM: initializing for "jd"
debug1: PAM: setting PAM_RHOST to "localhost"
debug1: PAM: setting PAM_TTY to "ssh"
debug1: userauth-request for user jd service ssh-connection method password
debug1: attempt 1 failures 0
debug1: PAM: password authentication accepted for jd
debug1: do_pam_account: called
Accepted password for jd from ::1 port 53426 ssh2
debug1: monitor_child_preauth: jd has been authenticated by privileged
process
debug1: temporarily_use_uid: 1008/1008 (e=0/0)
debug1: ssh_gssapi_storecreds: Not a GSSAPI mechanism
debug1: restore_uid: 0/0
debug1: SELinux support disabled
debug1: PAM: establishing credentials
User child is on pid 12452
debug1: PAM: establishing credentials
debug1: permanently_set_uid: 1008/1008
debug1: Entering interactive session for SSH2.
debug1: server_init_dispatch_20
debug1: server_input_channel_open: ctype session rchan 0 win 1048576 max
16384
debug1: input_session_request
debug1: channel 0: new [server-session]
debug1: session_new: session 0
debug1: session_open: channel 0
debug1: session_open: session 0: link with channel 0
debug1: server_input_channel_open: confirm session
debug1: server_input_global_request: rtype no-more-sessions(a)openssh.com
want_reply 0
debug1: server_input_channel_req: channel 0 request pty-req reply 1
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req pty-req
debug1: Allocating pty.
debug1: session_new: session 0
debug1: session_pty_req: session 0 alloc /dev/pts/2
debug1: server_input_channel_req: channel 0 request env reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req env
debug1: server_input_channel_req: channel 0 request env reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req env
debug1: server_input_channel_req: channel 0 request shell reply 1
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req shell
debug1: Setting controlling tty using TIOCSCTTY.
7:13 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 10/02/2010 11:32 AM, Jim wrote:
Wether I run NX (nomachine) or SSH I get the same error message, no
matter what host I try to connect to.
And on the host servers SSHd is running.
And so is the Client box.
Running NX
Error message: ssh: connect to host 70.236.39.98 port 22: Connection
timed out
Running $ ssh jim(a)70.236.39.98
ErrorMessage: ssh: connect to host 70.236.39.98 port 22: Connection
timed out
My concern about security makes me worry about asking too much about the
host, 70.236.39.98
Unfortunately, a little more information about the host, 70.236.39.98,
might help.
Is it a dedicated always on the Internet host, or a "dial-up" host?
I note, when I do,
host -a 70.236.39.98
I get
;; ANSWER SECTION:
98.39.236.70.in-addr.arpa. 6995 IN PTR
ppp-70-236-39-98.dsl.ipltin.ameritech.net.
- From the answer, is the host, 70.236.39.98, using PPP and is the host
always on the Internet, or only on the Internet when 70.236.39.98 has
outgoing traffic?
I also think I cannot get very close to the host when I do,
traceroute -n 70.236.39.98
I shouldn't be surprised that I cannot ping 70.236.39.98
A number of firewalls don't respond to ping.
Another, completely orthogonal possibility, is to ask about the ISP.
Perhaps the ISP, Ameritech, is restricting ports?
A number of ISPs restrict email ports (port 25).
I haven't heard of ISP restricting ssh ports (port 22), but need to ask.
Do you have access to iptables on 70.236.39.98?
There is a way to see the "count" of the number of packets each iptable
rule handles.
I think, as root, one does iptables -L -v -n
The "-v" verbose option causes counts to be shown.
Please see "man iptables"
If we believe the problem is iptables on 70.236.39.98, we should see a
count for the iptables rule that is blocking the traffic increase.
I would discourage one from showing their iptables rules willy-nilly.
Please sanitize security information shown in open forums.
People will argue, if the rules are correct, it doesn't matter if they
are shown. I will counter by asking when does anyone, and I include
myself in this list of people who are very imperfect, have the rules
"perfectly" correct.
I suspect the packet isn't even getting to 70.236.39.98...but don't know
where, or why, the packet is getting dropped.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkynyo4ACgkQyc8Kn0p/AZSiRACgk7ObVoG/t1SOQCu6ZK5ul46w
zjMAoI5SkD2AD27YCn5ymMmQPpimlLbJ
=8D2u
-----END PGP SIGNATURE-----
6:08 p.m.
New subject: Solved - SSH can't connect
On 10/04/2010 06:10 PM, Larry Brower wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jim wrote:
> On 10/04/2010 01:03 PM, JD wrote:
>> On 10/04/2010 08:54 AM, Jim wrote:
>>> And today his computer has Flat out "refused" any more SSH
>>> connections, It's a Fedora 13 box,
>> Then your friend's computer is either NOT running sshd or
>> his firewal simply refuses incoming connections.
>>
>>
> SSHD is running, i checked that yesterday and the firewall is checked
> for SSH.
What model is the AT&T box? can you login to it? A lot of AT&T
provided modem / routers have an internal firewall as well as perform
NAT. You may need to login to it and change the settings.
This is not a 2Wire router, it is setup for using one computer and no
Wireless.
It is at a different location and I will have to go there and check out
Make & Model .
And I cannot get through this modem to connect SSH to the computer.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJMqlDMAAoJEBgaXYoZ++87ql4IANSIVa852izdKoTHOeOwGU7c
DTN2+n6oy7rwGjDWbtmPtvNC5tbbuVhkNFO8jM33LDI+RQMEvakkwKfFc2nBk7yU
kFbZVpyzMJC441CG8BtJNNEx6XgajkPdbOVuHnrtKvTh6KnhZkanRM26TXx7z2cn
qjdtql7U85Lhu7NGoEHuX4KNHz1VVF3F3tIkk9BTE1RZ3W75qFCwT2I4lSU+J/GY
JOVVmJ+2vg/XY+RfRiULof2kntQapR7KU5U0flCkX4HR4zonzYR1tmq3iIlh20A7
FIs8SU7M24xMot8P5MOlLy3ZZnbhg5VO/+G8a3HR+mPMDmbrXg/l7Wv/LKVUHtk=
=I1Hc
-----END PGP SIGNATURE-----
5:10 p.m.
New subject: Solved - SSH can't connect
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jim wrote:
On 10/04/2010 01:03 PM, JD wrote:
> On 10/04/2010 08:54 AM, Jim wrote:
>> And today his computer has Flat out "refused" any more SSH
>> connections, It's a Fedora 13 box,
> Then your friend's computer is either NOT running sshd or
> his firewal simply refuses incoming connections.
>
>
SSHD is running, i checked that yesterday and the firewall is checked
for SSH.
What model is the AT&T box? can you login to it? A lot of AT&T
provided modem / routers have an internal firewall as well as perform
NAT. You may need to login to it and change the settings.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJMqlDMAAoJEBgaXYoZ++87ql4IANSIVa852izdKoTHOeOwGU7c
DTN2+n6oy7rwGjDWbtmPtvNC5tbbuVhkNFO8jM33LDI+RQMEvakkwKfFc2nBk7yU
kFbZVpyzMJC441CG8BtJNNEx6XgajkPdbOVuHnrtKvTh6KnhZkanRM26TXx7z2cn
qjdtql7U85Lhu7NGoEHuX4KNHz1VVF3F3tIkk9BTE1RZ3W75qFCwT2I4lSU+J/GY
JOVVmJ+2vg/XY+RfRiULof2kntQapR7KU5U0flCkX4HR4zonzYR1tmq3iIlh20A7
FIs8SU7M24xMot8P5MOlLy3ZZnbhg5VO/+G8a3HR+mPMDmbrXg/l7Wv/LKVUHtk=
=I1Hc
-----END PGP SIGNATURE-----
4:51 p.m.
New subject: Solved - SSH can't connect
On 10/04/2010 01:03 PM, JD wrote:
On 10/04/2010 08:54 AM, Jim wrote:
> And today his computer has Flat out "refused" any more SSH
> connections, It's a Fedora 13 box,
Then your friend's computer is either NOT running sshd or
his firewal simply refuses incoming connections.
SSHD is running, i checked that yesterday and the firewall is checked
for SSH.
4:48 p.m.
New subject: Solved - SSH can't connect
On 10/04/2010 04:38 PM, Aaron Konstam wrote:
On Mon, 2010-10-04 at 11:54 -0400, Jim wrote:
<snip>
>> JD
> Success Today , I had to go to my sisters house get into her Linksys
> WRT54G and setup Port Forwarding to her computer, no other Firewall
> settings was preventing from going through to her computer.
>
> I have a friends computer that I have been try to login for the past two
> days and he has no router in front of his box, just a AT&T ADSL modem.
> And his started out with "Timed Out" to a "Connection Refused"
today.
> Is there a possibility that all the trying to hack in for the past two
> days, And today his computer has Flat out "refused" any more SSH
> connections, It's a Fedora 13 box,
>
> Thanks for your help guys.
None of this explains why you cold not ssh between your computers.
Configuring you sister's computer does not explain your problem, at
least to me.
So your perplexed ? Well not as much as I'am.
I have never had this kind of problems with SSHD .
3:38 p.m.
New subject: Solved - SSH can't connect
On Mon, 2010-10-04 at 11:54 -0400, Jim wrote:
<snip>
> JD
Success Today , I had to go to my sisters house get into her Linksys
WRT54G and setup Port Forwarding to her computer, no other Firewall
settings was preventing from going through to her computer.
I have a friends computer that I have been try to login for the past two
days and he has no router in front of his box, just a AT&T ADSL modem.
And his started out with "Timed Out" to a "Connection Refused" today.
Is there a possibility that all the trying to hack in for the past two
days, And today his computer has Flat out "refused" any more SSH
connections, It's a Fedora 13 box,
Thanks for your help guys.
None of this explains why you cold not ssh between your
computers.
Configuring you sister's computer does not explain your problem, at
least to me.
--
=======================================================================
Persistence in one opinion has never been considered a merit in
political leaders. -- Marcus Tullius Cicero, "Ad familiares", 1st
century BC
=======================================================================
Aaron Konstam telephone: (210) 656-0355 e-mail: akonstam(a)sbcglobal.net
10:54 a.m.
New subject: Solved - SSH can't connect
On 10/03/2010 08:20 PM, JD wrote:
On 10/03/2010 04:25 PM, Jim wrote:
> On 10/03/2010 02:31 PM, JD wrote:
>> On 10/03/2010 08:15 AM, Jim wrote:
>>> From the Client to Server ssh george(a)61.243.171.16 and the Client
timed
>>> out and nothing has shown up on Server debug.
>>>
>>> I can ssh to any of my laptops on my local lan but not across the internet.
>>>
>>> if I knew that when I went from FC12 to 13 I would have stayed with F12.
>>> oh Well FC14 comes out in another month, i hope I have better luck.
>>>
>>> Below is all i get on the debug below, it just sits there listening .
>>>
>>> # service sshd restart
>>> Stopping sshd: [FAILED]
>>> Starting sshd: debug1: sshd version OpenSSH_5.4p1
>>> debug1: read PEM private key done: type RSA
>>> debug1: private host key: #0 type 1 RSA
>>> debug1: read PEM private key done: type DSA
>>> debug1: private host key: #1 type 2 DSA
>>> debug1: rexec_argv[0]='/usr/sbin/sshd'
>>> debug1: rexec_argv[1]='-d'
>>> Set /proc/self/oom_adj from 0 to -17
>>> debug1: Bind to port 22 on 0.0.0.0.
>>> Server listening on 0.0.0.0 port 22.
>>> debug1: Bind to port 22 on ::.
>>> Server listening on :: port 22.
>> Jim, I do not think the problem in your client machine's F13.
>> So please do not assume F13 is the culprit.
>> The "block" is somewhere between your gateway and the remote server.
>> That's you should be investigating.
>>
>> As a test, can someone on the remote server ssh to your
>> F13 client?
>>
>>
> I tried that today from my sister's Fedora 12 computer to mine, Fedora
> 13, and I get the same error; ssh: connect to host 69.58.52.206 port
> 22: Connection timed out.
>
> She is setting behind a Linksys router and i'am not.
>
> What about changing the Port 22 to something else ?
What about her linksys router? does IT allow port 22 traffic
in and out?
And your machine? Is IT on a router? If yes, have you check
the router to see if it has a firewall that does not allow port 22
traffic?
I am really suspecting only firewall issues, and not F13 issues.
Changing the port number on which your sshd daemon listens
could work if some firewall is blocking port 22 traffic.
You change the sshd port number by editing
In /etc/ssh/sshd_config you will see lines like:
# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented. Uncommented options change a
# default value.
#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::
Uncomment Port 22
and change it 22 to say ... 2222
and restart your sshd.
On your sister's machine, ssh to your machine like so:
ssh 69.58.52.206 -p 2222
and let us know if that worked.
If it does work, then your problem is indeed a firewall setting.
Good luck.
JD
Success Today , I had to go to my sisters house get into her Linksys
WRT54G and setup Port Forwarding to her computer, no other Firewall
settings was preventing from going through to her computer.
I have a friends computer that I have been try to login for the past two
days and he has no router in front of his box, just a AT&T ADSL modem.
And his started out with "Timed Out" to a "Connection Refused" today.
Is there a possibility that all the trying to hack in for the past two
days, And today his computer has Flat out "refused" any more SSH
connections, It's a Fedora 13 box,
Thanks for your help guys.
8:40 a.m.
On Sun, 2010-10-03 at 19:25 -0400, Jim wrote:
On 10/03/2010 02:31 PM, JD wrote:
>
> On 10/03/2010 08:15 AM, Jim wrote:
>> From the Client to Server ssh george(a)61.243.171.16 and the Client timed
>> out and nothing has shown up on Server debug.
>>
>> I can ssh to any of my laptops on my local lan but not across the internet.
>>
>> if I knew that when I went from FC12 to 13 I would have stayed with F12.
>> oh Well FC14 comes out in another month, i hope I have better luck.
>>
>> Below is all i get on the debug below, it just sits there listening .
>>
>> # service sshd restart
>> Stopping sshd: [FAILED]
>> Starting sshd: debug1: sshd version OpenSSH_5.4p1
>> debug1: read PEM private key done: type RSA
>> debug1: private host key: #0 type 1 RSA
>> debug1: read PEM private key done: type DSA
>> debug1: private host key: #1 type 2 DSA
>> debug1: rexec_argv[0]='/usr/sbin/sshd'
>> debug1: rexec_argv[1]='-d'
>> Set /proc/self/oom_adj from 0 to -17
>> debug1: Bind to port 22 on 0.0.0.0.
>> Server listening on 0.0.0.0 port 22.
>> debug1: Bind to port 22 on ::.
>> Server listening on :: port 22.
> Jim, I do not think the problem in your client machine's F13.
> So please do not assume F13 is the culprit.
> The "block" is somewhere between your gateway and the remote server.
> That's you should be investigating.
>
> As a test, can someone on the remote server ssh to your
> F13 client?
>
>
I tried that today from my sister's Fedora 12 computer to mine, Fedora
13, and I get the same error; ssh: connect to host 69.58.52.206 port
22: Connection timed out.
She is setting behind a Linksys router and i'am not.
What about changing the Port 22 to something else ?
Then it seems clear that your
machine is unreachable from the net. I
have not been keeping close attention to the discussion but some kind of
firewall either on your machine or your router seems to be a real
possibility.
--
=======================================================================
God requireth not a uniformity of religion. - Roger Williams
=======================================================================
Aaron Konstam telephone: (210) 656-0355 e-mail: akonstam(a)sbcglobal.net
7:20 p.m.
On 10/03/2010 04:25 PM, Jim wrote:
On 10/03/2010 02:31 PM, JD wrote:
> On 10/03/2010 08:15 AM, Jim wrote:
>> From the Client to Server ssh george(a)61.243.171.16 and the Client timed
>> out and nothing has shown up on Server debug.
>>
>> I can ssh to any of my laptops on my local lan but not across the internet.
>>
>> if I knew that when I went from FC12 to 13 I would have stayed with F12.
>> oh Well FC14 comes out in another month, i hope I have better luck.
>>
>> Below is all i get on the debug below, it just sits there listening .
>>
>> # service sshd restart
>> Stopping sshd: [FAILED]
>> Starting sshd: debug1: sshd version OpenSSH_5.4p1
>> debug1: read PEM private key done: type RSA
>> debug1: private host key: #0 type 1 RSA
>> debug1: read PEM private key done: type DSA
>> debug1: private host key: #1 type 2 DSA
>> debug1: rexec_argv[0]='/usr/sbin/sshd'
>> debug1: rexec_argv[1]='-d'
>> Set /proc/self/oom_adj from 0 to -17
>> debug1: Bind to port 22 on 0.0.0.0.
>> Server listening on 0.0.0.0 port 22.
>> debug1: Bind to port 22 on ::.
>> Server listening on :: port 22.
> Jim, I do not think the problem in your client machine's F13.
> So please do not assume F13 is the culprit.
> The "block" is somewhere between your gateway and the remote server.
> That's you should be investigating.
>
> As a test, can someone on the remote server ssh to your
> F13 client?
>
>
I tried that today from my sister's Fedora 12 computer to mine, Fedora
13, and I get the same error; ssh: connect to host 69.58.52.206 port
22: Connection timed out.
She is setting behind a Linksys router and i'am not.
What about changing the Port 22 to something else ?
What about her linksys router?
does IT allow port 22 traffic
in and out?
And your machine? Is IT on a router? If yes, have you check
the router to see if it has a firewall that does not allow port 22
traffic?
I am really suspecting only firewall issues, and not F13 issues.
Changing the port number on which your sshd daemon listens
could work if some firewall is blocking port 22 traffic.
You change the sshd port number by editing
In /etc/ssh/sshd_config you will see lines like:
# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented. Uncommented options change a
# default value.
#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::
Uncomment Port 22
and change it 22 to say ... 2222
and restart your sshd.
On your sister's machine, ssh to your machine like so:
ssh 69.58.52.206 -p 2222
and let us know if that worked.
If it does work, then your problem is indeed a firewall setting.
Good luck.
JD
2:01 p.m.
On 10/03/2010 11:49 AM, James McKenzie wrote:
Good idea. Also check the contents of hosts.allow/hosts.deny. One
further thing is to check if the IP address is being changed (NAT)
in-between the two systems. That can cause more troubles...
James McKenzie
If NAT, then the the sshd remote server needs to allow
the public IP address of the router, both in /etc/hosts.allow
AND in the firewall for port 22.
If this still fails, then the problem could be at the router/gateway
of the remote machine.
I have not seen any ISP's block port 22.
1:49 p.m.
On 10/3/10 11:43 AM, JD wrote:
On 10/03/2010 09:09 AM, Jim wrote:
> On 10/02/2010 08:28 PM, JD wrote:
>> On 10/02/2010 02:42 PM, Jim wrote:
>>> What is the 6749 in this command ?
>>>
>>>
>>> # netstat -nltp | grep 22
>>> tcp 0 0 0.0.0.0:22
>>> 0.0.0.0:* LISTEN 6749/sshd
>>> tcp 0 0 0.0.0.0:8822
>>> 0.0.0.0:* LISTEN 1666/smfpd
>>> tcp 0 0 :::22
>>> :::* LISTEN 6749/sshd
>> That's the process id.
>>
> I guess this would indicate I'am getting out onto the Internet.
> But is SSH ?
>
> # host -a 61.58.52.206
> Trying "206.52.58.6.61.in-addr.arpa"
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28179
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
>
> ;; QUESTION SECTION:
> ;206.52.58.68.in-addr.arpa. IN PTR
>
> ;; ANSWER SECTION:
> 206.52.58.68.in-addr.arpa. 7200 IN PTR
> c-61-58-52-206.hsd1.in.comcast.net.
>
> Received 91 bytes from 61.87.72.134#53 in 29 ms
>
Well, the process ID of the sshd does not mean you ARE
going over the internet, targeting a remote port 22.
The sshd is in listening mode, that's all.
Also, on your end, it matters not whether or not you
are running the sshd, since you are not trying to ssh
into your own machine. You want to ssh out to a remote
machine, and that's the machine that is running the sshd
that should respond to your connection request.
When you shared with us the firewall entries, was that
for your machine or the remote machine you are trying to connect to?
if that was for YOUR machine, then please run the command
iptables -L -n
on the remote machine and post the results.
Also, is your machine connected to a router/gateway?
If so, can you login to that router or gateway (usually
by aiming your browser to the router's LAN ip address.
Go thtough all it's menus that display/configure ports
and firewalls. See if that is where the block is.
Good idea. Also check the contents of hosts.allow/hosts.deny. One
further thing is to check if the IP address is being changed (NAT)
in-between the two systems. That can cause more troubles...
James McKenzie
1:43 p.m.
On 10/03/2010 09:09 AM, Jim wrote:
On 10/02/2010 08:28 PM, JD wrote:
> On 10/02/2010 02:42 PM, Jim wrote:
>> What is the 6749 in this command ?
>>
>>
>> # netstat -nltp | grep 22
>> tcp 0 0 0.0.0.0:22
>> 0.0.0.0:* LISTEN 6749/sshd
>> tcp 0 0 0.0.0.0:8822
>> 0.0.0.0:* LISTEN 1666/smfpd
>> tcp 0 0 :::22
>> :::* LISTEN 6749/sshd
> That's the process id.
>
I guess this would indicate I'am getting out onto the Internet.
But is SSH ?
# host -a 61.58.52.206
Trying "206.52.58.6.61.in-addr.arpa"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28179
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;206.52.58.68.in-addr.arpa. IN PTR
;; ANSWER SECTION:
206.52.58.68.in-addr.arpa. 7200 IN PTR
c-61-58-52-206.hsd1.in.comcast.net.
Received 91 bytes from 61.87.72.134#53 in 29 ms
Well, the process ID of the sshd does not mean you ARE
going over the internet, targeting a remote port 22.
The sshd is in listening mode, that's all.
Also, on your end, it matters not whether or not you
are running the sshd, since you are not trying to ssh
into your own machine. You want to ssh out to a remote
machine, and that's the machine that is running the sshd
that should respond to your connection request.
When you shared with us the firewall entries, was that
for your machine or the remote machine you are trying to connect to?
if that was for YOUR machine, then please run the command
iptables -L -n
on the remote machine and post the results.
Also, is your machine connected to a router/gateway?
If so, can you login to that router or gateway (usually
by aiming your browser to the router's LAN ip address.
Go thtough all it's menus that display/configure ports
and firewalls. See if that is where the block is.
1:31 p.m.
On 10/03/2010 08:15 AM, Jim wrote:
From the Client to Server ssh george(a)61.243.171.16 and the Client
timed
out and nothing has shown up on Server debug.
I can ssh to any of my laptops on my local lan but not across the internet.
if I knew that when I went from FC12 to 13 I would have stayed with F12.
oh Well FC14 comes out in another month, i hope I have better luck.
Below is all i get on the debug below, it just sits there listening .
# service sshd restart
Stopping sshd: [FAILED]
Starting sshd: debug1: sshd version OpenSSH_5.4p1
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-d'
Set /proc/self/oom_adj from 0 to -17
debug1: Bind to port 22 on 0.0.0.0.
Server listening on 0.0.0.0 port 22.
debug1: Bind to port 22 on ::.
Server listening on :: port 22.
Jim, I do not think the problem in your client
machine's F13.
So please do not assume F13 is the culprit.
The "block" is somewhere between your gateway and the remote server.
That's you should be investigating.
As a test, can someone on the remote server ssh to your
F13 client?
11:09 a.m.
On 10/02/2010 08:28 PM, JD wrote:
On 10/02/2010 02:42 PM, Jim wrote:
> What is the 6749 in this command ?
>
>
> # netstat -nltp | grep 22
> tcp 0 0 0.0.0.0:22
> 0.0.0.0:* LISTEN 6749/sshd
> tcp 0 0 0.0.0.0:8822
> 0.0.0.0:* LISTEN 1666/smfpd
> tcp 0 0 :::22
> :::* LISTEN 6749/sshd
That's the process id.
I guess this would indicate I'am getting out onto the Internet.
But is SSH ?
# host -a 61.58.52.206
Trying "206.52.58.6.61.in-addr.arpa"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28179
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;206.52.58.68.in-addr.arpa. IN PTR
;; ANSWER SECTION:
206.52.58.68.in-addr.arpa. 7200 IN PTR
c-61-58-52-206.hsd1.in.comcast.net.
Received 91 bytes from 61.87.72.134#53 in 29 ms
9:37 a.m.
On 10/03/2010 10:16 AM, Aaron Konstam wrote:
>
> sometimes you may have changed the default port for ssh service. Check
> whether the port is 22.
> Check /etc/ssh/ssh_config in servers
Or check that that address is reachable from your machine using host or
dig.
Is it possible that machine is his internet gateway/firewall ??
If so, this may (or not) be reachable via its internal private lan -
but when trying from the 'outside' has problems.
If the outside attempt is really - client->gateway->gateway - then the
firewall may need another rule .. this is distinct from when you're
coming in from a machine that is really outside (say trying from a
friends house or work or whatever).
9:16 a.m.
On Sat, 2010-10-02 at 22:10 +0530, Kalpa Welivitigoda wrote:
On Sat, Oct 2, 2010 at 10:02 PM, Jim <binarynut(a)comcast.net>
wrote:
> Wether I run NX (nomachine) or SSH I get the same error message, no
> matter what host I try to connect to.
>
> And on the host servers SSHd is running.
> And so is the Client box.
>
> Running NX
> Error message: ssh: connect to host 70.236.39.98 port 22: Connection
> timed out
>
> Running $ ssh jim(a)70.236.39.98
> ErrorMessage: ssh: connect to host 70.236.39.98 port 22: Connection
> timed out
>
sometimes you may have changed the default port for ssh service. Check
whether the port is 22.
Check /etc/ssh/ssh_config in servers
Or check that that address is reachable from
your machine using host or
dig.
--
=======================================================================
VMS must die!
=======================================================================
Aaron Konstam telephone: (210) 656-0355 e-mail: akonstam(a)sbcglobal.net
2:22 a.m.
Jim wrote:
On 10/02/2010 04:44 PM, Jim wrote:
> # ifconfig -a
> eth0 Link encap:Ethernet HWaddr 00:1D:72:A5:DD:B5
> inet addr:69.243.171.15 Bcast:69.243.175.255 Mask:255.255.248.0
> inet6 addr: fe80::21d:72ff:fea5:ddb5/64 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:509708 errors:0 dropped:0 overruns:0 frame:0
> TX packets:23265 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:59884381 (57.1 MiB) TX bytes:2849745 (2.7 MiB)
> Interrupt:28 Base address:0xc000
>
> 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:153 errors:0 dropped:0 overruns:0 frame:0
> TX packets:153 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:0
> RX bytes:9086 (8.8 KiB) TX bytes:9086 (8.8 KiB)
>
> # route -n
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric Ref Use
> Iface
> 69.243.168.0 0.0.0.0 255.255.248.0 U 1 0 0 eth0
> 0.0.0.0 69.243.168.1 0.0.0.0 UG 0 0 0 eth0
>
>
# tcpdump -i eth0 -n -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
16:56:59.415664 ARP, Request who-has 69.243.175.114 tell 69.243.168.1,
length 46
16:56:59.586430 ARP, Request who-has 69.243.175.116 tell 69.243.168.1,
length 46
16:56:59.696286 ARP, Request who-has 71.25.90.146 tell 71.25.88.1, length 46
16:56:59.697488 ARP, Request who-has 98.228.201.211 tell 98.228.200.1,
length 46
[...]
16:57:10.599762 ARP, Request who-has 68.57.226.27 tell 68.57.224.1,
length 46
^C
172 packets captured
172 packets received by filter
0 packets dropped by kernel
So, your routing appears to be good, but no sign of packets attempting
a connection comes up in the dump.
It could be you have a blocking firewall rule for outgoing packets.
Is the iptables output you pasted in another mail coming from the server
or client machine? We are checking the client's one.
What we have understood until now is that the client is not producing
packets to create a connection. We still do not know why.
Let's go on playing around the tcpdump.
- Does your (client) machine connect to the net? Does tcpdump see
packets to port 80 when you browser the web?
- Now, do you see packets when you try to ssh an IP which works
when browsed via web? I mean, go to www.google.com, observe its IP
address and then try to ssh to this address; google will refuse
the connection, but we have to see that packets are exchanged on
port 22.
- In the same spirit, let's try to connect via http to your 70.236.39.98
server, by writing http://70.236.39.98/ in your browser. Your server
will not respond, but packets must show up.
My idea is to understand if the problem is in the IP or on the port.
All tests are now on the client, because if there are no outgoing packets,
messing with the server is useless.
--
Roberto Ragusa mail at robertoragusa.it
6:35 p.m.
On 10/02/2010 07:05 PM, JD wrote:
On 10/02/2010 12:14 PM, Jim wrote:
> On 10/02/2010 02:52 PM, JD wrote:
>> On 10/02/2010 11:43 AM, Jim wrote:
>>> ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp
dpt:22
>> OK, So port 22 is open.
>> Is this on the server where sshd is running or is this
>> on the client where you are invoking /usr/bin/ssh ??
>>
>> If on the server, then take a look at the contents of
>> the server's
>> /var/log/secure
>> /var/log/iptables (if you have configured iptables to log there)
>> /var/log/messages
>>
>> and search for any messages pertaining to ssh or port 22 ...etc
>>
> /var/log/secure
>
> This is the only entries, and they repeated a number of different times.
>
> Sep 29 09:34:19 Acer sshd[1564]: Server listening on 0.0.0.0 port 22.
> Sep 29 09:34:19 Acer sshd[1564]: Server listening on :: port 22.
>
>
> /var/log/iptables
>
> There is no /var/log/iptables on server.
>
>
>
> /var/log/messages
>
> There is no entries in /var/log/messages for port 22.
If you have admin privs on the server, can you edit
/etc/init.d/sshd and modify the line
$SSHD $OPTIONS&& success || failure
to
$SSHD $OPTIONS -d&& success || failure
The -d will turn on debug.
You will look for messages in the debug output where
an incoming connection request is getting dropped.
I guess the debug output will show up in /var/log/messages ?
1:52 p.m.
On 10/02/2010 11:43 AM, Jim wrote:
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state
NEW tcp dpt:22
OK, So port 22 is open.
Is this on the server where sshd is running or is this
on the client where you are invoking /usr/bin/ssh ??
If on the server, then take a look at the contents of
the server's
/var/log/secure
/var/log/iptables (if you have configured iptables to log there)
/var/log/messages
and search for any messages pertaining to ssh or port 22 ...etc
6:07 p.m.
On 10/02/2010 12:21 PM, Jim wrote:
On 10/02/2010 02:52 PM, JD wrote:
> On 10/02/2010 11:43 AM, Jim wrote:
>> ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp
dpt:22
> OK, So port 22 is open.
> Is this on the server where sshd is running or is this
> on the client where you are invoking /usr/bin/ssh ??
>
> If on the server, then take a look at the contents of
> the server's
> /var/log/secure
> /var/log/iptables (if you have configured iptables to log there)
> /var/log/messages
>
> and search for any messages pertaining to ssh or port 22 ...etc
>
Forgot to add in /var/log/messages.
These two lines are the only entering, and they appear a number of
different times and dates
avahi-daemon[1319]: Service "Acer" (/services/ssh.service) successfully
established.
avahi-daemon[1334]: Loading service file /services/ssh.service.
Yeah.. that's
not of any consequence.
6:05 p.m.
On 10/02/2010 12:14 PM, Jim wrote:
On 10/02/2010 02:52 PM, JD wrote:
> On 10/02/2010 11:43 AM, Jim wrote:
>> ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp
dpt:22
> OK, So port 22 is open.
> Is this on the server where sshd is running or is this
> on the client where you are invoking /usr/bin/ssh ??
>
> If on the server, then take a look at the contents of
> the server's
> /var/log/secure
> /var/log/iptables (if you have configured iptables to log there)
> /var/log/messages
>
> and search for any messages pertaining to ssh or port 22 ...etc
>
/var/log/secure
This is the only entries, and they repeated a number of different times.
Sep 29 09:34:19 Acer sshd[1564]: Server listening on 0.0.0.0 port 22.
Sep 29 09:34:19 Acer sshd[1564]: Server listening on :: port 22.
/var/log/iptables
There is no /var/log/iptables on server.
/var/log/messages
There is no entries in /var/log/messages for port 22.
If you have admin privs on
the server, can you edit
/etc/init.d/sshd and modify the line
$SSHD $OPTIONS && success || failure
to
$SSHD $OPTIONS -d && success || failure
The -d will turn on debug.
You will look for messages in the debug output where
an incoming connection request is getting dropped.
5:19 p.m.
On Sat, 2010-10-02 at 17:42 -0400, Jim wrote:
What is the 6749 in this command ?
# netstat -nltp | grep 22
tcp 0 0 0.0.0.0:22
0.0.0.0:* LISTEN 6749/sshd
tcp 0 0 0.0.0.0:8822
0.0.0.0:* LISTEN 1666/smfpd
tcp 0 0 :::22
----
try running the command without the 'grep' portion and read the header
at the top of the column
Craig
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
3:44 p.m.
On 10/02/2010 04:02 PM, Roberto Ragusa wrote:
Jim wrote:
> On 10/02/2010 01:11 PM, Roberto Ragusa wrote:
>> Jim wrote:
>>> On 10/02/2010 12:32 PM, Jim wrote:
>>>> Wether I run NX (nomachine) or SSH I get the same error message, no
>>>> matter what host I try to connect to.
>>>>
>>>> And on the host servers SSHd is running.
>>>> And so is the Client box.
>>>>
>>>> Running NX
>>>> Error message: ssh: connect to host 70.236.39.98 port 22: Connection
>>>> timed out
>>>>
>>>> Running $ ssh jim(a)70.236.39.98
>>>> ErrorMessage: ssh: connect to host 70.236.39.98 port 22: Connection
>>>> timed out
>>>>
>>> I forgot to add;
>>>
>>> These are all FC13 boxes, clients and hosts and the Firewall in each box
>>> has SSH check as Trusted Service.
>> Try keeping a running
>> tcpdump -i eth0 -n -n
>> in a different terminal before invoking ssh.
>>
>> You should be able to see if packets are exchanged between the machines.
>> If you see your packets but no packet from the other machine, one of the
>> firewalls is interfering. You can sniff on the other side too for more
>> information.
>>
> Running your command I get a steady output of IP's I have never seen,
> example below
>
> 14:05:10.307914 ARP, Request who-has 69.243.174.143 tell 69.243.168.1,
> length 46
> 14:05:10.331512 ARP, Request who-has 69.243.175.116 tell 69.243.168.1,
> length 46
> 14:05:10.331695 ARP, Request who-has 71.25.91.72 tell 71.25.88.1, length 46
> 14:05:10.332746 ARP, Request who-has 69.243.175.114 tell 69.243.168.1,
> length 46
> 14:05:10.386862 ARP, Request who-has 69.243.170.149 tell 69.243.168.1,
> length 46
> 14:05:10.566254 ARP, Request who-has 69.243.174.15 tell 69.243.168.1,
> length 46
> 14:05:10.576918 ARP, Request who-has 73.45.175.36 tell 73.45.168.1,
> length 46
> 14:05:10.622413 ARP, Request who-has 69.243.174.176 tell 69.243.168.1,
> length 46
> 14:05:10.625877 ARP, Request who-has 73.44.155.236 tell 73.44.152.1,
> length 46
> 14:05:10.667900 ARP, Request who-has 69.243.175.116 tell 69.243.168.1,
> length 46
> 14:05:10.681633 ARP, Request who-has 69.243.175.114 tell 69.243.168.1,
> length 46
>
Quite strange output: ARP requests for 69.*, 71.* and 73.* networks
and nothing else. You only pasted 0.3 seconds of activity. Was there
something for 70.236.39.98 when you tried to ssh?
What kind of network connections do you have?
Is the 70.236.39.98 machine supposed to be contacted on eth0?
Would you give us some info about your network connection?
ifconfig -a
route -n
Thanks.
# ifconfig -a
eth0 Link encap:Ethernet HWaddr 00:1D:72:A5:DD:B5
inet addr:69.243.171.15 Bcast:69.243.175.255 Mask:255.255.248.0
inet6 addr: fe80::21d:72ff:fea5:ddb5/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:509708 errors:0 dropped:0 overruns:0 frame:0
TX packets:23265 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:59884381 (57.1 MiB) TX bytes:2849745 (2.7 MiB)
Interrupt:28 Base address:0xc000
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:153 errors:0 dropped:0 overruns:0 frame:0
TX packets:153 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:9086 (8.8 KiB) TX bytes:9086 (8.8 KiB)
# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
69.243.168.0 0.0.0.0 255.255.248.0 U 1 0 0 eth0
0.0.0.0 69.243.168.1 0.0.0.0 UG 0 0 0 eth0
3:02 p.m.
Jim wrote:
On 10/02/2010 01:11 PM, Roberto Ragusa wrote:
> Jim wrote:
>> On 10/02/2010 12:32 PM, Jim wrote:
>>> Wether I run NX (nomachine) or SSH I get the same error message, no
>>> matter what host I try to connect to.
>>>
>>> And on the host servers SSHd is running.
>>> And so is the Client box.
>>>
>>> Running NX
>>> Error message: ssh: connect to host 70.236.39.98 port 22: Connection
>>> timed out
>>>
>>> Running $ ssh jim(a)70.236.39.98
>>> ErrorMessage: ssh: connect to host 70.236.39.98 port 22: Connection
>>> timed out
>>>
>> I forgot to add;
>>
>> These are all FC13 boxes, clients and hosts and the Firewall in each box
>> has SSH check as Trusted Service.
> Try keeping a running
> tcpdump -i eth0 -n -n
> in a different terminal before invoking ssh.
>
> You should be able to see if packets are exchanged between the machines.
> If you see your packets but no packet from the other machine, one of the
> firewalls is interfering. You can sniff on the other side too for more
> information.
>
Running your command I get a steady output of IP's I have never seen,
example below
14:05:10.307914 ARP, Request who-has 69.243.174.143 tell 69.243.168.1,
length 46
14:05:10.331512 ARP, Request who-has 69.243.175.116 tell 69.243.168.1,
length 46
14:05:10.331695 ARP, Request who-has 71.25.91.72 tell 71.25.88.1, length 46
14:05:10.332746 ARP, Request who-has 69.243.175.114 tell 69.243.168.1,
length 46
14:05:10.386862 ARP, Request who-has 69.243.170.149 tell 69.243.168.1,
length 46
14:05:10.566254 ARP, Request who-has 69.243.174.15 tell 69.243.168.1,
length 46
14:05:10.576918 ARP, Request who-has 73.45.175.36 tell 73.45.168.1,
length 46
14:05:10.622413 ARP, Request who-has 69.243.174.176 tell 69.243.168.1,
length 46
14:05:10.625877 ARP, Request who-has 73.44.155.236 tell 73.44.152.1,
length 46
14:05:10.667900 ARP, Request who-has 69.243.175.116 tell 69.243.168.1,
length 46
14:05:10.681633 ARP, Request who-has 69.243.175.114 tell 69.243.168.1,
length 46
Quite strange output: ARP requests for 69.*, 71.* and 73.* networks
and nothing else. You only pasted 0.3 seconds of activity. Was there
something for 70.236.39.98 when you tried to ssh?
What kind of network connections do you have?
Is the 70.236.39.98 machine supposed to be contacted on eth0?
Would you give us some info about your network connection?
ifconfig -a
route -n
Thanks.
--
Roberto Ragusa mail at robertoragusa.it
2:14 p.m.
On 10/02/2010 02:52 PM, JD wrote:
On 10/02/2010 11:43 AM, Jim wrote:
> ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22
OK, So port 22 is open.
Is this on the server where sshd is running or is this
on the client where you are invoking /usr/bin/ssh ??
If on the server, then take a look at the contents of
the server's
/var/log/secure
/var/log/iptables (if you have configured iptables to log there)
/var/log/messages
and search for any messages pertaining to ssh or port 22 ...etc
/var/log/secure
This is the only entries, and they repeated a number of different times.
Sep 29 09:34:19 Acer sshd[1564]: Server listening on 0.0.0.0 port 22.
Sep 29 09:34:19 Acer sshd[1564]: Server listening on :: port 22.
/var/log/iptables
There is no /var/log/iptables on server.
/var/log/messages
There is no entries in /var/log/messages for port 22.
1:43 p.m.
On 10/02/2010 02:34 PM, JD wrote:
sudo iptables -L -n
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
[root@Acer mickey]# iptables -L -n
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state
RELATED,ESTABLISHED
ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp spt:427
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW
tcp dpt:22
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 state NEW
udp dpt:631
ACCEPT udp -- 0.0.0.0/0 224.0.0.251 state NEW
udp dpt:5353
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW
tcp dpt:631
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 state NEW
udp dpt:631
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 state NEW
udp dpt:161
REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with
icmp-host-prohibited
Chain FORWARD (policy ACCEPT)
target prot opt source destination
REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with
icmp-host-prohibited
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
1:37 p.m.
On 10/02/2010 12:40 PM, Kalpa Welivitigoda wrote:
On Sat, Oct 2, 2010 at 10:02 PM, Jim<binarynut(a)comcast.net>
wrote:
> Wether I run NX (nomachine) or SSH I get the same error message, no
> matter what host I try to connect to.
>
> And on the host servers SSHd is running.
> And so is the Client box.
>
> Running NX
> Error message: ssh: connect to host 70.236.39.98 port 22: Connection
> timed out
>
> Running $ ssh jim(a)70.236.39.98
> ErrorMessage: ssh: connect to host 70.236.39.98 port 22: Connection
> timed out
>
sometimes you may have changed the default port for ssh service. Check
whether the port is 22.
Check /etc/ssh/ssh_config in servers
> --
> users mailing list
> users(a)lists.fedoraproject.org
> To unsubscribe or change subscription options:
> https://admin.fedoraproject.org/mailman/listinfo/users
> Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
>
Here is my;
/etc/ssh/ssh_config
# $OpenBSD: ssh_config,v 1.26 2010/01/11 01:39:46 dtucker Exp $
# This is the ssh client system-wide configuration file. See
# ssh_config(5) for more information. This file provides defaults for
# users, and the values can be changed in per-user configuration files
# or on the command line.
# Configuration data is parsed as follows:
# 1. command line options
# 2. user-specific file
# 3. system-wide file
# Any configuration value is only changed the first time it is set.
# Thus, host-specific definitions should be at the beginning of the
# configuration file, and defaults at the end.
# Site-wide defaults for some commonly used options. For a comprehensive
# list of available options, their meanings and defaults, please see the
# ssh_config(5) man page.
# Host *
# ForwardAgent no
# ForwardX11 no
# RhostsRSAAuthentication no
# RSAAuthentication yes
# PasswordAuthentication yes
# HostbasedAuthentication no
# GSSAPIAuthentication no
# GSSAPIDelegateCredentials no
# GSSAPIKeyExchange no
# GSSAPITrustDNS no
# BatchMode no
# CheckHostIP yes
# AddressFamily any
# ConnectTimeout 0
# StrictHostKeyChecking ask
# IdentityFile ~/.ssh/identity
# IdentityFile ~/.ssh/id_rsa
# IdentityFile ~/.ssh/id_dsa
# Port 22
# Protocol 2,1
# Cipher 3des
# Ciphers
aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc
# MACs hmac-md5,hmac-sha1,umac-64(a)openssh.com,hmac-ripemd160
# EscapeChar ~
# Tunnel no
# TunnelDevice any:any
# PermitLocalCommand no
# VisualHostKey no
# ProxyCommand ssh -q -W %h:%p gateway.example.com
Host *
GSSAPIAuthentication yes
# If this option is set to yes then remote X11 clients will have full access
# to the original X11 display. As virtually no X11 client supports the
untrusted
# mode correctly we set this to yes.
ForwardX11Trusted yes
# Send locale-related environment variables
SendEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY
LC_MESSAGES
SendEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
SendEnv LC_IDENTIFICATION LC_ALL LANGUAGE
SendEnv XMODIFIERS
1:34 p.m.
On 10/02/2010 11:28 AM, Jim wrote:
On 10/02/2010 02:09 PM, JD wrote:
> On 10/02/2010 09:32 AM, Jim wrote:
>> Wether I run NX (nomachine) or SSH I get the same error message, no
>> matter what host I try to connect to.
>>
>> And on the host servers SSHd is running.
>> And so is the Client box.
>>
>> Running NX
>> Error message: ssh: connect to host 70.236.39.98 port 22: Connection
>> timed out
>>
>> Running $ ssh jim(a)70.236.39.98
>> ErrorMessage: ssh: connect to host 70.236.39.98 port 22: Connection
>> timed out
>>
> Check your firewalls???
I did and port 22 is a Trusted Service
Run
sudo iptables -L -n
and see if port 22 is open to accept connections
1:22 p.m.
Yep, this sounds like a firewall, I have FC13 and working with Putty from
Windows/7 locally and across the net.
Scott Ford
Senior Systems Engineer
[mobile] 609-346-0399
[direct] 678-266-3399 x304
identityforge.com http://identityforge.com
This message is for the designated recipient only and may contain
privileged, proprietary, or otherwise private information. If you have
received it in error, please notify the sender immediately or let us know at
idFinfo(a)identityforge.com , and then delete the original. Any other use of
his email by you is prohibited.
-----Original Message-----
From: users-bounces(a)lists.fedoraproject.org
[mailto:users-bounces@lists.fedoraproject.org] On Behalf Of JD
Sent: Saturday, October 02, 2010 2:09 PM
To: Community support for Fedora users
Subject: Re: SSH can't connect
On 10/02/2010 09:32 AM, Jim wrote:
Wether I run NX (nomachine) or SSH I get the same error message,
no
matter what host I try to connect to.
And on the host servers SSHd is running.
And so is the Client box.
Running NX
Error message: ssh: connect to host 70.236.39.98 port 22: Connection
timed out
Running $ ssh jim(a)70.236.39.98
ErrorMessage: ssh: connect to host 70.236.39.98 port 22: Connection
timed out
Check your firewalls???
--
users mailing list
users(a)lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
1:09 p.m.
On 10/02/2010 09:32 AM, Jim wrote:
Wether I run NX (nomachine) or SSH I get the same error message,
no
matter what host I try to connect to.
And on the host servers SSHd is running.
And so is the Client box.
Running NX
Error message: ssh: connect to host 70.236.39.98 port 22: Connection
timed out
Running $ ssh jim(a)70.236.39.98
ErrorMessage: ssh: connect to host 70.236.39.98 port 22: Connection
timed out
Check your firewalls???
1:09 p.m.
On 10/02/2010 01:11 PM, Roberto Ragusa wrote:
Jim wrote:
> On 10/02/2010 12:32 PM, Jim wrote:
>> Wether I run NX (nomachine) or SSH I get the same error message, no
>> matter what host I try to connect to.
>>
>> And on the host servers SSHd is running.
>> And so is the Client box.
>>
>> Running NX
>> Error message: ssh: connect to host 70.236.39.98 port 22: Connection
>> timed out
>>
>> Running $ ssh jim(a)70.236.39.98
>> ErrorMessage: ssh: connect to host 70.236.39.98 port 22: Connection
>> timed out
>>
> I forgot to add;
>
> These are all FC13 boxes, clients and hosts and the Firewall in each box
> has SSH check as Trusted Service.
Try keeping a running
tcpdump -i eth0 -n -n
in a different terminal before invoking ssh.
You should be able to see if packets are exchanged between the machines.
If you see your packets but no packet from the other machine, one of the
firewalls is interfering. You can sniff on the other side too for more
information.
Running your command I get a steady output of IP's I have never seen,
example below
14:05:10.307914 ARP, Request who-has 69.243.174.143 tell 69.243.168.1,
length 46
14:05:10.331512 ARP, Request who-has 69.243.175.116 tell 69.243.168.1,
length 46
14:05:10.331695 ARP, Request who-has 71.25.91.72 tell 71.25.88.1, length 46
14:05:10.332746 ARP, Request who-has 69.243.175.114 tell 69.243.168.1,
length 46
14:05:10.386862 ARP, Request who-has 69.243.170.149 tell 69.243.168.1,
length 46
14:05:10.566254 ARP, Request who-has 69.243.174.15 tell 69.243.168.1,
length 46
14:05:10.576918 ARP, Request who-has 73.45.175.36 tell 73.45.168.1,
length 46
14:05:10.622413 ARP, Request who-has 69.243.174.176 tell 69.243.168.1,
length 46
14:05:10.625877 ARP, Request who-has 73.44.155.236 tell 73.44.152.1,
length 46
14:05:10.667900 ARP, Request who-has 69.243.175.116 tell 69.243.168.1,
length 46
14:05:10.681633 ARP, Request who-has 69.243.175.114 tell 69.243.168.1,
length 46
And it keeps running.
12:53 p.m.
On 10/02/2010 01:11 PM, Roberto Ragusa wrote:
Jim wrote:
> On 10/02/2010 12:32 PM, Jim wrote:
>> Wether I run NX (nomachine) or SSH I get the same error message, no
>> matter what host I try to connect to.
>>
>> And on the host servers SSHd is running.
>> And so is the Client box.
>>
>> Running NX
>> Error message: ssh: connect to host 70.236.39.98 port 22: Connection
>> timed out
>>
>> Running $ ssh jim(a)70.236.39.98
>> ErrorMessage: ssh: connect to host 70.236.39.98 port 22: Connection
>> timed out
>>
> I forgot to add;
>
> These are all FC13 boxes, clients and hosts and the Firewall in each box
> has SSH check as Trusted Service.
Try keeping a running
tcpdump -i eth0 -n -n
in a different terminal before invoking ssh.
You should be able to see if packets are exchanged between the machines.
If you see your packets but no packet from the other machine, one of the
firewalls is interfering. You can sniff on the other side too for more
information.
What is the -n -n After eth0 mean ?
11:40 a.m.
On Sat, Oct 2, 2010 at 10:02 PM, Jim <binarynut(a)comcast.net> wrote:
Wether I run NX (nomachine) or SSH I get the same error message, no
matter what host I try to connect to.
And on the host servers SSHd is running.
And so is the Client box.
Running NX
Error message: ssh: connect to host 70.236.39.98 port 22: Connection
timed out
Running $ ssh jim(a)70.236.39.98
ErrorMessage: ssh: connect to host 70.236.39.98 port 22: Connection
timed out
sometimes you may have changed the default port for ssh service. Check
whether the port is 22.
Check /etc/ssh/ssh_config in servers
--
users mailing list
users(a)lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
--
Best Regards,
W.H.Kalpa Pathum
http://kalpapathum.blogspot.com
http://thiraya.wordpress.com
5014
days inactive
5016
days old
47 comments
12 participants
participants (12)
-
Aaron Konstam -
Craig White -
Genes MailLists -
James McKenzie -
JD -
Kalpa Welivitigoda -
Larry Brower -
Mickey -
Richard Sewill -
Roberto Ragusa -
Scott Ford -
stan