{"id":13622,"date":"2026-03-11T11:12:14","date_gmt":"2026-03-11T05:42:14","guid":{"rendered":"https:\/\/www.youstable.com\/blog\/?p=13622"},"modified":"2026-03-11T11:12:26","modified_gmt":"2026-03-11T05:42:26","slug":"fix-ssh-on-linux","status":"publish","type":"post","link":"https:\/\/www.youstable.com\/blog\/fix-ssh-on-linux","title":{"rendered":"How to Fix SSH on Linux Server? Practical Recovery Guide"},"content":{"rendered":"\n

To fix SSH on a Linux server<\/strong>, verify network reachability, confirm the SSH daemon (sshd) is running, ensure the correct port is open in the firewall and cloud security groups, inspect logs for errors, validate sshd_config syntax and permissions, then safely restart the service. If locked out, use a provider console or rescue mode to recover access.<\/p>\n\n\n\n

Secure Shell (SSH) is the lifeline to any Linux server. When it breaks, work stops. In this guide, I\u2019ll show you how to fix SSH on a Linux server step by step, covering connection timeouts, \u201cPermission denied (publickey)\u201d, service failures, misconfigurations, SELinux, Fail2ban, and cloud firewall issues, using safe, proven methods from years of server administration.<\/p>\n\n\n\n

Whether you manage a VPS, dedicated server, or cloud instance, these checks will help you diagnose and resolve SSH problems quickly without risking lockouts. If you use a managed VPS from YouStable, our support can also restore access and harden your SSH configuration for you.<\/p>\n\n\n\n

\n\n\n\n

Quick Checks for Common SSH Errors<\/h2>\n\n\n\n

1) Confirm network reachability and DNS<\/h3>\n\n\n\n

If you can\u2019t connect at all, ensure the server is online and the hostname resolves correctly.<\/p>\n\n\n\n

# From your local machine\nping -c3 your-server.com\ndig +short A your-server.com\ntraceroute your-server.com  # or mtr your-server.com<\/code><\/pre>\n\n\n\n
If DNS is wrong, connect via the server\u2019s<\/a> public IP instead of the hostname and fix DNS later.<\/p>\n\n\n\n
2) Test port reachability (default 22)<\/strong><\/h3>\n\n\n\n
Check if the SSH port is open and reachable. Some admins move SSH to a non standard port.<\/p>\n\n\n\n
nc -vz your-server.com 22\n# or\nnmap -p 22 your-server.com<\/code><\/pre>\n\n\n\n
If connection is refused or filtered, jump ahead to firewall and cloud security<\/a> group fixes.<\/p>\n\n\n\n
3) Verify the SSH service (sshd) is running<\/h3>\n\n\n\n
Use the provider\u2019s web\/VNC console or a KVM to run commands on the box if you\u2019re locked out.<\/p>\n\n\n\n
# Systemd-based distros (Ubuntu, Debian, RHEL, CentOS, AlmaLinux, Rocky)\nsudo systemctl status ssh     # Debian\/Ubuntu service name: ssh\nsudo systemctl status sshd    # RHEL\/CentOS\/Alma\/Rocky service name: sshd\n\n# Start and enable if needed\nsudo systemctl enable --now sshd || sudo systemctl enable --now ssh\n\n# Check listening port\nsudo ss -tlnp | grep sshd     # or: sudo netstat -tlnp | grep sshd<\/code><\/pre>\n\n\n\n
If it isn\u2019t listening, review logs and configuration next.<\/p>\n\n\n\n
\n\n\n\n
Fix Connection Refused or Timeout<\/h2>\n\n\n\n
Ensure sshd is listening on the correct port<\/h3>\n\n\n\n
Check and correct the Port directive in \/etc\/ssh\/sshd_config, then test configuration before restarting.<\/p>\n\n\n\n
sudo grep -i '^Port' \/etc\/ssh\/sshd_config\n# Test config (no output = OK)\nsudo sshd -t\n# Restart service\nsudo systemctl restart sshd || sudo systemctl restart ssh\n# Confirm listening port\nsudo ss -tlnp | grep sshd<\/code><\/pre>\n\n\n\n
If you changed the port, remember to specify it when connecting: ssh -p 2222 user@host.<\/p>\n\n\n\n
Open the port in the server firewall (UFW, firewalld, iptables)<\/h3>\n\n\n\n
Allow SSH in your host firewall. Replace 22 with your custom port if changed.<\/p>\n\n\n\n
# UFW (Ubuntu)\nsudo ufw allow 22\/tcp\nsudo ufw status\n\n# firewalld (RHEL\/Alma\/Rocky\/CentOS Stream\/Fedora)\nsudo firewall-cmd --permanent --add-service=ssh\n# If using a non-standard port:\n# sudo firewall-cmd --permanent --add-port=2222\/tcp\nsudo firewall-cmd --reload\nsudo firewall-cmd --list-all\n\n# iptables (legacy)\nsudo iptables -I INPUT -p tcp --dport 22 -j ACCEPT\nsudo service iptables save || sudo iptables-save | sudo tee \/etc\/iptables.rules<\/code><\/pre>\n\n\n\n
Check cloud security groups and provider firewalls<\/h3>\n\n\n\n
On AWS, GCP, Azure, or many VPS providers, a network firewall may block SSH regardless of the OS firewall. Allow TCP 22 (or your custom port) from your IP or trusted ranges in the provider\u2019s console.<\/p>\n\n\n\n
Review Fail2ban, CSF, and intrusion tools<\/h3>\n\n\n\n
If you tried many times, your IP may be banned. Unban or temporarily disable to test.<\/p>\n\n\n\n
sudo fail2ban-client status sshd\nsudo fail2ban-client unban <your.ip.address>\n\n# CSF (ConfigServer Firewall)\nsudo csf -g <your.ip.address>    # find\nsudo csf -dr <your.ip.address>   # remove\/deny rule\nsudo csf -tr <your.ip.address>   # temporary allow<\/code><\/pre>\n\n\n\n
\n\n\n\n
Fix Authentication Failures<\/h2>\n\n\n\n
Password vs key authentication<\/h3>\n\n\n\n
Know what\u2019s allowed by sshd_config. Many servers disable passwords for security and require SSH keys<\/a>.<\/p>\n\n\n\n
sudo egrep -i '^(PasswordAuthentication|PubkeyAuthentication|PermitRootLogin)' \/etc\/ssh\/sshd_config\nsudo sshd -T | egrep 'passwordauthentication|pubkeyauthentication|permitrootlogin'<\/code><\/pre>\n\n\n\n
If you must temporarily enable passwords to restore access, set PasswordAuthentication yes, restart SSH, log in, then re-enable keys and disable passwords again as a best practice.<\/p>\n\n\n\n
Fix \u201cPermission denied (publickey)\u201d by correcting permissions<\/h3>\n\n\n\n
SSH will ignore keys<\/a> if file permissions or ownership are too open or incorrect.<\/p>\n\n\n\n
# As the target user (or via sudo specifying user paths)\nchmod 700 ~\/.ssh\nchmod 600 ~\/.ssh\/authorized_keys\nchown -R $USER:$USER ~\/.ssh\nls -ld ~\/.ssh; ls -l ~\/.ssh\/authorized_keys\n\n# Confirm the server sees your key attempt (on the client)\nssh -vvv user@server<\/code><\/pre>\n\n\n\n
Ensure your public key (~\/.ssh\/id_rsa.pub or id_ed25519.pub) is in ~\/.ssh\/authorized_keys on the server, exactly one line per key.<\/p>\n\n\n\n
Reset a user password or add a key via console<\/h3>\n\n\n\n
If completely locked out, use the provider console\/KVM or rescue mode to add your key or reset a password safely.<\/p>\n\n\n\n
# Create user and add a key (replace <user> and pubkey)\nsudo useradd -m -s \/bin\/bash <user>\nsudo mkdir<\/a> -p \/home\/<user>\/.ssh\necho \"ssh-ed25519 AAAA... your_email\" | sudo tee \/home\/<user>\/.ssh\/authorized_keys\nsudo chown -R <user>:<user> \/home\/<user>\/.ssh\nsudo chmod 700 \/home\/<user>\/.ssh\nsudo chmod 600 \/home\/<user>\/.ssh\/authorized_keys\nsudo usermod -aG sudo <user>  # Debian\/Ubuntu\nsudo usermod -aG wheel <user>  # RHEL\/Alma\/Rocky<\/code><\/pre>\n\n\n\n
Root login policies<\/h3>\n\n\n\n
For security, PermitRootLogin should be no or prohibit password. Use a sudo capable user to administer. If you must enable root temporarily, revert after recovery and secure with keys or 2FA.<\/p>\n\n\n\n
\n\n\n\n
Fix and Safeguard sshd_config<\/strong><\/h2>\n\n\n\n
Create backups and validate syntax<\/h3>\n\n\n\n
Always back up before editing. Validate syntax to avoid lockouts.<\/p>\n\n\n\n
sudo cp \/etc\/ssh\/sshd_config \/etc\/ssh\/sshd_config.bak.$(date +%F-%H%M)\nsudo nano \/etc\/ssh\/sshd_config   # or your editor\nsudo sshd -t                     # syntax check\nsudo systemctl restart sshd || sudo systemctl restart ssh<\/code><\/pre>\n\n\n\n
Know effective settings and rollback plan<\/h3>\n\n\n\n
List effective settings and keep an active session while restarting to avoid being locked out.<\/p>\n\n\n\n
sudo sshd -T | less\n# If broken, revert quickly:\nsudo mv \/etc\/ssh\/sshd_config.bak.* \/etc\/ssh\/sshd_config\nsudo systemctl restart sshd || sudo systemctl restart ssh<\/code><\/pre>\n\n\n\n
Fix host key and known_hosts mismatches<\/h3>\n\n\n\n
If you reinstalled or rebuilt, the server\u2019s host<\/a> keys may change, causing client warnings. Verify fingerprints via console, then update known_hosts.<\/p>\n\n\n\n
# On server (list fingerprints)\nsudo ssh-keygen -l -f \/etc\/ssh\/ssh_host_ed25519_key.pub\nsudo ssh-keygen -l -f \/etc\/ssh\/ssh_host_rsa_key.pub\n\n# On client (remove old entry and reconnect)\nssh-keygen -R your-server.com\nssh user@your-server.com<\/code><\/pre>\n\n\n\n
Also Read: Fix phpMyAdmin on Linux Server<\/a><\/strong><\/p>\n\n\n\n
\n\n\n\n
SELinux or AppArmor Interference<\/h2>\n\n\n\n
SELinux port and context issues (RHEL\/Alma\/Rocky\/CentOS\/Fedora)<\/h3>\n\n\n\n
If you change the SSH port, allow it in SELinux. Also restore file contexts for user SSH directories.<\/p>\n\n\n\n
# Permit non-standard SSH port\nsudo semanage port -l | grep ssh\nsudo semanage port -a -t ssh_port_t -p tcp 2222 2>\/dev\/null || \\\nsudo semanage port -m -t ssh_port_t -p tcp 2222\n\n# Restore contexts\nsudo restorecon -Rv \/etc\/ssh \/home\/*\/.ssh\n\n# Temporary test (not a fix): set SELinux permissive\nsudo setenforce 0  # Remember to re-enable: setenforce 1<\/code><\/pre>\n\n\n\n
AppArmor profiles (Ubuntu\/Debian)<\/h3>\n\n\n\n
Verify the sshd AppArmor profile isn\u2019t denying required paths. Check dmesg or logs and adjust or temporarily set to complain mode only for testing.<\/p>\n\n\n\n
sudo aa-status\n# Switch to complain mode for testing\nsudo aa-complain \/etc\/apparmor.d\/usr.sbin.sshd<\/code><\/pre>\n\n\n\n
\n\n\n\n
Logs and Deep Diagnostics<\/h2>\n\n\n\n
Read server logs for SSH errors<\/h3>\n\n\n\n
Log messages often pinpoint the root cause: bad permissions, banned IP, config syntax, or missing keys.<\/p>\n\n\n\n
sudo journalctl -u ssh -e     # Debian\/Ubuntu\nsudo journalctl -u sshd -e    # RHEL\/Alma\/Rocky\nsudo tail -f \/var\/log\/auth.log \/var\/log\/secure<\/code><\/pre>\n\n\n\n
Temporarily increase logging for clarity<\/h3>\n\n\n\n
Set LogLevel DEBUG in sshd_config, restart, reproduce the issue, collect logs, then revert to INFO.<\/p>\n\n\n\n
sudo sed -i 's\/^#\\?LogLevel.*\/LogLevel DEBUG\/' \/etc\/ssh\/sshd_config\nsudo systemctl restart sshd || sudo systemctl restart ssh\n# After diagnosing:\nsudo sed -i 's\/^LogLevel.*\/LogLevel INFO\/' \/etc\/ssh\/sshd_config\nsudo systemctl restart sshd || sudo systemctl restart ssh<\/code><\/pre>\n\n\n\n
Use client side debug output<\/h3>\n\n\n\n
Run verbose mode to see key negotiation, auth methods, and disconnect reasons.<\/p>\n\n\n\n
ssh -vvv -p 22 user@your-server.com<\/code><\/pre>\n\n\n\n
\n\n\n\n
Emergency Access and Recovery Options<\/h2>\n\n\n\n
Use cloud provider console or KVM<\/h3>\n\n\n\n
Most providers offer a built in console you can open from the dashboard to regain terminal access even if SSH is down. Fix firewall rules, revert sshd_config, or restart the service from there.<\/p>\n\n\n\n
Boot into rescue\/single-user mode<\/h3>\n\n\n\n
In rescue mode, mount your root filesystem, chroot if needed, and repair SSH configuration<\/a>, users, keys, and firewall without the network actively blocking you.<\/p>\n\n\n\n
# Common recovery tasks\nsudo nano \/etc\/ssh\/sshd_config\nsudo sshd -t\nsudo systemctl restart sshd || sudo systemctl restart ssh\n# Regenerate host keys if missing\nsudo ssh-keygen -A\n# Reinstall server package if corrupted\nsudo apt-get update && sudo apt-get install --reinstall openssh-server\nsudo dnf reinstall -y openssh-server<\/code><\/pre>\n\n\n\n
Hardening SSH After You Fix It<\/h2>\n\n\n\n
Use key only authentication and disable passwords<\/h3>\n\n\n\n
Keys are safer and stop most brute force attacks. Set PubkeyAuthentication yes and PasswordAuthentication no, confirm access with a second session, then restart sshd.<\/p>\n\n\n\n
Optional: Change the SSH port (security by reduction of noise)<\/h2>\n\n\n\n
Moving from 22 to a high port reduces bot noise but isn\u2019t a true defense. If you change it, update SELinux, host firewall, and cloud security groups consistently.<\/p>\n\n\n\n
Add Fail2ban and 2FA for stronger protection<\/h3>\n\n\n\n
Enable Fail2ban to throttle brute force attempts. Consider 2FA (e.g., Google Authenticator, Duo) for privileged accounts. Always keep backups of working sshd_config files.<\/p>\n\n\n\n
Adopt configuration management and backups<\/h3>\n\n\n\n
Use Ansible, Puppet, or Chef to standardize SSH settings across servers. Store known good configs in version control. Managed VPS from YouStable can offload patching, SSH hardening, and 24\/7 incident response so you stay focused on your apps.<\/p>\n\n\n\n
\n\n\n\n
Common Error Patterns and How to Resolve Them<\/h2>\n\n\n\n
Error: Connection refused<\/h3>\n\n\n\n
Likely causes:<\/strong> sshd not running, wrong port, host firewall blocking, or cloud security group denies. Start sshd, open the port, and verify with ss -tlnp and nc\/nmap.<\/p>\n\n\n\n
Error: Connection timed out<\/h3>\n\n\n\n
Network path or firewall issue. Check provider firewalls, routing, security groups, and confirm public IP and DNS records are correct.<\/p>\n\n\n\n
Error: Permission denied (publickey)<\/h3>\n\n\n\n
Fix file permissions, ensure correct public key in authorized_keys, and confirm that PubkeyAuthentication is enabled. Use ssh -vvv to see which key is offered.<\/p>\n\n\n\n
Error: Remote host identification has changed<\/h3>\n\n\n\n
Host keys changed (e.g., rebuild). Verify fingerprints via console, then run ssh keygen -R hostname on the client and reconnect to trust the new key.<\/p>\n\n\n\n
\n\n\n\n
FAQs<\/h2>\n\n\n
\n
\n
\n
Why does SSH say \u201cConnection refused\u201d on my Linux server?<\/h3>\n
\n\n
Because sshd isn\u2019t listening or a firewall is blocking the port. Start\/enable sshd, confirm the listening port with ss -tlnp, and allow it in UFW\/firewalld and your cloud security groups. If you changed the port, connect with -p and adjust SELinux accordingly.<\/p>\n\n<\/div>\n<\/div>\n
\n
How do I fix \u201cPermission denied (publickey)\u201d?<\/h3>\n
\n\n
Place your public key into ~\/.ssh\/authorized_keys on the server, set correct permissions (700 on .ssh, 600 on authorized_keys), ensure ownership, and verify PubkeyAuthentication yes. Use ssh -vvv to confirm the correct key is being offered by your client.<\/p>\n\n<\/div>\n<\/div>\n
\n
How can I restart SSH safely without locking myself out?<\/h3>\n
\n\n
Keep an existing session open, back up sshd_config, run sshd -t to validate syntax, then restart sshd. Test a new connection in another terminal before closing the original session.<\/p>\n\n<\/div>\n<\/div>\n
\n
What if I changed the SSH port and now I can\u2019t connect?<\/h3>\n
\n\n
Open the new port in UFW\/firewalld and your cloud security groups, update SELinux with semanage port, verify sshd listens on the new port, and connect with ssh -p <port>. If stuck, use the provider console to revert the change.<\/p>\n\n<\/div>\n<\/div>\n
\n
Can I reinstall or regenerate SSH safely?<\/h3>\n
\n\n
Yes<\/strong>. Reinstall openssh server and regenerate host keys with ssh keygen -A from console or rescue mode. Expect a host key change warning on the client; verify fingerprints, remove the old entry with ssh-keygen -R, then reconnect.<\/p>\n\n<\/div>\n<\/div>\n<\/div>\n<\/div>","protected":false},"excerpt":{"rendered":"
To fix SSH on a Linux server, verify network reachability, confirm the SSH daemon (sshd) is running, ensure the correct […]<\/p>\n","protected":false},"author":21,"featured_media":19050,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[350],"tags":[],"class_list":["post-13622","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-knowledgebase"],"acf":[],"featured_image_src":"https:\/\/www.youstable.com\/blog\/wp-content\/uploads\/2025\/12\/How-to-Fix-SSH-on-Linux-Server.jpg","author_info":{"display_name":"Sanjeet Chauhan","author_link":"https:\/\/www.youstable.com\/blog\/author\/sanjeet"},"_links":{"self":[{"href":"https:\/\/www.youstable.com\/blog\/wp-json\/wp\/v2\/posts\/13622","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.youstable.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.youstable.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.youstable.com\/blog\/wp-json\/wp\/v2\/users\/21"}],"replies":[{"embeddable":true,"href":"https:\/\/www.youstable.com\/blog\/wp-json\/wp\/v2\/comments?post=13622"}],"version-history":[{"count":8,"href":"https:\/\/www.youstable.com\/blog\/wp-json\/wp\/v2\/posts\/13622\/revisions"}],"predecessor-version":[{"id":19439,"href":"https:\/\/www.youstable.com\/blog\/wp-json\/wp\/v2\/posts\/13622\/revisions\/19439"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.youstable.com\/blog\/wp-json\/wp\/v2\/media\/19050"}],"wp:attachment":[{"href":"https:\/\/www.youstable.com\/blog\/wp-json\/wp\/v2\/media?parent=13622"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.youstable.com\/blog\/wp-json\/wp\/v2\/categories?post=13622"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.youstable.com\/blog\/wp-json\/wp\/v2\/tags?post=13622"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}