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@70.236.39.98 ErrorMessage: ssh: connect to host 70.236.39.98 port 22: Connection timed out
On Sat, Oct 2, 2010 at 10:02 PM, Jim binarynut@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@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@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
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@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.
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@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.
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, nomatter 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@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 ?
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, nomatter 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@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.
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@70.236.39.98 ErrorMessage: ssh: connect to host 70.236.39.98 port 22: Connection timed out
Check your firewalls???
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@identityforge.com , and then delete the original. Any other use of his email by you is prohibited.
-----Original Message----- From: users-bounces@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@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@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
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, nomatter 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@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
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, nomatter 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@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
On 10/02/2010 12:40 PM, Kalpa Welivitigoda wrote:
On Sat, Oct 2, 2010 at 10:02 PM, Jimbinarynut@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@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@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@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
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
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
On Sat, 02 Oct 2010 13:53:32 -0400 Jim binarynut@comcast.net wrote:
What is the -n -n After eth0 mean ?
man tcpdump
-n Don’t convert host addresses to names. This can be used to avoid DNS lookups.
-nn Don’t convert protocol and port numbers etc. to names either.
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.
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.
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, nomatter 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@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.
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, nomatter 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@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
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, nomatter 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@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
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
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
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
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.
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.
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 ?
-----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 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@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.
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@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.
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.
On Sat, 2010-10-02 at 22:10 +0530, Kalpa Welivitigoda wrote:
On Sat, Oct 2, 2010 at 10:02 PM, Jim binarynut@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@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.
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).
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@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@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.
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
On 10/03/2010 08:15 AM, Jim wrote:
From the Client to Server ssh george@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?
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.
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
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.
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@61.243.171.16 and the Client timedout 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 ?
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@61.243.171.16 and the Client timedout 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
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@61.243.171.16 and the Client timedout 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.
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@61.243.171.16 and the Client timedout 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.
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.
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 .
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.
-----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.
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 SSHconnections, 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-----
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.
-
Aaron Konstam -
Craig White -
Genes MailLists -
James McKenzie -
JD -
Kalpa Welivitigoda -
Larry Brower -
Mickey -
Richard Sewill -
Roberto Ragusa -
Scott Ford -
stan