LinuxQuestions.org
Download your favorite Linux distribution at LQ ISO.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie
User Name
Password
Linux - Newbie This Linux forum is for members that are new to Linux.
Just starting out and have a question? If it is not in the man pages or the how-to's this is the place!

Notices


Reply
  Search this Thread
Old 08-12-2010, 11:48 AM   #1
jarrodhadfield
LQ Newbie
 
Registered: Aug 2010
Posts: 7

Rep: Reputation: 0
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
 
Old 08-12-2010, 11:58 AM   #2
nicedream
Member
 
Registered: Feb 2010
Distribution: Arch Linux
Posts: 68

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

Code:
iptables -t nat -F POSTROUTING
iptables -t nat -F PREROUTING
iptables -t nat -F OUTPUT
iptables -F
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.
 
Old 08-12-2010, 12:10 PM   #3
jarrodhadfield
LQ Newbie
 
Registered: Aug 2010
Posts: 7

Original Poster
Rep: Reputation: 0
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
 
Old 08-12-2010, 12:13 PM   #4
nicedream
Member
 
Registered: Feb 2010
Distribution: Arch Linux
Posts: 68

Rep: Reputation: 19
Quote:
Originally Posted by jarrodhadfield View Post
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.
 
Old 08-12-2010, 12:24 PM   #5
jarrodhadfield
LQ Newbie
 
Registered: Aug 2010
Posts: 7

Original Poster
Rep: Reputation: 0
What would be the best way of figuring that out (something to read?)?

Thanks,

Jarrod
 
Old 08-12-2010, 12:29 PM   #6
nicedream
Member
 
Registered: Feb 2010
Distribution: Arch Linux
Posts: 68

Rep: Reputation: 19
Quote:
Originally Posted by jarrodhadfield View Post
What would be the best way of figuring that out (something to read?)?

Thanks,

Jarrod
What does your current firewall setup look like now?
 
Old 08-12-2010, 12:33 PM   #7
jarrodhadfield
LQ Newbie
 
Registered: Aug 2010
Posts: 7

Original Poster
Rep: Reputation: 0
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)
 
Old 08-12-2010, 12:45 PM   #8
nicedream
Member
 
Registered: Feb 2010
Distribution: Arch Linux
Posts: 68

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

Code:
iptables -L
and

Code:
 iptables -t nat -L
 
Old 08-12-2010, 12:53 PM   #9
jarrodhadfield
LQ Newbie
 
Registered: Aug 2010
Posts: 7

Original Poster
Rep: Reputation: 0
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
 
Old 08-12-2010, 01:09 PM   #10
nicedream
Member
 
Registered: Feb 2010
Distribution: Arch Linux
Posts: 68

Rep: Reputation: 19
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).
 
Old 08-12-2010, 01:18 PM   #11
jarrodhadfield
LQ Newbie
 
Registered: Aug 2010
Posts: 7

Original Poster
Rep: Reputation: 0
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!
 
Old 08-12-2010, 01:21 PM   #12
nicedream
Member
 
Registered: Feb 2010
Distribution: Arch Linux
Posts: 68

Rep: Reputation: 19
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.
 
Old 08-12-2010, 03:09 PM   #13
r3sistance
Senior Member
 
Registered: Mar 2004
Location: UK
Distribution: CentOS 6/7
Posts: 1,375

Rep: Reputation: 216Reputation: 216Reputation: 216
Quote:
Originally Posted by jarrodhadfield View Post
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A OUTPUT -p tcp --sport 22 -j ACCEPT
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]

Quote:
Originally Posted by nicedream View Post
but generally I would think your input chain should have a default DENY policy, and then explicitly allow only certain things (like ssh).
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.

Last edited by r3sistance; 08-12-2010 at 03:26 PM.
 
Old 08-13-2010, 02:31 AM   #14
jarrodhadfield
LQ Newbie
 
Registered: Aug 2010
Posts: 7

Original Poster
Rep: Reputation: 0
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
 
Old 08-13-2010, 07:24 AM   #15
nicedream
Member
 
Registered: Feb 2010
Distribution: Arch Linux
Posts: 68

Rep: Reputation: 19
Quote:
Originally Posted by r3sistance View Post

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


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
SSH Connection Refused tuftystick Linux - Newbie 15 01-12-2009 08:44 PM
ssh connection refused kevinsn Linux - Networking 5 03-31-2008 03:48 PM
ssh connection refused - trying to set up ssh server at home openSauce Linux - Server 10 10-18-2007 04:38 PM
SSH Connection Refused meping Linux - Networking 9 04-15-2006 01:04 AM
ssh in fedora: connection refused zwanzig Linux - Networking 8 06-11-2004 04:26 AM


All times are GMT -5. The time now is 03:14 PM.

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
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration