Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have just installed Fedora 11 on my desktop system and would like to have sshd work. These are the steps I have done:

  1. Enabled sshd as a trusted service using system-config-firewall
  2. Restarted sshd as a service using service restart sshd

An SSH connection to localhost is possible, but I still can't use an SSH connection from a remote machine. Is there anything I am missing?

share|improve this question
You can't ssh from a remote machine, and what? It doesn't respond (timeouts)? It refuses connection? It connects but refuses login? Please, help us to help you. – Juliano Jun 24 '09 at 2:41
"Connection Timed Out" is the error. – vivekian2 Jun 24 '09 at 5:13
As I asked for in my answer below, please post the contents of /var/log/messages and /var/log/secure during the time you (a) start the sshd service and (b) try to connect from a remote server. – wzzrd Jun 24 '09 at 15:18
up vote 5 down vote accepted

1 Disable firewall to host (only long enough to verify it isn't the firewall

2 Open a terminal, su into the root user, and type /etc/init.d/sshd start This will atleast give you whatever errors you may be seeing. Hopefully it'll acknowledge the start

3 Enable firewall Verify that the firewall isn't the problem by connecting from remote host

Any errors from this, if you post, we might all be able to help.

You may notice in step 2 that the computer is generating your keys, which may have not been done sooner. This would explain why it wasn't working earlier. If it didn't create the keys, that means that they were previously generated and you're O.K.

share|improve this answer
Do not use /etc/init.d/*, at least not on Fedora (and probably also not on most distros). You should use "service sshd start". The former is considered obsolete, there is no guarantee that service scripts will be in that path in future versions. – Juliano Jun 24 '09 at 2:39
Wow good to know. Thanks Juliano! – bobby Jun 24 '09 at 3:57
Yes, that was the error earlier, but I have already done a service sshd restart which generated the keys. Something I have noticed though is that when system-config-services is run, I am unable to enable sshd there. It stays red – vivekian2 Jun 24 '09 at 5:12
@Juliano The question is about F11, not future versions. The /sbin/service is a RedHat thing, it doesn't apply to 'most other distros'. Compatibility with having an /etc/init.d will be maintained for years and years since everyone is so used to having it, and symlinks cost nothing. All 'service' does is call up the init script anyway, so as long as they're there there's no harm in using them. – theotherreceive Sep 5 '09 at 12:03
But, service works in RedHat (and thus CentOS and Fedora), SUSE and Ubuntu and others, so there isn't any point in not using it either. – user17642 Oct 30 '09 at 5:21

I was making a stupid mistake.

The problem was that I was trying to access the wrong IP address. The IP address was changed by DHCP once the machine had rebooted, and I kept trying to access the old IP address.

This is the reason why the local SSH connection was working but not remotely. I should have run ifconfig earlier to check the IP address.

There should be only 2 steps to this:

  • Enable sshd as a trusted service using system-config-firewall
  • Start sshd as a service using service sshd start

The second step makes sure that the keys have been generated. SELinux does not need to be touched at all.

share|improve this answer

SELinux is not the problem here. Do not disable SELinux or set it in permissive mode. There is absolutely no reason to do so. My laptop has been running F11 since the beginning of April with SELinux in enforcing mode without any problems.

SELinux only becomes a problem when you have manually created keys and placed them in /etc/ssh, for example, but since that is not the problem, leave SELinux alone.

Fedora does not have very bizarre hosts.deny rules, like for example Arch does, nor does it block ssh in iptables by default.

Please post the output of /var/log/secure and /var/log/messages around the time you are trying to start sshd and I'll see if I can help you out.

share|improve this answer
Messages from /var/log/secure: Apr 25 11:06:40 dhcp-172-16-137-155 sshd[3321]: Server listening on port 22. Apr 25 11:06:40 dhcp-172-16-137-155 sshd[3321]: Server listening on :: port 22. There was nothing relevant in /var/log/messages. – vivekian2 Jun 24 '09 at 18:07
Your /var/log/secure output suggests the service is started correctly. Can you try to log in and then post the part of /var/log/secure that shows your login attempt? – wzzrd Jun 24 '09 at 18:46
You don't have to turn off SELinux or put it in permissive to see if it is the problem. Even with limited knowledge of SELinux you can spot obvious SELinux related issues. For example grep "avc.*denied.*ssh" /var/log/audit/audit.log. or tail it for a "live" audit. tail -f /var/log/audit.log | grep "avc.*denied.*sshd". or to catch more generic SELinux related problems tail -f /var/log/audit.log | grep "avc.*denied. From a sysadmin point of view I find using tail/grep easy. For a more robust tool try seaudit from the setools package. – rev Jul 10 '09 at 11:48
Also Fedora has seen a lot of SELinux attention, out of the box configurations tend to work well. As you deviate YMMV. However FC by default is a "targeted" policy which means it targets network facing services like ssh. However pretty much everything else is unconfined. see -Z options as in ps -Z ls -Z. Also sesearch is your friend. say you do ps -Z to get the context of a process, then ls -Z on a file of interest, does policy allow lets say reading? try sesearch --allow -s typeFromps -t typeFromls. If all else fails, drop to permissive if you feel it really is SELinux causing it – rev Jul 10 '09 at 12:16

Ennable SSHD using this command systemctl enable sshd.service

su -
systemctl enable sshd.service
systemctl start sshd.service
share|improve this answer

You most likely have selinux running; recent Fedora installations enable this by default, with a pretty restrictive set of policies.

share|improve this answer
Except that the default targetted policy that Fedora ships does not lock down sshd from performing its core functionality like accepting valid ssh connections. – Ophidian Jun 24 '09 at 3:54
Still worth turning selinux of just to make sure its not a problem. – Jason Tan Jun 24 '09 at 14:47
That's what Permissive mode is for – Ophidian Jun 24 '09 at 15:57
I stand corrected, thanks for the info - I always assume that problems like this are caused by selinux, but didn't take enough time to check into the details. – gareth_bowles Jun 24 '09 at 19:24

You might also want to check your hosts.deny and hosts.allow files in /etc. In some distributions, these are set by default to block all connections from external sources but allow any connections from the local machine. This may be why you are able to connect locally but not from a remote system.

If hosts.deny has the "ALL: *" or maybe "ALL: PARANOID" line present and uncommented then this will be rejecting all connections from outside sources not explicitly allowed in the hosts.allow file. This is the default state in some distributions as it helps lock down the system from outside tampering right from start. If the file has nothing but comments this isn't the problem.

Assuming the "ALL: PARANOID" line is present in hosts.deny and you leave it alone, to enable ssh connections from a specific source you would need to add a "sshd: " line to your hosts.allow file. can be a specific IP, FQDN or a wildcarded version (i.e. sshd: 192.168.0.* or * This file typically has an "ALL:" line in it allowing any type of connection from the local machine which is why ssh may be working from the local machine but not from an external machine.

share|improve this answer

Some debugging approaches:

Have you verified that sshd is actually running. e.g. ps aux|grep sshd and netstat -nltp|grep 22 (as root)

Assuming sshd is running we want to see the network traffic and what is happening in the server's sshd process and the client ssh process:

  1. Can you ssh to the host from loclhost?

  2. Turn up the ssh logging in /etc/ssh/sshd_config and check the logs.

  3. tcpdump -i any tcp dst port 22 and src host <ssh_client_ip/host> on server host

  4. tcpdump -i any tcp dst port 22 and dst host <ssh_server_ip/host> on client host

  5. Attach strace -F -p <listening sshd process pid> to the listening instance of sshd on the server and see what is happening.

  6. ssh into the server, running the client from strace, i.e. strace ssh <user>@<host> and see what is happening

Also stop the sshd service on the server and run the sshd daemon from the command line in debug mode. e.g.:

service sshd stop;pkill sshd

sshd -d3


service sshd stop;pkill sshd

strace sshd -d3.

The -d3 runs sshd with a high debug level and stops it detaching/forking. I.e. it will be the only instance running and the output should go to your terminal

You might also want to use the -oLogLevel=DEBUG on the client command line to make it noisier.

If you are using keys for auth check the dir that your keys are in e,g, ~/.ssh hace sufficiently private perms. e.g chown -R ${USERID}. .sshd; chmod -R 700 .sshd.

share|improve this answer

To make sure it was configured and running:

chkconfig --list sshd
service sshd status

Once I knew it was running, I checked to make sure that it would come up at boot time. Next, to get it working, I added the following rule to /etc/sysconfig/iptables:

-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT

Then I restarted iptables, using:

service iptables restart

I had also disabled SELINUX by editing /etc/selinux/config and setting:


I may have rebooted to be sure. Those are the steps taken to get remote SSH logins.

NOTE: I have configured sshd.conf to NOT allow root logins. Double check your current sshd.conf file for that setting if you trying to login as root user. It's not really advisable to permit root to login remotely for security reasons.

share|improve this answer
I'm not an expert on SELINUX, but it looks like you can set that variable to "permissive" and that will permit and log instead of simply preventing various secured aspects of the OS. – netlinxman Jun 24 '09 at 3:07
If you want to turn off selinux without rebooting, e.g for testing like this you can use the setenforce command. setenforce 0 to turn it off and setenforce 1 to turn it on. getenforce will report selinux's status, i.e. enabled, disabled , or permissive. – Jason Tan Jun 24 '09 at 14:49

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.