How to enable sshd on Fedora 11?

Question

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?

Solution 1

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.

Solution 2

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.

Solution 3

Ennable SSHD using this command systemctl enable sshd.service

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

Solution 4

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.

View more solutions

Comments

[Admin]

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.

[Admin]

"Connection Timed Out" is the error.

[Admin]

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.

[Zaid Amir]

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.

[netlinxman]

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.

[Ophidian]

Except that the default targetted policy that Fedora ships does not lock down sshd from performing its core functionality like accepting valid ssh connections.

[vivekian2]

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

[Secoe]

Still worth turning selinux of just to make sure its not a problem.

[Secoe]

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.

[Ophidian]

That's what Permissive mode is for

[vivekian2]

Messages from /var/log/secure: Apr 25 11:06:40 dhcp-172-16-137-155 sshd[3321]: Server listening on 0.0.0.0 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.

[Govindarajulu]

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?

[gareth_bowles]

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.

[rev]

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]

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

[AWesley]

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

[Admin]

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.