SSH connection refused on Fedora 13
 

Hi,

I've installed Fedora 13 and can no longer ssh the machine from my Mac: I get

ssh: connect to host 129.215.***.** port 22: Connection refused

I've edited iptables:

iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A OUTPUT -p tcp --sport 22 -j ACCEPT

/etc/ssh/sshd_config looks OK, and I can ssh the account from the computer itself.

I temporarily turned SElinux off - but to no avail.

Any help would be appreciated.

Cheers,

Jarrod

Try removing all firewall rules to see if that is the problem:

If you are able to connect after doing this, then you know there is an error somewhere in the firewall setup. If you still can't connect, then you will know that the problem lies elsewhere.

Hi,

That made my last 4 hours seem pretty pointless. Indeed - it now works! I'm not sure what these modifications to iptables has done, but is it safe to leave them like this?

Thanks,

Jarrod

No, you probably don't want to let your server exposed without any firewall rules at all. But now you know that you have some firewall rule that was preventing your ssh connection. You just have to figure out what it is.

What would be the best way of figuring that out (something to read?)?

Thanks,

Jarrod

What does your current firewall setup look like now?

From the drop down menu SSH is ticked as a trusted service and everything else is not ticked, including everything in Trusted Interfaces (where I presume the problem lies)

With the firewall enabled the way you had it before (when ssh doesn't work), post the output of the following commands:

and

Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT icmp -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT udp -- anywhere anywhere state NEW udp dpt:ipp
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ipp
ACCEPT udp -- anywhere anywhere state NEW udp dpt:ipp
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
ACCEPT tcp -- anywhere anywhere tcp dpt:ssh

Chain FORWARD (policy ACCEPT)
target prot opt source destination
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ACCEPT tcp -- anywhere anywhere tcp dpt:ssh


and

target prot opt source destination
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT icmp -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT udp -- anywhere anywhere state NEW udp dpt:ipp
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ipp
ACCEPT udp -- anywhere anywhere state NEW udp dpt:ipp
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
ACCEPT tcp -- anywhere anywhere tcp dpt:ssh

Chain FORWARD (policy ACCEPT)
target prot opt source destination
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ACCEPT tcp -- anywhere anywhere tcp dpt:ssh
[root@sce-bio-c01600 jarrod]# iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target prot opt source destination

Chain POSTROUTING (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

With the config you posted, can you verify that SSH does *not* work?

iptables will process rules from top to bottom, and then stop when it hits a rule that matches the packet. Therefore, it seems like everything should pass through based on your third rule "ACCEPT all -- anywhere anywhere". I don't think that the REJECT statement several lines down would ever be reached.

Also: Did this firewall configuration come only from the GUI tool, or have you added other things to it yourself? I don't run Fedora, and I don't know how their GUI tool creates firewall rules, but generally I would think your input chain should have a default DENY policy, and then explicitly allow only certain things (like ssh).

Sorry - ssh does now work, although I thought I had reset everything to as it was when it was failing. Now I can't get it to fail!

Whatever you did to your firewall so far, you need to start over from scratch. Right now your firewall is letting everything in based on the 3rd rule in the Input chain.

Should have been

iptables -I INPUT -p tcp --dport 22 -j ACCEPT
iptables -I OUTPUT -p tcp --sport 22 -j ACCEPT

-A appends, -I inserts. Append adds to the end, Insert by default inserts at the start... if you look at your rules you will see the following in the input chain

REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
ACCEPT tcp -- anywhere anywhere tcp dpt:ssh

Note that the rules go in order thus before the SSH rules are hit, all traffic has already been rejected. If this now works could you please mark this thread as [solved]

This is also a very good way to blackhole yourself out of a system, not so important with a desktop but if you hit an issue with a remote server that requires iptables being flushed... well that's gunna cause some rough downtime, more so if you have to travel to wherever the server is... maybe not so bad if it's at a datacenter and you can get KVMoIP access... you can make the argument that a server should be well set-up in the first place, however services rarely stay the same, when more things are offered these things tend to occur.

Hi,

Thanks for the responses - iptables now makes more (some) sense. The problem is solved in that I can ssh the computer, but given the earlier reply I'm afraid I've compromised the security by fixing it.

Cheers,

Jarrod

Yes - if you aren't careful you can lock yourself out of a system, but locking people out of the system is the whole purpose of a firewall. When you are testing your firewall rules for the first time, you should either be physically at the system, or have a way to easily remotely reboot the system to reset the rules.

I'll stand by my statement that a default DENY is the best (most secure) policy. It's much easier and safer to open up the ports that you need, rather than trying to close all the ones that you don't.