September 11, 2026
11 min read
By Kokil Thapa | Last reviewed: September 2026
Ubuntu SSH server setup is the first task on almost every fresh VPS I touch for client work. Without SSH, you cannot deploy Laravel apps, tune Apache, or run backups from your laptop. This guide walks through installing OpenSSH on Ubuntu 22.04 or 24.04, hardening sshd_config, and fixing the connection errors that waste hours on a Sunday night. If you are preparing a box for PHP or a full Ubuntu server for PHP apps, start here before anything else.
Quick answer: Ubuntu SSH server setup means installing the
openssh-server package, enabling the ssh service, opening port 22 in UFW, creating key-based logins, and hardening /etc/ssh/sshd_config before exposing the host to the internet.What is Ubuntu SSH server setup and why does it matter?
SSH (Secure Shell) gives you an encrypted terminal session on a remote Linux machine. The server side runs sshd, the OpenSSH daemon. Your laptop runs the ssh client. Every command, file transfer, and Git deploy over SSH travels inside a TLS-like tunnel.
On production boxes I maintain with Deployer 7 and GitLab CI, SSH is the front door. A misconfigured door invites brute-force bots within minutes. A properly hardened one stays quiet for years. That is why Ubuntu server setup always starts with SSH, not with Nginx or MySQL.
SSH also powers scp, sftp, and rsync. Ansible playbooks and GitLab CI deploy jobs depend on the same daemon. Treat SSH as infrastructure, not a convenience feature you enable and forget.
How do you install and enable OpenSSH on Ubuntu?
Ubuntu Server images usually ship with the client preinstalled. The server package is separate. Install it on a fresh VPS before you close the provider's web console.
Step 1: Update packages and install openssh-server
sudo apt update
sudo apt install openssh-server -yOn Ubuntu 24.04 LTS, this pulls OpenSSH from the official repositories. Verify the service is running:
sudo systemctl status ssh
sudo systemctl enable sshExpected output shows active (running). Enable ensures SSH starts after a reboot. I have seen hosts lose remote access after kernel updates because someone forgot this step.
Step 2: Confirm the listening port
sudo ss -tlnp | grep sshdDefault port is 22. You can change it later in /etc/ssh/sshd_config. If you do, update UFW and your SSH client config at the same time.
Step 3: Open the firewall
UFW is the standard firewall on Ubuntu server images. Allow SSH before enabling UFW, or you lock yourself out:
sudo ufw allow OpenSSH
sudo ufw enable
sudo ufw status verboseFor a custom port such as 2222, use sudo ufw allow 2222/tcp instead. Pair this with the broader checklist in our initial Ubuntu server setup guide.
Step 4: Create a non-root sudo user
Logging in as root over SSH is convenient and risky. Create a deploy user first:
sudo adduser deploy
sudo usermod -aG sudo deployDetailed user and group patterns live in the Ubuntu user management guide. For sister sites on shared EC2 infrastructure, every site gets its own deploy user with a restricted sudoers file.
How do you set up SSH key authentication on Ubuntu?
Password logins get hammered by bots. Key-based auth removes that attack surface. Generate a key pair on your local machine, not on the server.
Generate keys on your workstation
ssh-keygen -t ed25519 -C "deploy@your-laptop" -f ~/.ssh/id_ed25519_deployEd25519 keys are short, fast, and widely supported in 2026. Use RSA 4096 only if an old system demands it. Protect the private key with a passphrase. A strong passphrase generator helps if you rotate credentials regularly.
Copy the public key to the server
ssh-copy-id -i ~/.ssh/id_ed25519_deploy.pub deploy@YOUR_SERVER_IPManual method if ssh-copy-id is unavailable:
mkdir -p ~/.ssh
chmod 700 ~/.ssh
echo "YOUR_PUBLIC_KEY" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keysOwnership must match the login user. Wrong permissions cause silent rejections. See the dedicated SSH key-only auth setup article for a full walkthrough.
Test before you disable passwords
Open a second terminal. Connect with your key:
ssh -i ~/.ssh/id_ed25519_deploy deploy@YOUR_SERVER_IPOnly after this works should you edit sshd_config. I keep the provider's web console open during every hardening session. One typo has cost me a support ticket on a Friday evening.
Which sshd_config settings should you change for production?
The main config file lives at /etc/ssh/sshd_config. Ubuntu also reads drop-in files from /etc/ssh/sshd_config.d/. Prefer drop-ins for clarity:
sudo nano /etc/ssh/sshd_config.d/99-hardening.confAdd these production-oriented settings:
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
LoginGraceTime 30
AllowUsers deploy
ClientAliveInterval 300
ClientAliveCountMax 2Validate syntax before reload:
sudo sshd -t
sudo systemctl reload sshNever use restart during a live session unless you must. reload applies config without dropping existing connections. Official reference: the Ubuntu sshd_config man page.
| Setting | Dev / staging | Production | Why it matters |
|---|---|---|---|
PermitRootLogin | prohibit-password | no | Root is a predictable target for bots |
PasswordAuthentication | yes (temporary) | no | Stops brute-force password attacks |
Port | 22 | custom (optional) | Reduces noise, not real security alone |
AllowUsers | omitted | deploy | Limits who can authenticate at all |
MaxAuthTries | 6 | 3 | Closes failed attempts faster |
Changing the port cuts log noise but does not replace keys and firewall rules. Combine it with fail2ban on Ubuntu for automatic IP bans after repeated failures.
Optional: client-side config for daily use
Store connection shortcuts in ~/.ssh/config on your laptop:
Host prod-law-portal
HostName 203.0.113.10
User deploy
IdentityFile ~/.ssh/id_ed25519_deploy
Port 22Then connect with ssh prod-law-portal. This saves time when you juggle multiple client servers across Nepal and abroad.
How do you harden SSH beyond basic config?
Config changes are the baseline. Layer these extras before you host client data or payment flows.
- Install fail2ban — bans IPs after failed SSH attempts. Documented in our server hardening guide.
- Keep packages current —
sudo apt update && sudo apt upgrade openssh-serverpatches CVEs quickly. - Restrict source IPs — if your office IP is stable, allow SSH only from that range in UFW.
- Use a bastion or VPN — for high-value systems, SSH should not face the public internet directly.
- Audit auth logs —
sudo journalctl -u ssh -n 50shows recent login attempts.
The broader picture sits in the Ubuntu security hardening guide. For ongoing patches, follow the Ubuntu security updates guide.
On legal-tech portals and eCommerce backends I maintain, SSH access is limited to named deploy users. GitLab CI uses a dedicated key with forced command restrictions where possible. That pattern aligns with Linux system administration work I deliver for Nepal clients who need hands-on server care without hiring a full-time ops engineer.
Two-factor authentication (optional)
Google Authenticator or hardware keys add a second factor on top of SSH keys. Install libpam-google-authenticator and configure PAM. This is overkill for a small brochure site but sensible for databases holding sensitive documents.
How do you troubleshoot common Ubuntu SSH connection errors?
SSH failures usually fall into a short list. Work through them in order.
Connection refused
The daemon is not running or the firewall blocks the port. Check:
sudo systemctl status ssh
sudo ufw status
sudo ss -tlnp | grep sshStart the service with sudo systemctl start ssh if it is stopped.
Permission denied (publickey)
Wrong key, wrong user, or bad file permissions on the server. Fix ownership:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R deploy:deploy ~/.sshRun the client in verbose mode to see what the server rejects:
ssh -vvv deploy@YOUR_SERVER_IPConnection timed out
Usually a cloud security group or network ACL blocks port 22. Check your VPS provider's firewall panel in addition to UFW. I have lost an hour to AWS security groups while UFW looked perfect.
Locked out after a bad config edit
Use your VPS provider's web console (VNC or serial). Fix sshd_config, run sudo sshd -t, then reload. Keep a backup:
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bakDocument the rollback path in your server backup strategy so config files restore with the rest of the stack.
How does SSH fit into a full Ubuntu web stack?
SSH is step one. Step two is the application layer. Typical next installs on boxes I configure:
- Install Nginx on Ubuntu as the web front end
- Install PHP on Ubuntu for Laravel 12 or 13 apps (PHP 8.3+ required)
- Install MySQL on Ubuntu for relational data
- Server monitoring for uptime alerts
Sister legal-tech sites on shared EC2—such as flows documented under Notary Kathmandu—share Deployer 7 pipelines that depend on reliable SSH from GitLab runners. Break SSH and every deploy stops.
If you prefer infrastructure-as-code over manual steps, the Ansible automation guide codifies the same hardening. For hosting selection before you even get SSH access, see domain registration and hosting in Nepal.
Official Ubuntu documentation for the OpenSSH server package is at ubuntu.com/server/docs/service-openssh. The upstream project overview lives at openssh.com.
Key Takeaways
- Install
openssh-server, enable the service, and allow SSH in UFW before you close the provider console. - Generate ed25519 keys locally, copy them with
ssh-copy-id, and test login before disabling passwords. - Harden via
/etc/ssh/sshd_config.d/: no root login, no password auth,AllowUsersset, thensshd -tand reload. - Layer fail2ban, security updates, and optional IP restrictions for production Laravel and WordPress hosts.
- Diagnose failures with
systemctl status ssh, UFW rules, cloud security groups, andssh -vvv. - Keep provider console access open until key auth is confirmed—lockouts are common and fixable but stressful.
People Also Ask
Is OpenSSH preinstalled on Ubuntu Server?
Ubuntu Server includes the SSH client by default. The server daemon requires the openssh-server package. Desktop editions may omit it entirely. Run dpkg -l openssh-server to check.
Should I change the default SSH port on Ubuntu?
Changing port 22 reduces log noise from automated scanners. It does not stop targeted attacks. Always combine a custom port with key-only auth, UFW rules, and fail2ban for real protection.
Can I use SSH on Ubuntu without a static IP?
Yes. Connect with your VPS public IP or a DNS A record. Dynamic home IPs work for outbound SSH client connections. For inbound access to a home server, use a dynamic DNS service or a reverse tunnel.
What is the difference between ssh restart and reload?
systemctl reload ssh applies config changes without dropping active sessions. restart stops and starts the daemon, which can disconnect your current shell. Use reload after validated config edits.
Next steps for your Ubuntu SSH server setup
Ubuntu SSH server setup takes twenty focused minutes on a fresh VPS. Install OpenSSH, open the firewall, deploy keys, harden sshd_config, and add fail2ban. That foundation supports everything else—PHP-FPM, MySQL, Deployer releases, and nightly backups.
If you want someone to harden servers, wire CI/CD, and keep them patched, review our support and maintenance services or contact us with your stack details. Solid SSH today prevents emergency console logins tomorrow.
Frequently Asked Questions
Ubuntu SSH server setup means installing the openssh-server package, enabling the ssh service, opening port 22 in UFW, creating key-based logins, and hardening /etc/ssh/sshd_config before exposing the host to the internet.
On Ubuntu 22.04 or 24.04 LTS, run sudo apt update followed by sudo apt install openssh-server -y. Verify the daemon is active with sudo systemctl status ssh and ensure it survives reboots with sudo systemctl enable ssh. Confirm sshd is listening on port 22 using sudo ss -tlnp | grep sshd before closing the provider web console. I have seen hosts lose remote access after kernel updates because someone installed OpenSSH but forgot to enable the service at boot.
Ubuntu Server includes the SSH client by default. The server daemon requires the separate openssh-server package. Desktop editions may omit it entirely. Run dpkg -l openssh-server to check.
Generate ed25519 keys on your local workstation with ssh-keygen -t ed25519, never on the server. Copy the public key with ssh-copy-id deploy@YOUR_SERVER_IP or manually append it to ~/.ssh/authorized_keys. Set chmod 700 on ~/.ssh and chmod 600 on authorized_keys, with ownership matching the login user. Open a second terminal and test ssh -i ~/.ssh/id_ed25519_deploy deploy@YOUR_SERVER_IP before disabling passwords in sshd_config. I keep the provider web console open during every hardening session because wrong permissions cause silent rejections.
Prefer drop-in files at /etc/ssh/sshd_config.d/99-hardening.conf rather than editing the main file directly. Set PermitRootLogin no, PasswordAuthentication no, PubkeyAuthentication yes, MaxAuthTries 3, LoginGraceTime 30, AllowUsers deploy, ClientAliveInterval 300, and ClientAliveCountMax 2. Validate syntax with sudo sshd -t, then apply changes with sudo systemctl reload ssh. On production boxes I maintain with Deployer 7 and GitLab CI, password auth stays disabled and only named deploy users can authenticate at all.
Changing port 22 reduces log noise from automated scanners. It does not stop targeted attacks. Always combine a custom port with key-only auth, UFW rules, and fail2ban.
Allow SSH before enabling UFW or you lock yourself out. Run sudo ufw allow OpenSSH, then sudo ufw enable and confirm with sudo ufw status verbose. For a custom port such as 2222, use sudo ufw allow 2222/tcp and update sshd_config plus your local ~/.ssh/config at the same time. Check your VPS provider firewall panel as well because cloud security groups can block port 22 even when UFW looks correct. I have lost an hour to AWS security groups while UFW appeared perfect on the server itself.
Connection refused means the daemon is not running or a firewall blocks the port. Check sudo systemctl status ssh, sudo ufw status, and sudo ss -tlnp | grep sshd. Start the service with sudo systemctl start ssh if it is stopped. Also verify your cloud provider security group or network ACL allows inbound traffic on the SSH port. This is the first failure mode I work through when Ubuntu SSH server setup works locally on the box but remote connections fail from a laptop.
Wrong key, wrong user, or bad file permissions on the server cause this error. Fix ownership with chmod 700 ~/.ssh, chmod 600 ~/.ssh/authorized_keys, and chown -R deploy:deploy ~/.ssh. Run the client in verbose mode with ssh -vvv deploy@YOUR_SERVER_IP to see exactly what sshd rejects. Silent rejections from incorrect authorized_keys permissions are common when keys are pasted manually instead of copied with ssh-copy-id during first-time Ubuntu SSH server setup.
systemctl reload ssh applies config changes without dropping active sessions, which is why the article recommends reload after sudo sshd -t validates your hardening edits. systemctl restart ssh stops and starts the daemon entirely, disconnecting your current shell mid-session. Use reload during live hardening on a box you are actively connected to. Only restart when troubleshooting a daemon that failed to start or when reload does not pick up a change you expected.
Install fail2ban to ban IPs after repeated failed SSH attempts. Keep openssh-server patched with sudo apt update and sudo apt upgrade because OpenSSH CVEs get fixed quickly. Restrict source IPs in UFW if your office IP is stable. For high-value systems, put SSH behind a bastion or VPN rather than exposing it directly to the internet. Audit recent logins with sudo journalctl -u ssh -n 50. Optional two-factor auth via libpam-google-authenticator adds a second factor on top of keys for systems holding sensitive documents.
Yes. Connect to your VPS using its public IP or a DNS A record pointing at it. Dynamic home IPs work fine for outbound SSH client connections from your laptop. For inbound access to a home server, you need a dynamic DNS service or a reverse tunnel because firewalls and routing expect a reachable address. On client VPS work, the public IP from the hosting panel is usually sufficient without any additional DDNS setup.
Use your VPS provider web console through VNC or serial access to regain entry. Fix sshd_config, validate syntax with sudo sshd -t, then reload the service. Keep a backup with sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak before hardening sessions. Document the rollback path in your server backup strategy so config files restore with the rest of the stack. Lockouts after typos in PermitRootLogin or PasswordAuthentication settings are common and fixable but stressful without console access.
Logging in as root over SSH is convenient and risky because root is a predictable target for automated bots. Create a deploy user with sudo adduser deploy and sudo usermod -aG sudo deploy, then set AllowUsers deploy alongside PermitRootLogin no in sshd_config. For sister sites on shared EC2 infrastructure, every site gets its own deploy user with a restricted sudoers file. Named deploy users also align with GitLab CI and Deployer 7 pipelines that depend on reliable non-root SSH access for releases.
Install openssh-server, open the firewall with UFW, create a non-root sudo user, set up and test key-based logins, then harden sshd_config. Never skip the key test step from a second terminal before disabling password authentication. Keep the provider console open until key auth is confirmed. After SSH is solid, proceed to Nginx, PHP 8.3 or higher for Laravel 12 or 13 apps, and MySQL. Break SSH and every Deployer release, GitLab CI deploy job, and nightly backup stops.
0 Comments
Leave a comment
Your email is not published. Comments appear once they have been read. Sign in to have your details filled in.
