So, I have a strange problem which I can't figure out. After Friday's updates, I was unable to ssh into the machine with a nonstandard port. I changed the port to the default and was able to get in. I was able to resolve this only after stopping and starting iptables service.
Is this the norm? How is this fixed? I have never had to do this before.
OK, I believe this is a bug (or a feature I can not fathom)....
I reboot the machine, and lose access to the ssh port. Restarting iptables fixes the problem. This is problematic because the machine can not be rebooted remotely to obtain access remotely.
Is this a bug, or a new feature? What should this be filed against?
This only started after last Friday's updates.
Many thanks!
-----Original Message----- From: maitra.mbox.ignored@inbox.com Sent: Mon, 28 Jan 2013 15:01:58 -0600 To: users@lists.fedoraproject.org Subject: F18: post-friday updates + ssh ports + iptables
So, I have a strange problem which I can't figure out. After Friday's updates, I was unable to ssh into the machine with a nonstandard port. I changed the port to the default and was able to get in. I was able to resolve this only after stopping and starting iptables service.
Is this the norm? How is this fixed? I have never had to do this before.
-- Important Notice: This mailbox is ignored: e-mails are set to be deleted on receipt. For those needing to send personal or professional e-mail, please use appropriate addresses.
GET FREE SMILEYS FOR YOUR IM & EMAIL - Learn more at http://www.inbox.com/smileys Works with AIM®, MSN® Messenger, Yahoo!® Messenger, ICQ®, Google Talk™ and most webmails
-- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
____________________________________________________________ FREE 3D MARINE AQUARIUM SCREENSAVER - Watch dolphins, sharks & orcas on your desktop! Check it out at http://www.inbox.com/marineaquarium
On Mon, Jan 28, 2013 at 03:47:50PM -0800, Ranjan Maitra wrote:
OK, I believe this is a bug (or a feature I can not fathom)....
I reboot the machine, and lose access to the ssh port. Restarting iptables fixes the problem. This is problematic because the machine can not be rebooted remotely to obtain access remotely.
Is this a bug, or a new feature? What should this be filed against?
This only started after last Friday's updates.
What were in those updates? If isolating it and rollingback resolves your problem then you have your answer and can file a bug report.
GL,
PS: From what I see in my updated packages on Friday, there is nothing that even remotely relates to ssh or iptables.
dracut-024-18.git20130102.fc18.x86_64 googlecl-0.9.13-3.fc18.noarch mdadm-3.2.6-7.fc18.x86_64 parted-3.1-9.fc18.x86_64 rubygem-multi_xml-0.4.1-4.fc18.noarch xorg-x11-drv-nouveau-1:1.0.3-1.fc18.x86_64
-- Suvayu
Open source is the future. It sets us free.
On Tue, 29 Jan 2013 03:01:30 +0100 Suvayu Ali <fatkasuvayu +linux@gmail.com> wrote:
On Mon, Jan 28, 2013 at 03:47:50PM -0800, Ranjan Maitra wrote:
OK, I believe this is a bug (or a feature I can not fathom)....
I reboot the machine, and lose access to the ssh port. Restarting iptables fixes the problem. This is problematic because the machine can not be rebooted remotely to obtain access remotely.
Is this a bug, or a new feature? What should this be filed against?
This only started after last Friday's updates.
What were in those updates? If isolating it and rollingback resolves your problem then you have your answer and can file a bug report.
GL,
PS: From what I see in my updated packages on Friday, there is nothing that even remotely relates to ssh or iptables.
dracut-024-18.git20130102.fc18.x86_64 googlecl-0.9.13-3.fc18.noarch mdadm-3.2.6-7.fc18.x86_64 parted-3.1-9.fc18.x86_64 rubygem-multi_xml-0.4.1-4.fc18.noarch xorg-x11-drv-nouveau-1:1.0.3-1.fc18.x86_64
I am not sure how to figure out what were in those updates. Is there a way? I am not even sure that this is an iptables issue, only that restarting it appears to be resolving the problem (namely that ssh is set to access through the standard port, which is disabled in favor of the non-standard port in the ssd_config).
I do see that the iptables package has not been updated at all since F18 was released. Neither has ssh, and both of them worked at least till Friday mid-morning, but not after Friday afternoon.
One point to note is that I did update through yum (and have not been able to resolve my sound for this i386 machine yet). However, this iptables + ssh did work from Thursday afternoon for about 24 hours, as usual.
Perhaps something else messed it up, and will need to be fixed.
Thanks again for any help!
Best wishes, Ranjan
Ranjan
On Mon, Jan 28, 2013 at 08:23:11PM -0600, Ranjan Maitra wrote:
On Tue, 29 Jan 2013 03:01:30 +0100 Suvayu Ali <fatkasuvayu +linux@gmail.com> wrote:
I am not sure how to figure out what were in those updates. Is there a way? I am not even sure that this is an iptables issue, only that restarting it appears to be resolving the problem (namely that ssh is set to access through the standard port, which is disabled in favor of the non-standard port in the ssd_config).
# yum history list # yum history info <transaction id>
F18 uses firewalld by default instead of iptables. Maybe you need to open those non-standard ssh ports for firewalld? To do that you need to install firewall-config.
# yum install firewall-config
Hope this helps,
On Tue, 29 Jan 2013 04:00:05 +0100 Suvayu Ali <fatkasuvayu +linux@gmail.com> wrote:
On Mon, Jan 28, 2013 at 08:23:11PM -0600, Ranjan Maitra wrote:
On Tue, 29 Jan 2013 03:01:30 +0100 Suvayu Ali <fatkasuvayu +linux@gmail.com> wrote:
I am not sure how to figure out what were in those updates. Is there a way? I am not even sure that this is an iptables issue, only that restarting it appears to be resolving the problem (namely that ssh is set to access through the standard port, which is disabled in favor of the non-standard port in the ssd_config).
# yum history list # yum history info <transaction id>
These are what were updated on Friday:
Transaction performed with: Installed rpm-4.10.2-1.fc18.i686 @updates Installed yum-3.4.3-47.fc18.noarch @fedora Installed yum-metadata-parser-1.1.4-7.fc18.i686 @fedora Updated yum-plugin-fastestmirror-1.1.31-6.fc18.noarch @fedora Installed yum-presto-0.9.0-1.fc18.noarch @fedora Packages Altered: Updated dracut-024-18.git20130102.fc18.i686 @fedora Update 024-23.git20130118.fc18.i686 @updates Updated mdadm-3.2.6-7.fc18.i686 @updates Update 3.2.6-12.fc18.i686 @updates Updated parted-3.1-9.fc18.i686 @fedora Update 3.1-10.fc18.i686 @updates Updated xorg-x11-drv-nouveau-1:1.0.3-1.fc18.i686 @fedora Update 1:1.0.6-1.fc18.i686 @updates history info
F18 uses firewalld by default instead of iptables. Maybe you need to open those non-standard ssh ports for firewalld? To do that you need to install firewall-config.
# yum install firewall-config
So, this is installed. I will look into this, but this does not explain why the ssh worked ok on Thursday.
Ranjan
____________________________________________________________ FREE 3D EARTH SCREENSAVER - Watch the Earth right on your desktop! Check it out at http://www.inbox.com/earth
Ranjan Maitra <maitra.mbox.ignored <at> inbox.com> writes:
So, I have a strange problem which I can't figure out. After Friday's updates, I was unable to ssh into the machine with a nonstandard port. I changed the port to the default and was able to get in. I was able to resolve this only after stopping and starting iptables service.
Possible simple explanation: Do you have an iptables rule that restricts access to the target system to a specific host? If so, did you specify the system to allow in using a host name (or FQDN) or did you use that system's IP address? If the host name can't be resolved at startup but resolves once the system is fully up, you could have an explanation for the behavior you're seeing.
I think I've also seen this with a slow DNS or a resolv.conf that includes an unavailable DNS server.
Cheers, Dave
-
David G. Miller (aka DaveAtFraud) -
Ranjan Maitra -
Suvayu Ali