ssh: no route to host

Hey,

  My linux networking skills aren't the best but,

1) Are you sure you have the correct IP address of the machine, I know you can ping it, but are you sure that it is the correct one?

2) We could add an entry into your ip table, by doing this

route add -host XXX.XXX.XXX.XXX netmask 255.X.X.X gw YYY.YYY.YYY.YYY

where Xs are the host and the Ys are the destination.

the netmask is your subnet mask, if you are unsure, type ipconfig in.  It should be 255.0.0.0

Good luck.

I posted on another Linux site and a user helped me solve my problem by using the /usr/bin/system-config-securitylevel tool to configure my firewall. (Under gnome, run Desktop->System Settings->Security Level. On the Firewall Options tab, check the SSH box in the "Trusted Services" window.)

However, I have another related question. Here is my new iptables after enabling ssh service:

[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:

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:

[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.

First I am glad you got it to work. 

I am not a guru, by any means, of linux networking.  But I just wonder if it has anything to do with the way the applications are ordered on the network.  The Secure shell is a different animal than say, http, https, ftp etc.  SSH lies on the application layer and has much different protocol than the network layer (http, ftp)protocols.  Again, this could be all wrong, but this is just some of the stuff I have gathered from learning networking and linux.  Maybe someone else has a better idea.

The following line is why your HTTP and HTTPS traffic can come back to you:

7 0 0 ACCEPT all -- any any anywhere anywhere state RELATED,ESTABLISHED

You're accepting any related and established traffic, but the key to the statement is that you've already initiated the connection out. When you want a webpage, you send a request to the server and that rule let's the "response" back in.

The reason your SSH server failed is that you didn't initiate the connection from your SSH server. You started the connection from another client, which is a new connection. You probably noticed you could SSH OUT of that box, before you put the new rule in. Again, the reason is because you were allowing RELATED and ESTABLISHED traffic back in.