LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Software
User Name
Password
Linux - Software This forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.

Notices


Reply
  Search this Thread
Old 06-27-2005, 01:12 AM   #1
thanhvn
Member
 
Registered: Mar 2005
Location: CA
Distribution: RHEL3, FC4
Posts: 46

Rep: Reputation: 15
ssh: No route to host


I'm running FC4 (2.6.11-1.1369) on both the local host and the remote host, and both hosts are on the same network (192.168.0.xxx). The two hosts can ping each other but when I attempt to ssh from one host to the other I got the following error:

ssh: connect to host 192.168.0.2 port 22: No route to host

I checked the settings of my router and it is not set up to block any services nor to do any port forwarding. Here is my iptables:

[root@localhost ~]# iptables -L
Chain FORWARD (policy ACCEPT)
target prot opt source destination
RH-Firewall-1-INPUT all -- anywhere anywhere

Chain INPUT (policy ACCEPT)
target prot opt source destination
RH-Firewall-1-INPUT all -- anywhere anywhere

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Chain RH-Firewall-1-INPUT (2 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere
ACCEPT icmp -- anywhere anywhere icmp any
ACCEPT ipv6-crypt-- anywhere anywhere
ACCEPT ipv6-auth-- anywhere anywhere
ACCEPT udp -- anywhere 224.0.0.251 udp dpt:5353
ACCEPT udp -- anywhere anywhere udp dpt:ipp
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
[root@localhost ~]#

Is there a problem with my firewall that might have caused this problem? Thanks for any help.

P.S. I also checked that the sshd is running on the remote I'm attempting to ssh to:

[tnguy@localhost ~]$ /etc/rc.d/init.d/sshd status
sshd (pid 2462) is running...

Last edited by thanhvn; 06-27-2005 at 01:14 AM.
 
Old 06-27-2005, 04:38 AM   #2
sudhasmyle
Member
 
Registered: Nov 2004
Distribution: RedHat
Posts: 37

Rep: Reputation: 15
Hi,
Yes, this is the problem because of your FIREWALL. Set the NO FIREWALL in both the side and try. I hope this will help you.
redhat-config-securitylevel
 
Old 06-27-2005, 10:29 PM   #3
thanhvn
Member
 
Registered: Mar 2005
Location: CA
Distribution: RHEL3, FC4
Posts: 46

Original Poster
Rep: Reputation: 15
I don't want to turn off my firewall unless I absolutely have to. If you can point out which rule(s) in my iptables are causing the problem and how to modify those rules to allow ssh (without compromising the rest of the system security), I would appreciate that.
 
Old 06-28-2005, 02:13 AM   #4
tkedwards
Senior Member
 
Registered: Aug 2004
Location: Munich, Germany
Distribution: Opensuse 11.2
Posts: 1,549

Rep: Reputation: 52
The port you have to open is port 22. Use the redhat-config-firewall tool (or whatever its called) to open those ports on both sides.
 
Old 06-29-2005, 08:26 AM   #5
jcliburn
Member
 
Registered: Dec 2003
Location: Mississippi, USA
Distribution: Fedora
Posts: 435

Rep: Reputation: 33
Quote:
Originally posted by thanhvn
I don't want to turn off my firewall unless I absolutely have to. If you can point out which rule(s) in my iptables are causing the problem and how to modify those rules to allow ssh (without compromising the rest of the system security), I would appreciate that.
I had this same problem. Under gnome, run Desktop->System Settings->Security Level. On the Firewall Options tab, check the SSH box in the "Trusted Services" window. That should fix you up.
 
Old 06-30-2005, 01:23 AM   #6
thanhvn
Member
 
Registered: Mar 2005
Location: CA
Distribution: RHEL3, FC4
Posts: 46

Original Poster
Rep: Reputation: 15
Thanks, jcliburn, that does the trick. (BTW: the command is /usr/bin/system-config-securitylevel). However, I have another related question:

Here is my new iptables after enabling ssh service:

Code:
[root@localhost ~]# iptables -L -v --line-numbers
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 RH-Firewall-1-INPUT  all  --  any    any     anywhere             anywhere

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 RH-Firewall-1-INPUT  all  --  any    any     anywhere             anywhere

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Chain RH-Firewall-1-INPUT (2 references)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 ACCEPT     all  --  lo     any     anywhere             anywhere
2        0     0 ACCEPT     icmp --  any    any     anywhere             anywhere            icmp any
3        0     0 ACCEPT     ipv6-crypt--  any    any     anywhere             anywhere
4        0     0 ACCEPT     ipv6-auth--  any    any     anywhere             anywhere
5        0     0 ACCEPT     udp  --  any    any     anywhere             224.0.0.251         udp dpt:5353
6        0     0 ACCEPT     udp  --  any    any     anywhere             anywhere            udp dpt:ipp
7        0     0 ACCEPT     all  --  any    any     anywhere             anywhere            state RELATED,ESTABLISHED
8        0     0 ACCEPT     tcp  --  any    any     anywhere             anywhere            state NEW tcp dpt:ssh
9        0     0 REJECT     all  --  any    any     anywhere             anywhere            reject-with icmp-host-prohibited
The only difference between this new iptables and the old one is the addition of one new rule in the RH-Firewall-1-INPUT chain:

Code:
8        0     0 ACCEPT     tcp  --  any    any     anywhere             anywhere            state NEW tcp dpt:ssh
Now, I can understand why this new rule is needed because the rule#1 and rule#7 in the RH-Firewall-1-INPUT chain do not apply, only packets coming into the loopback interface and packets belonging to an existing connection are accepted, respectively.

However, what I don't understand is that I've been browsing and purchasing stuff on the Internet and there are no rules for accepting new incoming HTTP and HTTPS packets !?

As a demonstration, I use the system-config-securitylevel tool to enable HTTP and HTTPS services in the firewall and my new iptables is:

Code:
[root@localhost ~]# iptables -L -v --line-numbers
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 RH-Firewall-1-INPUT  all  --  any    any     anywhere             anywhere

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 RH-Firewall-1-INPUT  all  --  any    any     anywhere             anywhere

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Chain RH-Firewall-1-INPUT (2 references)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 ACCEPT     all  --  lo     any     anywhere             anywhere
2        0     0 ACCEPT     icmp --  any    any     anywhere             anywhere            icmp any
3        0     0 ACCEPT     ipv6-crypt--  any    any     anywhere             anywhere
4        0     0 ACCEPT     ipv6-auth--  any    any     anywhere             anywhere
5        0     0 ACCEPT     udp  --  any    any     anywhere             224.0.0.251         udp dpt:5353
6        0     0 ACCEPT     udp  --  any    any     anywhere             anywhere            udp dpt:ipp
7        0     0 ACCEPT     all  --  any    any     anywhere             anywhere            state RELATED,ESTABLISHED
8        0     0 ACCEPT     tcp  --  any    any     anywhere             anywhere            state NEW tcp dpt:https
9        0     0 ACCEPT     tcp  --  any    any     anywhere             anywhere            state NEW tcp dpt:http
10       0     0 ACCEPT     tcp  --  any    any     anywhere             anywhere            state NEW tcp dpt:ssh
11       0     0 REJECT     all  --  any    any     anywhere             anywhere            reject-with icmp-host-prohibited
As you can see, two new rules, rule#8 and rule#9 were added for HTTPS and HTTP service, respectively.

Now, why were I able to use the HTTP and HTTPS services without rules #8 and #9 while I couldn't use the SSH service without rule #10 ?

Thanks for any help in expanding my limited Linux networking knowledge.
 
Old 06-30-2005, 07:18 AM   #7
jcliburn
Member
 
Registered: Dec 2003
Location: Mississippi, USA
Distribution: Fedora
Posts: 435

Rep: Reputation: 33
Rule 7 covers your browsing http/https sessions; they're in a RELATED or ESTABLISHED state because you initiated them. They're not new connections. Unless you're running a web server, you don't need your new rules 8 and 9.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
No route to host Airwaves Linux - Networking 2 11-04-2005 07:15 AM
no route to host PenguinHead Linux - Networking 9 02-02-2005 02:03 PM
no route to host php *BSD 2 11-10-2004 02:05 PM
No route to host senzoga Linux - Networking 1 07-14-2004 06:03 PM
No Route To Host Que Linux - General 10 08-19-2002 08:22 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Software

All times are GMT -5. The time now is 01:43 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration