SSH Issues. IPTables issues

Moved a Linux server to another network.  Had to re IP.   I am now unable to SSH to the device....SSH is running...the sshd-config file has been edited with the new IP address...

with IP tables on...no go...with IP Tables stopped...I have no issue with logging in.     I tried to duplicate an entry for ACCEPT as it was before, but added the new network that I wish to be logging in from....didnt work.   Any thoughts.
marchopkinsAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Martyn SpencerManaging DirectorCommented:
I commented on your other question. What rules do you have for port 22 in iptables?
0
Martyn SpencerManaging DirectorCommented:
The rules you showed in your other question were this:

4    DROP       tcp  --  0.0.0.0/0            63.XXX.XXX.0/24     tcp dpt:22
5    ACCEPT     tcp  --  0.0.0.0/0            10.0.0.0/24         state NEW tcp dpt:22

Open in new window


If you take a look at /etc/sysconfig/iptables do you see rules for the DROP line? It will be something like:

-A INPUT -s 0.0.0.0/0 -p tcp -m state --state NEW -m tcp --dport 22 -j DROP

Open in new window


If you do, I think that will be the cause of your problem. I am assuming that 63.XXX.XXX.0/24 is your public IP? Do you have more than one public IP on this machine? if you don't see it, it may well be that you just need to add one or two rules to make it work for you.

As a guide for you, here is a sample, cut-down iptables config file:

:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -s 10.0.0.0/24 -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -s XXX.XXX.XXX.XXX -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT

Open in new window


In this example, any devices on the 10.0.0.0/24 subnet can ssh to your machine. Also, host XXX.XXX.XXX.XXX can connect. Anything that does not match the rules is dropped, which achieves what I think you want. Do double-check this though and clearly don't just use my example without comparing it to what you have. There may be other rules and your format may be different. Mine is taken from a Centos6 machine with only SSH rules present.
0
nociSoftware EngineerCommented:
hm. what does the iptables rules look like?, the Q is a bit thin on details.

iptables -I INPUT -p tcp --dport 22 -j ACCEPT    

Open in new window

(or some variant on this is needed)
Variants might include connection tracking aka stateful inspection or allowing from some specific  source.
0
Big Business Goals? Which KPIs Will Help You

The most successful MSPs rely on metrics – known as key performance indicators (KPIs) – for making informed decisions that help their businesses thrive, rather than just survive. This eBook provides an overview of the most important KPIs used by top MSPs.

marchopkinsAuthor Commented:
i do not see that DROP rule...   Ill show you the full table with the public IP's  XXX'd out.

Im on an MPLS network where i want to be able to ssh from 192.168.40.0/24 private space to this box.  

63 network is my Public.  Yes there is more than one public IP on the machine but it is on the 63 network.

I can ping the device from my 192 network but no SSH...connection refused.

Below is the output from IPTABLES on the box that I cannot ssh into.

:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [3:324]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -m comment --comment "loopback" -j ACCEPT
-A INPUT -d 63.XXX.XXX.0/24 -p tcp -m tcp --dport 22 -j DROP
-A INPUT -d 10.0.0.0/24 -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -s XXX.XXX.XXX.XXX/32 -p udp -m state --state NEW -m udp --dport 123 -j ACCEPT
-A INPUT -d 10.0.0.0/24 -p tcp -m state --state NEW -m tcp --dport 53 -j ACCEPT
-A INPUT -d 10.0.0.0/24 -p udp -m state --state NEW -m udp --dport 53 -j ACCEPT
-A INPUT -s 63.XXX.XXX.0/24 -p tcp -m state --state NEW -m tcp --dport 53 -j ACCEPT
-A INPUT -s 63.XXX.XXX.0/24 -p udp -m state --state NEW -m udp --dport 53 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT
0
nociSoftware EngineerCommented:
-A INPUT -d 63.XXX.XXX.0/24 -p tcp -m tcp --dport 22 -j DROP

Open in new window


This would mean that anything going to 63.xxx.xxx.0/24 address will NEVER be able to connect to this system with port TCP/22
Not sure why a -d 10.0.0.0/24 or -d 63.x.x.0/24 would be used in a Firewall rule... INPUT is for localaccess on THIS system only.
The -d xxxx make more sense on a FORWARD rule (where packets pass through this system).

You Allow ICMP in the 3rd line..., but only allow restricted access to 10.0.0.0/24  so if the address of this system is OUTSIDE of the range 10.0.0.0 - 10.0.0.255 no SSH access is allowed.
2
Martyn SpencerManaging DirectorCommented:
Hopefully you have your answer now. As I suggested, you probably have a DROP rule (which you do - it is the line that noci highlights). If you need help constructing a set of rules that meet your requirements, it may be a good idea to list them and I am sure that one of us can assist.
0
arnoldCommented:
Which IPs changed? sshd_config changes sshd bnding info, it does not change firewall rules.

Prior setup
Server at site A, IP a.b.c.d
You access from site B e.f.g.h

What changed, site A moved to  new IP i.j.k.l?
Site B moved to m.n.o.p?

If site A IP changed, commonly only the external firewall needs to change and  the IP to which you connect with SSH.

If site B changed, others commented that you use iptables to restrict access which would need to be updated to reflect the authorization for the new site B IPs replacing the OLD site B IP in.
0
Steve BinkCommented:
Here's an excerpt from your table dump:
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [3:324]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -m comment --comment "loopback" -j ACCEPT
-A INPUT -d 63.XXX.XXX.0/24 -p tcp -m tcp --dport 22 -j DROP
-A INPUT -d 10.0.0.0/24 -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT

Open in new window


First, line 1 specifies that your default policy on the INPUT table is DROP.  This means that any packets not explicitly accepted will be dropped.  This is a normal configuration, but also an important point to remember.

Second, line 7 states that any SSH traffic (I say "SSH", but really just port 22) heading to your 63.*.*.* addresses will be explicitly dropped.  If that is your only public-facing set of addresses on the server, that means nothing outside of the server's local network will be able to connect.

Third, line 8 states you are explicitly accepting any TCP traffic heading to 10.*.*.* on port 22, provided the state of the packet is "NEW".  This allows new clients to *begin* communications on port 22.  However, remember that this traffic is limited to the local network - 10.0.0.0/24 is not accessible from the internet-at-large.

Finally,  line 4 states you are explicitly accepting any traffic with the packet state set as "RELATED" or "ESTABLISHED".  This allows existing communications to continue regardless of other rules.

Ideally, this means you can start an SSH session on port 22 from the local network (10.0.0.0/24).  Line 8 allows the session to be initialized, and line 4 allows continuing communication once it is established.  

To troubleshoot, verify:
- Your server's local IP range is still using 10.0.0.0/24.
- Your attempted connection is actually traversing the 10.0.0.0/24 subnet.
- Your SSH port is still set at 22.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
marchopkinsAuthor Commented:
thanks for this....i think given the explanation...that I know exactly what to do now.  I think i need to add the new Private IP Range network  10.100.20.0 /24 in the same way that the 10.0.0.0/24 network is in there.
0
marchopkinsAuthor Commented:
thanks for all of the input guys.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Linux

From novice to tech pro — start learning today.