Hide Forgot
Description of problem: I cannot ssh into a VM with a brand new f17-branched installation. Version-Release number of selected component (if applicable): firewalld-0.2.4-1.fc17 openssh-5.9p1-22.fc17 How reproducible: always Steps to Reproduce: 1. Install f17-branched 2. ssh to host fails 3. suspecting firewall problems, # firewall-cmd --add --service-ssh 4. Error: ALREADY_ENABLED 5. systemctl --all indicates firewalld.service & iptables.service active Actual results: no connection Expected results: connection Additional info: ssh localhost works. tcpdump indicates the port-22 packets are arriving. # firewall-cmd --set-default-zone=home fails with Permission denied.
Note that permission denied message is a selinux problem.
With selinux disabled, and # firewall-cmd --set-default-zone=home done, and with firewalld restarted, incoming ssh finally is permitted. The "ALREADY_ENABLED" message rather mislead about the source of the problem, which was apparently that "public" is the default zone.
(In reply to comment #0) > 5. systemctl --all indicates firewalld.service & iptables.service active that shouldn't be possible because firewalld.service contains 'Conflicts=iptables.service'. What does the following command show ? systemctl list-unit-files | egrep 'iptables|firewalld' (In reply to comment #1) > Note that permission denied message is a selinux problem. I filled bug #812040. Please check that it's the same SELinux warning that you see. (In reply to comment #2) > With selinux disabled, and > # firewall-cmd --set-default-zone=home > done, and with firewalld restarted, incoming ssh finally is permitted. > > The "ALREADY_ENABLED" message rather mislead about the source of the > problem, which was apparently that "public" is the default zone. It returns ALREADY_ENABLED, because ssh is already allowed in the default ("public") zone. So changing default zone from "public" to "home" actually shouldn't "fix" the problem as I understand it, because ssh is allowed in both. Does the problem occur again if you change it back to "public" ?
Problem with sshd is even when iptables are disabled. Until I start them I'm not able to connect to the guest. And when iptables are enabled, I need to restart them to get sshd working.
(In reply to comment #4) > Problem with sshd is even when iptables are disabled. Until I start them I'm > not able to connect to the guest. Could you show me output of the following commands in this state (before you start iptables) ? systemctl --all | egrep 'iptables|firewalld' firewall-cmd --list=all iptables -L > And when iptables are enabled, I need to > restart them to get sshd working. That's probably because it conflicts with firewalld. Did you disable firewalld ?
I think this is duplicate of bug #821938. Do you use NetworkManager or network service (initscripts).
*** This bug has been marked as a duplicate of bug 821938 ***