Lost SSH Access Recovery Guide - Cloud VPS

Before You Begin

Do not reinstall your OS unless you have confirmed that your data is backed up or that data loss is acceptable. Most SSH access issues can be resolved without a reinstall.

Losing SSH access to your VPS can happen for several reasons, from misconfigured firewall rules to corrupted SSH keys or forgotten passwords. This guide walks you through diagnosing the cause and recovering access using tools available through the RamNode client portal.

Common Causes of Lost SSH Access

Cause	Description
Firewall Lockout	iptables, nftables, UFW, or CSF rules blocking port 22 (or your custom SSH port).
Failed SSH Key Auth	Incorrect permissions on ~/.ssh/authorized_keys, wrong key format, or key removed during updates.
Password Change / Expiry	Root password changed, expired, or PAM modules rejecting authentication.
SSH Daemon Crash	sshd service stopped, misconfigured, or failed to start after a reboot.
Disk Full	No space on /var or /tmp preventing sshd from creating PID files or writing logs.
Network Misconfiguration	Static IP configured incorrectly, broken /etc/network/interfaces, or missing default route.
Fail2Ban / DenyHosts	Your IP was banned after too many failed login attempts.
Kernel Panic / Boot Failure	VPS not fully booting due to fstab errors, kernel issues, or corrupted filesystem.

Diagnostic Flowchart

Follow this decision tree to identify the most likely cause:

1.Can you ping your VPS IP? If NO → Network / Boot Issues. If YES → continue.
2.Can you connect to any other service? (e.g., HTTP on port 80) If NO → Firewall Lockout. If YES → continue.
3.Does SSH respond with "Connection refused"? If YES → SSH Daemon Issues. If NO → continue.
4.Does SSH prompt then reject credentials? If YES → Authentication Recovery. If NO → continue.
5.Does the connection hang or timeout? → Firewall Lockout or Fail2Ban.

Accessing the VPS Console via Client Portal

The RamNode client portal provides a web-based VNC/noVNC console that gives you direct terminal access, bypassing the network stack entirely. This is your primary recovery tool when SSH is unavailable.

Log in to the RamNode Client Portal at vpscp.ramnode.com
Select your VPS from the service list
Click the "Console" or "VNC" button in the management panel
A browser-based terminal will open with a login prompt
Log in with your root credentials (or a sudo-enabled user account)

💡 Console Tip: The VNC console may have limited copy-paste support. Keep commands short and simple. If you need to type long commands, consider piping them through a temporary script file.

Root Password Reset

Method A: Portal Password Reset

Navigate to your VPS in the RamNode Client Portal
Look for a "Root Password Reset" or "Rescue" option
Enter and confirm a new root password
Reboot the VPS if prompted
Try logging in via the VNC console with the new password

Method B: Single-User Mode (via Console)

If the portal reset does not work, boot into single-user mode:

Open the VNC console and reboot the VPS
When the GRUB bootloader appears, press e to edit the boot entry
Find the line starting with linux and append init=/bin/bash
Press Ctrl+X or F10 to boot

Remount and reset password

mount -o remount,rw /
passwd root
sync
reboot -f

⚠ GRUB Timeout: Many VPS images have a very short GRUB timeout (1–2 seconds). You may need to reboot multiple times and press a key immediately. If GRUB is hidden, try holding Shift during boot.

SSH Authentication Recovery

Fix SSH Key Permissions

SSH is extremely strict about file permissions. Incorrect permissions are the most common cause of key-based authentication failures:

Fix permissions

chmod 700 /root/.ssh
chmod 600 /root/.ssh/authorized_keys
chown -R root:root /root/.ssh

Re-add Your Public Key

Add SSH key

mkdir -p /root/.ssh
echo "ssh-rsa AAAA...your-key-here..." > /root/.ssh/authorized_keys
chmod 600 /root/.ssh/authorized_keys

Enable Password Authentication Temporarily

Temporarily enable password login

sed -i 's/^PasswordAuthentication no/PasswordAuthentication yes/' /etc/ssh/sshd_config
sed -i 's/^PermitRootLogin.*/PermitRootLogin yes/' /etc/ssh/sshd_config
systemctl restart sshd

⚠ Security Reminder: Re-disable password authentication once you have restored key-based access. Leaving password auth enabled exposes your VPS to brute-force attacks.

Verify sshd_config Syntax

Validate config

sshd -t

If there are errors, the output will indicate the line number and issue. Fix them, then restart sshd.

Firewall Lockout Recovery

Firewall misconfigurations are the single most common cause of SSH lockouts. Use the VNC console to regain access.

Identify Your Firewall

Check which firewall is active

# Check for iptables rules
iptables -L -n --line-numbers

# Check for nftables
nft list ruleset

# Check for UFW
ufw status

# Check for CSF (ConfigServer Firewall)
csf -s

Quick Fix: Flush All Rules

Flush firewall rules

# iptables
iptables -F
iptables -X
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

# UFW
ufw disable

# CSF
csf -f

Surgical Fix: Allow SSH Only

Allow SSH through firewall

# iptables (replace 22 with your custom SSH port if changed)
iptables -I INPUT 1 -p tcp --dport 22 -j ACCEPT

# UFW
ufw allow 22/tcp
ufw reload

# CSF
csf -a YOUR_IP_ADDRESS

Persist Firewall Changes

Save firewall rules

# Debian/Ubuntu (install iptables-persistent if needed)
apt install -y iptables-persistent
netfilter-persistent save

# CentOS/AlmaLinux
service iptables save

SSH Daemon Issues

Check and Restart sshd

Diagnose sshd

# Check status
systemctl status sshd

# If inactive or failed, check logs
journalctl -u sshd -n 50 --no-pager

# Attempt restart
systemctl restart sshd

# If sshd won't start, validate config
sshd -t

Reinstall SSH Server

Reinstall openssh-server

# Debian/Ubuntu
apt update && apt install --reinstall openssh-server

# CentOS/AlmaLinux
yum reinstall openssh-server

# Then start and enable
systemctl enable --now sshd

Disk Full Preventing sshd Startup

Free up disk space

# Check disk usage
df -h

# Find large files
du -sh /var/log/* | sort -rh | head -20

# Clear old logs
journalctl --vacuum-size=50M
truncate -s 0 /var/log/syslog

# Remove old kernels (Ubuntu)
apt autoremove --purge

Network & Boot Issues

Verify Network Configuration (via Console)

Check network

# Check interface status
ip addr show

# Check default route
ip route show

# Test outbound connectivity
ping -c 3 8.8.8.8

# Check DNS
cat /etc/resolv.conf

Restore DHCP Configuration

Netplan (Ubuntu 18.04+)

cat > /etc/netplan/01-fix.yaml << 'EOF'
network:
  version: 2
  ethernets:
    eth0:
      dhcp4: true
EOF
netplan apply

Traditional ifupdown

echo 'auto eth0' > /etc/network/interfaces
echo 'iface eth0 inet dhcp' >> /etc/network/interfaces
ifdown eth0 && ifup eth0

Boot Failures

• fstab errors: Edit /etc/fstab and comment out the offending line with #
• Filesystem corruption: Run fsck /dev/vda1 from single-user mode. Do NOT run fsck on a mounted filesystem.
• Kernel issues: Select an older kernel from the GRUB menu to boot.

Fail2Ban / IP Ban Recovery

Unban Your IP

Unban commands

# Fail2Ban: check if your IP is banned
fail2ban-client status sshd

# Unban your IP
fail2ban-client set sshd unbanip YOUR_IP_ADDRESS

# DenyHosts: remove from blocklist
sed -i '/YOUR_IP_ADDRESS/d' /etc/hosts.deny

# CSF: remove temporary/permanent blocks
csf -dr YOUR_IP_ADDRESS
csf -tr YOUR_IP_ADDRESS

Whitelist Your IP

Prevent future bans

# Fail2Ban: add to ignoreip
echo '[sshd]' >> /etc/fail2ban/jail.local
echo 'ignoreip = YOUR_IP_ADDRESS' >> /etc/fail2ban/jail.local
systemctl restart fail2ban

# CSF: add to allow list
csf -a YOUR_IP_ADDRESS

Last Resort — OS Reinstall

⚠ Data Loss Warning: Reinstalling the OS will erase ALL data on the VPS. If you have important data, contact RamNode support first — they may be able to mount your disk to a rescue environment so you can retrieve files before reinstalling.

Log in to the RamNode Client Portal
Select your VPS and navigate to the "Reinstall OS" section
Choose your desired OS template
Confirm the reinstall and note the new root credentials
Once complete, SSH in with the provided credentials and reconfigure your server

Preventing Future Lockouts

Always test firewall rules

Use 'at' to auto-revert: echo 'iptables -F' | at now + 5 minutes — then apply your rules. If locked out, rules revert in 5 minutes.

Keep a secondary SSH key

Store a backup key pair in a secure location. Add both public keys to authorized_keys.

Use a non-standard SSH port

Change Port in sshd_config to reduce noise, but always allow the new port in your firewall BEFORE changing it.

Enable RamNode backups

Use RamNode's snapshot or backup feature so you can restore to a known-good state.

Set up monitoring

Use an external uptime monitor (e.g., UptimeRobot) to alert you if SSH stops responding.

Document your config

Keep a record of your firewall rules, SSH port, and key fingerprints in a secure note.

Whitelist your IP in Fail2Ban

Add your static IP to the ignoreip list in /etc/fail2ban/jail.local.

Quick Reference: Emergency Commands

Keep these commands handy. All should be run from the VNC console when SSH is unavailable.

Emergency recovery commands

# Reset root password
passwd root

# Flush all firewall rules
iptables -F && iptables -P INPUT ACCEPT

# Restart SSH daemon
systemctl restart sshd

# Check sshd config for errors
sshd -t

# Unban IP from Fail2Ban
fail2ban-client set sshd unbanip YOUR_IP

# Check disk space
df -h

# View recent SSH logs
journalctl -u sshd -n 30 --no-pager

# Check listening ports
ss -tlnp | grep ssh

Getting Help from RamNode Support

If you have exhausted the self-service options above, RamNode's support team can assist with additional recovery methods including rescue boot environments and disk mounts.

• Support Portal: clientarea.ramnode.com → Open a Support Ticket

Include in your ticket: VPS hostname, IP address, what you were doing when access was lost, and any error messages from the VNC console.