{"id":2909,"date":"2026-05-28T02:09:07","date_gmt":"2026-05-28T02:09:07","guid":{"rendered":"https:\/\/sreschool.com\/blog\/?p=2909"},"modified":"2026-05-28T02:09:08","modified_gmt":"2026-05-28T02:09:08","slug":"godaddy-how-to-fix-ssh-whm-lockout-from-rescue-mode-by-cleaning-saved-firewall-rules","status":"publish","type":"post","link":"https:\/\/sreschool.com\/blog\/godaddy-how-to-fix-ssh-whm-lockout-from-rescue-mode-by-cleaning-saved-firewall-rules\/","title":{"rendered":"Godaddy &#8211; How to Fix SSH\/WHM Lockout from Rescue Mode by Cleaning Saved Firewall Rules"},"content":{"rendered":"\n<p><\/p>\n\n\n\n<h2 class=\"wp-block-heading\">A Practical Recovery Tutorial for WHM\/cPanel, AlmaLinux, CentOS, Rocky Linux, and RHEL Servers<\/h2>\n\n\n\n<p>Firewall lockout is one of the most stressful server incidents. A small mistake in <code>iptables<\/code>, <code>nftables<\/code>, CSF, or firewalld can suddenly block SSH, WHM, cPanel, and ping while websites may still continue working on ports <code>80<\/code> and <code>443<\/code>.<\/p>\n\n\n\n<p>This tutorial explains how to recover a Linux VPS\/server from <strong>rescue mode<\/strong> by cleaning the <strong>saved firewall rules of the original operating system<\/strong>, not the temporary rescue environment.<\/p>\n\n\n\n<p>This is useful when:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>SSH is not accessible\nWHM\/cPanel is not accessible\nPing stops after boot\nOnly websites on 80\/443 are working\nFirewall rules were saved incorrectly\nYour own IP changed after adding firewall allow rules\nThe server boots normally but you cannot log in\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">Important Concept: Rescue Mode Firewall Is Not the Real Server Firewall<\/h1>\n\n\n\n<p>When a server is booted into rescue mode, you are usually running a temporary operating system provided by the hosting provider.<\/p>\n\n\n\n<p>So this command in rescue mode:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>systemctl disable firewalld nftables iptables ip6tables csf lfd\n<\/code><\/pre>\n\n\n\n<p>may affect only the <strong>rescue OS<\/strong>, not your real WHM\/cPanel installation.<\/p>\n\n\n\n<p>To fix the real server, you must:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>1. Mount the original root partition\n2. Edit the saved firewall files inside the mounted disk\n3. Disable firewall services inside the original OS\n4. Reboot back into normal mode\n5. Rebuild safe firewall rules\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">Common Symptoms<\/h1>\n\n\n\n<p>You may see something like this from your local machine:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>Request timeout for icmp_seq 141\nRequest timeout for icmp_seq 142\n64 bytes from SERVER_IP: icmp_seq=145 ttl=33 time=283 ms\n64 bytes from SERVER_IP: icmp_seq=146 ttl=33 time=285 ms\nRequest timeout for icmp_seq 149\nRequest timeout for icmp_seq 150\n<\/code><\/pre>\n\n\n\n<p>This usually means:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>Network comes up during boot\nThen firewall rules load\nThen ping\/SSH\/WHM gets blocked\n<\/code><\/pre>\n\n\n\n<p>If websites are still accessible, the server is alive. The issue is usually firewall access, not a dead server.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">Example Scenario<\/h1>\n\n\n\n<p>Assume:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>Server IP: 92.205.20.47\nYour current admin IP: 1.73.146.125\nOriginal root partition: \/dev\/sda4\nMount point: \/mnt\/original\n<\/code><\/pre>\n\n\n\n<p>Do not blindly use old IPs. First confirm your current public IP from your local machine:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>curl -4 ifconfig.me\n<\/code><\/pre>\n\n\n\n<p>If your IP changes frequently, do not rely on only one fixed IP without a recovery method.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">Part 1: Boot Server into Rescue Mode<\/h1>\n\n\n\n<p>Use your hosting provider panel to boot the server into rescue mode.<\/p>\n\n\n\n<p>Then log in to the rescue shell as root.<\/p>\n\n\n\n<p>Confirm available disks:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>lsblk -f\n<\/code><\/pre>\n\n\n\n<p>You may see something like:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sda\n\u251c\u2500sda1\n\u251c\u2500sda2\n\u251c\u2500sda3\n\u2514\u2500sda4\n<\/code><\/pre>\n\n\n\n<p>In many systems, the real root partition may be:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>\/dev\/sda4\n<\/code><\/pre>\n\n\n\n<p>But it may also be:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>\/dev\/sdb4\n\/dev\/vda4\n\/dev\/nvme0n1p4\n<\/code><\/pre>\n\n\n\n<p>Always verify before mounting.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">Part 2: Mount the Original OS<\/h1>\n\n\n\n<p>Assuming your real root partition is <code>\/dev\/sda4<\/code>:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>mkdir -p \/mnt\/original\nmount \/dev\/sda4 \/mnt\/original\n<\/code><\/pre>\n\n\n\n<p>If the partition is different, replace <code>\/dev\/sda4<\/code> with the correct partition.<\/p>\n\n\n\n<p>Confirm it looks like a real Linux root filesystem:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ls -lah \/mnt\/original\n<\/code><\/pre>\n\n\n\n<p>You should see directories like:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>etc\nroot\nhome\nusr\nvar\nboot\n<\/code><\/pre>\n\n\n\n<p>For a WHM\/cPanel server, you may also see:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ls -ld \/mnt\/original\/usr\/local\/cpanel \/mnt\/original\/var\/cpanel 2&gt;\/dev\/null\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">Part 3: Backup Existing Firewall Configuration<\/h1>\n\n\n\n<p>Before changing anything, create one backup directory and copy all firewall-related files there.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>BACKUP_DIR=\"\/mnt\/original\/root\/firewall-backup-$(date +%F-%H%M)\"\nmkdir -p \"$BACKUP_DIR\"\n\ncp -a \/mnt\/original\/etc\/sysconfig\/iptables* \"$BACKUP_DIR\"\/ 2&gt;\/dev\/null || true\ncp -a \/mnt\/original\/etc\/nftables.conf \"$BACKUP_DIR\"\/ 2&gt;\/dev\/null || true\ncp -a \/mnt\/original\/etc\/firewalld \"$BACKUP_DIR\"\/ 2&gt;\/dev\/null || true\ncp -a \/mnt\/original\/etc\/csf \"$BACKUP_DIR\"\/ 2&gt;\/dev\/null || true\n\necho \"Backup saved at: $BACKUP_DIR\"\n<\/code><\/pre>\n\n\n\n<p>This protects files such as:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>\/etc\/sysconfig\/iptables\n\/etc\/sysconfig\/ip6tables\n\/etc\/nftables.conf\n\/etc\/firewalld\/\n\/etc\/csf\/\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">Part 4: Reset Saved iptables Rules to ACCEPT<\/h1>\n\n\n\n<p>Create safe, open saved rules for IPv4:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>mkdir -p \/mnt\/original\/etc\/sysconfig\n\ncat &gt; \/mnt\/original\/etc\/sysconfig\/iptables &lt;&lt; 'EOF'\n*filter\n:INPUT ACCEPT &#91;0:0]\n:FORWARD ACCEPT &#91;0:0]\n:OUTPUT ACCEPT &#91;0:0]\nCOMMIT\nEOF\n<\/code><\/pre>\n\n\n\n<p>Create safe, open saved rules for IPv6:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>cat &gt; \/mnt\/original\/etc\/sysconfig\/ip6tables &lt;&lt; 'EOF'\n*filter\n:INPUT ACCEPT &#91;0:0]\n:FORWARD ACCEPT &#91;0:0]\n:OUTPUT ACCEPT &#91;0:0]\nCOMMIT\nEOF\n<\/code><\/pre>\n\n\n\n<p>This removes saved DROP rules that may block SSH, WHM, or cPanel after reboot.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">Part 5: Reset nftables Rules<\/h1>\n\n\n\n<p>If <code>nftables<\/code> was used, reset its saved config too:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>cat &gt; \/mnt\/original\/etc\/nftables.conf &lt;&lt; 'EOF'\nflush ruleset\nEOF\n<\/code><\/pre>\n\n\n\n<p>This prevents old nftables rules from being restored during boot.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">Part 6: Disable Firewall Services in the Original OS<\/h1>\n\n\n\n<p>Do not just run <code>systemctl disable<\/code> in rescue mode without pointing to the original OS.<\/p>\n\n\n\n<p>Use <code>systemctl --root<\/code>:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>systemctl --root=\/mnt\/original disable firewalld 2&gt;\/dev\/null || true\nsystemctl --root=\/mnt\/original disable nftables 2&gt;\/dev\/null || true\nsystemctl --root=\/mnt\/original disable iptables 2&gt;\/dev\/null || true\nsystemctl --root=\/mnt\/original disable ip6tables 2&gt;\/dev\/null || true\nsystemctl --root=\/mnt\/original disable csf 2&gt;\/dev\/null || true\nsystemctl --root=\/mnt\/original disable lfd 2&gt;\/dev\/null || true\n<\/code><\/pre>\n\n\n\n<p>If <code>systemctl --root<\/code> does not work, use chroot:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>mount --bind \/dev \/mnt\/original\/dev\nmount --bind \/proc \/mnt\/original\/proc\nmount --bind \/sys \/mnt\/original\/sys\nmount --bind \/run \/mnt\/original\/run\n\nchroot \/mnt\/original \/bin\/bash -c \"systemctl disable firewalld nftables iptables ip6tables csf lfd 2&gt;\/dev\/null || true\"\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">Part 7: Disable CSF If It Exists<\/h1>\n\n\n\n<p>If CSF exists, create a disable marker:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>touch \/mnt\/original\/etc\/csf\/csf.disable 2&gt;\/dev\/null || true\n<\/code><\/pre>\n\n\n\n<p>You can also inspect CSF files:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ls -lah \/mnt\/original\/etc\/csf 2&gt;\/dev\/null\n<\/code><\/pre>\n\n\n\n<p>Check if your IP was blocked:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>grep -R \"YOUR_IP_HERE\" \/mnt\/original\/etc\/csf\/ 2&gt;\/dev\/null\n<\/code><\/pre>\n\n\n\n<p>Example:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>grep -R \"1.73.146.125\" \/mnt\/original\/etc\/csf\/ 2&gt;\/dev\/null\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">Part 8: Reboot into Normal Mode<\/h1>\n\n\n\n<p>Once saved firewall rules are cleaned:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>reboot\n<\/code><\/pre>\n\n\n\n<p>Now boot the server back into normal mode from your provider panel if required.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">Part 9: Verify Access After Normal Boot<\/h1>\n\n\n\n<p>From your local machine:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ping 92.205.20.47\n<\/code><\/pre>\n\n\n\n<p>Test important ports:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>for p in 22 80 443 2087 2086 2083 2082 2095 2096; do\n  echo \"Testing port $p\"\n  nc -vz -G 5 92.205.20.47 $p\ndone\n<\/code><\/pre>\n\n\n\n<p>Meaning:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>succeeded  = port reachable\ntimeout    = firewall drop or network block\nrefused    = service not listening\n<\/code><\/pre>\n\n\n\n<p>If SSH gives a host key warning:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!\n<\/code><\/pre>\n\n\n\n<p>verify the server fingerprint from console:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ssh-keygen -l -f \/etc\/ssh\/ssh_host_ed25519_key.pub\n<\/code><\/pre>\n\n\n\n<p>Then remove the old known host entry from your local machine:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ssh-keygen -R 92.205.20.47\n<\/code><\/pre>\n\n\n\n<p>Reconnect:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ssh USERNAME@92.205.20.47\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">Part 10: Rebuild Firewall Rules Safely After Login<\/h1>\n\n\n\n<p>After you regain SSH\/WHM access, rebuild firewall rules carefully.<\/p>\n\n\n\n<p>First, confirm your current public IP:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>curl -4 ifconfig.me\n<\/code><\/pre>\n\n\n\n<p>Example:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>1.73.146.125\n<\/code><\/pre>\n\n\n\n<p>Set it:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>MYIP=\"1.73.146.125\"\n<\/code><\/pre>\n\n\n\n<p>Now create safer rules.<\/p>\n\n\n\n<p>Important: Always include this rule:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>-m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT\n<\/code><\/pre>\n\n\n\n<p>This protects existing SSH sessions from being killed when new DROP rules are added.<\/p>\n\n\n\n<p>Run as root:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>iptables -F INPUT\niptables -P INPUT ACCEPT\n\niptables -I INPUT 1 -i lo -j ACCEPT\niptables -I INPUT 2 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT\niptables -I INPUT 3 -p tcp -m multiport --dports 80,443 -j ACCEPT\niptables -I INPUT 4 -p tcp -s \"$MYIP\" -m multiport --dports 22,2087,2086,2083,2082,2095,2096 -j ACCEPT\niptables -I INPUT 5 -p icmp -s \"$MYIP\" --icmp-type echo-request -j ACCEPT\n\niptables -A INPUT -p tcp -m multiport --dports 22,2087,2086,2083,2082,2095,2096 -j DROP\n<\/code><\/pre>\n\n\n\n<p>Save rules:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>iptables-save &gt; \/etc\/sysconfig\/iptables\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">Important WHM\/cPanel Ports<\/h1>\n\n\n\n<p>For WHM\/cPanel servers:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>22    SSH\n80    HTTP\n443   HTTPS\n2082  cPanel non-SSL\n2083  cPanel SSL\n2086  WHM non-SSL\n2087  WHM SSL\n2095  Webmail non-SSL\n2096  Webmail SSL\n<\/code><\/pre>\n\n\n\n<p>Usually:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>80 and 443 should be public\n22, 2086, 2087, 2082, 2083 should be restricted to admin IPs\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">Safer Temporary Rule for Dynamic IP Users<\/h1>\n\n\n\n<p>If your ISP changes your IP often, a single IP rule may lock you out.<\/p>\n\n\n\n<p>Example problem:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>Allowed IP: 1.73.128.79\nActual IP:  1.73.146.125\nResult: SSH blocked\n<\/code><\/pre>\n\n\n\n<p>In emergency situations, you can temporarily allow a small subnet:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>MYNET=\"1.73.146.0\/24\"\n\niptables -I INPUT 1 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT\niptables -I INPUT 2 -p tcp -s \"$MYNET\" -m multiport --dports 22,2087,2086,2083,2082,2095,2096 -j ACCEPT\n<\/code><\/pre>\n\n\n\n<p>Then test access. After recovery, narrow the rule if you have a static VPN or fixed office IP.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">How to Check Current Firewall Rules<\/h1>\n\n\n\n<pre class=\"wp-block-code\"><code>iptables -L INPUT -n --line-numbers\n<\/code><\/pre>\n\n\n\n<p>Check saved rules:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>cat \/etc\/sysconfig\/iptables\n<\/code><\/pre>\n\n\n\n<p>Check nftables:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>nft list ruleset\n<\/code><\/pre>\n\n\n\n<p>Check active firewall services:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>systemctl status firewalld --no-pager\nsystemctl status nftables --no-pager\nsystemctl status iptables --no-pager\nsystemctl status csf --no-pager\nsystemctl status lfd --no-pager\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">Emergency Rollback from Normal Mode<\/h1>\n\n\n\n<p>If your SSH session is still active but firewall rules are wrong, immediately run:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>iptables -F INPUT\niptables -P INPUT ACCEPT\niptables-save &gt; \/etc\/sysconfig\/iptables\n<\/code><\/pre>\n\n\n\n<p>This opens INPUT traffic again.<\/p>\n\n\n\n<p>Then rebuild rules slowly.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">Emergency Rollback from Rescue Mode<\/h1>\n\n\n\n<p>If you are locked out again, boot into rescue mode and run:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>mkdir -p \/mnt\/original\nmount \/dev\/sda4 \/mnt\/original\n<\/code><\/pre>\n\n\n\n<p>Then reset saved firewall rules:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>cat &gt; \/mnt\/original\/etc\/sysconfig\/iptables &lt;&lt; 'EOF'\n*filter\n:INPUT ACCEPT &#91;0:0]\n:FORWARD ACCEPT &#91;0:0]\n:OUTPUT ACCEPT &#91;0:0]\nCOMMIT\nEOF\n\ncat &gt; \/mnt\/original\/etc\/sysconfig\/ip6tables &lt;&lt; 'EOF'\n*filter\n:INPUT ACCEPT &#91;0:0]\n:FORWARD ACCEPT &#91;0:0]\n:OUTPUT ACCEPT &#91;0:0]\nCOMMIT\nEOF\n\ncat &gt; \/mnt\/original\/etc\/nftables.conf &lt;&lt; 'EOF'\nflush ruleset\nEOF\n<\/code><\/pre>\n\n\n\n<p>Disable firewall services for the original OS:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>systemctl --root=\/mnt\/original disable firewalld nftables iptables ip6tables csf lfd 2&gt;\/dev\/null || true\n<\/code><\/pre>\n\n\n\n<p>Then reboot:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>reboot\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">Common Mistake That Causes Lockout<\/h1>\n\n\n\n<p>This is risky:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>MYIP=\"1.73.128.79\"\n\niptables -I INPUT 1 -p tcp -m multiport --dports 80,443 -j ACCEPT\niptables -I INPUT 2 -p tcp -s $MYIP -m multiport --dports 22,2087,2086,2083,2082,2095,2096 -j ACCEPT\niptables -A INPUT -p tcp -m multiport --dports 22,2087,2086,2083,2082,2095,2096 -j DROP\n<\/code><\/pre>\n\n\n\n<p>Why?<\/p>\n\n\n\n<p>Because if your real current IP is different, for example:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>1.73.146.125\n<\/code><\/pre>\n\n\n\n<p>then your SSH will be blocked.<\/p>\n\n\n\n<p>Also, without:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>iptables -I INPUT 1 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT\n<\/code><\/pre>\n\n\n\n<p>your active SSH session may freeze or become unstable.<\/p>\n\n\n\n<p>The safer version is:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>MYIP=\"$(curl -4 -s ifconfig.me)\"\n\niptables -F INPUT\niptables -P INPUT ACCEPT\n\niptables -I INPUT 1 -i lo -j ACCEPT\niptables -I INPUT 2 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT\niptables -I INPUT 3 -p tcp -m multiport --dports 80,443 -j ACCEPT\niptables -I INPUT 4 -p tcp -s \"$MYIP\" -m multiport --dports 22,2087,2086,2083,2082,2095,2096 -j ACCEPT\niptables -A INPUT -p tcp -m multiport --dports 22,2087,2086,2083,2082,2095,2096 -j DROP\n\niptables-save &gt; \/etc\/sysconfig\/iptables\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">Final Recommended Recovery Flow<\/h1>\n\n\n\n<p>Use this sequence:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>1. Boot into rescue mode\n2. Mount original OS root partition\n3. Backup firewall config files\n4. Reset \/etc\/sysconfig\/iptables\n5. Reset \/etc\/sysconfig\/ip6tables\n6. Reset \/etc\/nftables.conf\n7. Disable firewalld\/nftables\/iptables\/csf\/lfd in original OS\n8. Reboot normal mode\n9. Confirm SSH\/WHM access\n10. Rebuild firewall with current IP\n11. Add ESTABLISHED,RELATED rule\n12. Save firewall rules\n13. Test from a second terminal before closing existing session\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h1 class=\"wp-block-heading\">Conclusion<\/h1>\n\n\n\n<p>Yes, you can clean saved firewall rules from rescue mode, but the key is this:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>Do it on the mounted original OS, not the rescue OS.\n<\/code><\/pre>\n\n\n\n<p>The safest recovery strategy is to temporarily reset firewall rules to <code>ACCEPT<\/code>, regain SSH\/WHM access, then rebuild firewall rules carefully using your <strong>current public IP<\/strong>.<\/p>\n\n\n\n<p>For WHM\/cPanel servers, keep websites public on:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>80, 443\n<\/code><\/pre>\n\n\n\n<p>Restrict admin services to your trusted IP:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>22, 2086, 2087, 2082, 2083, 2095, 2096\n<\/code><\/pre>\n\n\n\n<p>And always add this before applying DROP rules:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>iptables -I INPUT 1 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT\n<\/code><\/pre>\n\n\n\n<p>That one rule can save you from locking yourself out again.<\/p>\n\n\n\n<p><\/p>\n","protected":false},"excerpt":{"rendered":"<p>A Practical Recovery Tutorial for WHM\/cPanel, AlmaLinux, CentOS, Rocky Linux, and RHEL Servers Firewall lockout is one of the most [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-2909","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v26.5 - https:\/\/yoast.com\/wordpress\/plugins\/seo\/ -->\n<title>Godaddy - How to Fix SSH\/WHM Lockout from Rescue Mode by Cleaning Saved Firewall Rules - SRE School<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/sreschool.com\/blog\/godaddy-how-to-fix-ssh-whm-lockout-from-rescue-mode-by-cleaning-saved-firewall-rules\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Godaddy - How to Fix SSH\/WHM Lockout from Rescue Mode by Cleaning Saved Firewall Rules - SRE School\" \/>\n<meta property=\"og:description\" content=\"A Practical Recovery Tutorial for WHM\/cPanel, AlmaLinux, CentOS, Rocky Linux, and RHEL Servers Firewall lockout is one of the most [&hellip;]\" \/>\n<meta property=\"og:url\" content=\"https:\/\/sreschool.com\/blog\/godaddy-how-to-fix-ssh-whm-lockout-from-rescue-mode-by-cleaning-saved-firewall-rules\/\" \/>\n<meta property=\"og:site_name\" content=\"SRE School\" \/>\n<meta property=\"article:published_time\" content=\"2026-05-28T02:09:07+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2026-05-28T02:09:08+00:00\" \/>\n<meta name=\"author\" content=\"Rajesh Kumar\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Rajesh Kumar\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"4 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"WebPage\",\"@id\":\"https:\/\/sreschool.com\/blog\/godaddy-how-to-fix-ssh-whm-lockout-from-rescue-mode-by-cleaning-saved-firewall-rules\/\",\"url\":\"https:\/\/sreschool.com\/blog\/godaddy-how-to-fix-ssh-whm-lockout-from-rescue-mode-by-cleaning-saved-firewall-rules\/\",\"name\":\"Godaddy - How to Fix SSH\/WHM Lockout from Rescue Mode by Cleaning Saved Firewall Rules - SRE School\",\"isPartOf\":{\"@id\":\"https:\/\/sreschool.com\/blog\/#website\"},\"datePublished\":\"2026-05-28T02:09:07+00:00\",\"dateModified\":\"2026-05-28T02:09:08+00:00\",\"author\":{\"@id\":\"https:\/\/sreschool.com\/blog\/#\/schema\/person\/0ffe446f77bb2589992dbe3a7f417201\"},\"breadcrumb\":{\"@id\":\"https:\/\/sreschool.com\/blog\/godaddy-how-to-fix-ssh-whm-lockout-from-rescue-mode-by-cleaning-saved-firewall-rules\/#breadcrumb\"},\"inLanguage\":\"en\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/sreschool.com\/blog\/godaddy-how-to-fix-ssh-whm-lockout-from-rescue-mode-by-cleaning-saved-firewall-rules\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/sreschool.com\/blog\/godaddy-how-to-fix-ssh-whm-lockout-from-rescue-mode-by-cleaning-saved-firewall-rules\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/sreschool.com\/blog\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Godaddy &#8211; How to Fix SSH\/WHM Lockout from Rescue Mode by Cleaning Saved Firewall Rules\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/sreschool.com\/blog\/#website\",\"url\":\"https:\/\/sreschool.com\/blog\/\",\"name\":\"SRESchool\",\"description\":\"Master SRE. Build Resilient Systems. Lead the Future of Reliability\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/sreschool.com\/blog\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en\"},{\"@type\":\"Person\",\"@id\":\"https:\/\/sreschool.com\/blog\/#\/schema\/person\/0ffe446f77bb2589992dbe3a7f417201\",\"name\":\"Rajesh Kumar\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en\",\"@id\":\"https:\/\/sreschool.com\/blog\/#\/schema\/person\/image\/\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/f901a4f2929fa034a291a8363d589791d5a3c1f6a051c22e744acb8bfc8e022a?s=96&d=mm&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/f901a4f2929fa034a291a8363d589791d5a3c1f6a051c22e744acb8bfc8e022a?s=96&d=mm&r=g\",\"caption\":\"Rajesh Kumar\"},\"sameAs\":[\"http:\/\/sreschool.com\/blog\"],\"url\":\"https:\/\/sreschool.com\/blog\/author\/admin\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Godaddy - How to Fix SSH\/WHM Lockout from Rescue Mode by Cleaning Saved Firewall Rules - SRE School","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/sreschool.com\/blog\/godaddy-how-to-fix-ssh-whm-lockout-from-rescue-mode-by-cleaning-saved-firewall-rules\/","og_locale":"en_US","og_type":"article","og_title":"Godaddy - How to Fix SSH\/WHM Lockout from Rescue Mode by Cleaning Saved Firewall Rules - SRE School","og_description":"A Practical Recovery Tutorial for WHM\/cPanel, AlmaLinux, CentOS, Rocky Linux, and RHEL Servers Firewall lockout is one of the most [&hellip;]","og_url":"https:\/\/sreschool.com\/blog\/godaddy-how-to-fix-ssh-whm-lockout-from-rescue-mode-by-cleaning-saved-firewall-rules\/","og_site_name":"SRE School","article_published_time":"2026-05-28T02:09:07+00:00","article_modified_time":"2026-05-28T02:09:08+00:00","author":"Rajesh Kumar","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Rajesh Kumar","Est. reading time":"4 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"https:\/\/sreschool.com\/blog\/godaddy-how-to-fix-ssh-whm-lockout-from-rescue-mode-by-cleaning-saved-firewall-rules\/","url":"https:\/\/sreschool.com\/blog\/godaddy-how-to-fix-ssh-whm-lockout-from-rescue-mode-by-cleaning-saved-firewall-rules\/","name":"Godaddy - How to Fix SSH\/WHM Lockout from Rescue Mode by Cleaning Saved Firewall Rules - SRE School","isPartOf":{"@id":"https:\/\/sreschool.com\/blog\/#website"},"datePublished":"2026-05-28T02:09:07+00:00","dateModified":"2026-05-28T02:09:08+00:00","author":{"@id":"https:\/\/sreschool.com\/blog\/#\/schema\/person\/0ffe446f77bb2589992dbe3a7f417201"},"breadcrumb":{"@id":"https:\/\/sreschool.com\/blog\/godaddy-how-to-fix-ssh-whm-lockout-from-rescue-mode-by-cleaning-saved-firewall-rules\/#breadcrumb"},"inLanguage":"en","potentialAction":[{"@type":"ReadAction","target":["https:\/\/sreschool.com\/blog\/godaddy-how-to-fix-ssh-whm-lockout-from-rescue-mode-by-cleaning-saved-firewall-rules\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/sreschool.com\/blog\/godaddy-how-to-fix-ssh-whm-lockout-from-rescue-mode-by-cleaning-saved-firewall-rules\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/sreschool.com\/blog\/"},{"@type":"ListItem","position":2,"name":"Godaddy &#8211; How to Fix SSH\/WHM Lockout from Rescue Mode by Cleaning Saved Firewall Rules"}]},{"@type":"WebSite","@id":"https:\/\/sreschool.com\/blog\/#website","url":"https:\/\/sreschool.com\/blog\/","name":"SRESchool","description":"Master SRE. Build Resilient Systems. Lead the Future of Reliability","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/sreschool.com\/blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en"},{"@type":"Person","@id":"https:\/\/sreschool.com\/blog\/#\/schema\/person\/0ffe446f77bb2589992dbe3a7f417201","name":"Rajesh Kumar","image":{"@type":"ImageObject","inLanguage":"en","@id":"https:\/\/sreschool.com\/blog\/#\/schema\/person\/image\/","url":"https:\/\/secure.gravatar.com\/avatar\/f901a4f2929fa034a291a8363d589791d5a3c1f6a051c22e744acb8bfc8e022a?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/f901a4f2929fa034a291a8363d589791d5a3c1f6a051c22e744acb8bfc8e022a?s=96&d=mm&r=g","caption":"Rajesh Kumar"},"sameAs":["http:\/\/sreschool.com\/blog"],"url":"https:\/\/sreschool.com\/blog\/author\/admin\/"}]}},"_links":{"self":[{"href":"https:\/\/sreschool.com\/blog\/wp-json\/wp\/v2\/posts\/2909","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/sreschool.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/sreschool.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/sreschool.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/sreschool.com\/blog\/wp-json\/wp\/v2\/comments?post=2909"}],"version-history":[{"count":1,"href":"https:\/\/sreschool.com\/blog\/wp-json\/wp\/v2\/posts\/2909\/revisions"}],"predecessor-version":[{"id":2910,"href":"https:\/\/sreschool.com\/blog\/wp-json\/wp\/v2\/posts\/2909\/revisions\/2910"}],"wp:attachment":[{"href":"https:\/\/sreschool.com\/blog\/wp-json\/wp\/v2\/media?parent=2909"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/sreschool.com\/blog\/wp-json\/wp\/v2\/categories?post=2909"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/sreschool.com\/blog\/wp-json\/wp\/v2\/tags?post=2909"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}