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?

  • 2
    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
    Commented Jun 24, 2009 at 2:41
  • "Connection Timed Out" is the error.
    – vivekian2
    Commented Jun 24, 2009 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
    Commented Jun 24, 2009 at 15:18

8 Answers 8


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.

  • 5
    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
    Commented Jun 24, 2009 at 2:39
  • 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
    Commented Jun 24, 2009 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. Commented Sep 5, 2009 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
    Commented Oct 30, 2009 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.


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.

  • 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
    Commented Jun 24, 2009 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
    Commented Jun 24, 2009 at 18:46
  • 1
    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
    Commented Jul 10, 2009 at 11:48
  • 1
    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
    Commented Jul 10, 2009 at 12:16

Ennable SSHD using this command systemctl enable sshd.service

su -
systemctl enable sshd.service
systemctl start sshd.service

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

  • 4
    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
    Commented Jun 24, 2009 at 3:54
  • Still worth turning selinux of just to make sure its not a problem.
    – Jason Tan
    Commented Jun 24, 2009 at 14:47
  • That's what Permissive mode is for
    – Ophidian
    Commented Jun 24, 2009 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. Commented Jun 24, 2009 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 *.mydomain.net). 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.


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.


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.

  • 2
    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
    Commented Jun 24, 2009 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
    Commented Jun 24, 2009 at 14:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .