Consultation

Best Practices for Secure SSH Login on Immich Server Deployments

Image
By:
  • 0 Comments

Immich is a lovely photo vault. It stores family trips, pet chaos, food pics, and tiny memories. That means your server is not just “a box.” It is a treasure chest. So your SSH login needs a strong lock, a quiet alarm, and maybe a digital guard dog.

TLDR: Use SSH keys, not passwords. Disable root login and only allow trusted users. Protect SSH with a firewall, updates, and tools like Fail2ban. If possible, put SSH behind a VPN so the whole internet cannot poke it.

Why SSH Security Matters for Immich

Immich is often deployed on a home server, VPS, or small cloud machine. It usually runs with Docker. You may use SSH to update containers, edit config files, check logs, or restart services.

This makes SSH very powerful. If an attacker gets SSH access, they may control the host. Then they may reach your Immich files, database, backups, and secrets. That is bad. Very bad. Like “accidentally shared all holiday photos with a raccoon” bad.

The good news is simple. SSH can be very safe. You just need a few good habits.

Use SSH Keys, Not Passwords

Passwords are easy to guess, steal, reuse, or type into the wrong place. SSH keys are better. They use a public key and a private key. The public key lives on the server. The private key stays on your laptop.

Think of it like a magic door. The door knows your public badge. Your laptop holds the secret badge. No secret badge, no entry.

Create a modern key on your own computer:

ssh-keygen -t ed25519 -a 100 -C "immich admin key"

Use a strong passphrase. Yes, a passphrase. Not pizza123. Use something long and weird. For example, a sentence with random words.

Then copy the key to your server:

ssh-copy-id youruser@yourserver

After testing key login, disable password login. Edit the SSH config:

sudo nano /etc/ssh/sshd_config

Set these options:

PasswordAuthentication no
PubkeyAuthentication yes

Then restart SSH:

sudo systemctl restart ssh

Important: Keep one SSH session open while testing a new one. Do not lock yourself out. That is a classic admin facepalm.

Disable Root Login

The root user is the super boss. Attackers love root because the username is known. They only need the password or key. Do not make their day easy.

Use a normal user instead. Give that user sudo rights when needed. Then disable root SSH login.

In /etc/ssh/sshd_config, set:

PermitRootLogin no

Restart SSH again:

sudo systemctl restart ssh

Now you log in as your normal user. When you need admin power, use:

sudo command

This creates a small speed bump. Small speed bumps matter. Security is often many small speed bumps stacked together.

Allow Only the Users You Trust

Your Immich server may have several Linux users. Not all of them need SSH. Be strict. Keep the guest list short.

Add this line to your SSH config:

AllowUsers youruser backupadmin

Only those users can log in through SSH. Everyone else gets the digital bouncer treatment.

You can also use groups:

AllowGroups sshusers

Then add trusted users to that group:

sudo groupadd sshusers
sudo usermod -aG sshusers youruser

This is neat when you manage more than one admin.

Use a Firewall

A firewall decides who may knock on the door. If your SSH port is open to the world, bots will find it. They are fast. They are boring. They never sleep.

On Ubuntu or Debian, ufw is simple:

sudo ufw allow OpenSSH
sudo ufw enable
sudo ufw status

If you know your home IP address, allow only that address:

sudo ufw allow from 203.0.113.55 to any port 22

Replace the example IP with your real IP. If your IP changes often, this can be annoying. In that case, a VPN is better.

For cloud providers, also check the cloud firewall. Many people configure the server firewall and forget the provider firewall. That is like locking the front door while the garage is wide open.

Put SSH Behind a VPN

This is one of the best moves. Do not expose SSH to the public internet at all. Use a VPN like WireGuard, Tailscale, or ZeroTier. Then SSH is only reachable from your private network.

This makes your server quieter. Bots cannot brute force what they cannot see.

A common setup looks like this:

  • Immich web access: Public through HTTPS, if needed.
  • SSH access: Private through VPN only.
  • Database access: Local only. Never public.
  • Docker socket: Local only. Treat it like root access.

This is a clean separation. Your photo app can serve users. Your admin door stays hidden.

Install Fail2ban or SSHGuard

Fail2ban watches login failures. If one IP fails too many times, it gets blocked. It is like a tiny robot saying, “Nope. Go away.”

Install it:

sudo apt update
sudo apt install fail2ban

Then enable it:

sudo systemctl enable fail2ban
sudo systemctl start fail2ban

Fail2ban works well with SSH. It is not a replacement for keys or VPN. It is an extra trap. Extra traps are good.

Change the SSH Port, But Do Not Worship It

You can move SSH from port 22 to another port. This can reduce random bot noise. It is not real security by itself. It is more like moving the doorbell.

To change it, edit:

sudo nano /etc/ssh/sshd_config

Set a port:

Port 2222

Allow the new port in your firewall before restarting SSH:

sudo ufw allow 2222/tcp
sudo systemctl restart ssh

Then connect with:

ssh -p 2222 youruser@yourserver

Again, keep an old session open while testing. Your future self will thank you.

Keep the Server Updated

Security updates are boring. Boring is beautiful. A patched server is a happy server.

Update your host often:

sudo apt update
sudo apt upgrade

Also update Docker and Immich carefully. Read release notes. Back up first. Then update.

For Immich, this often means updating your Docker Compose stack. A typical flow may be:

docker compose pull
docker compose down
docker compose up -d

Use the commands that match your deployment. Do not blindly paste random commands from the web. The web contains both wisdom and bananas.

Protect Your SSH Private Key

Your private key is powerful. Guard it well.

  • Store it only on trusted devices.
  • Use a strong passphrase.
  • Do not email it to yourself.
  • Do not put it in Git.
  • Do not upload it to your Immich server.
  • Back it up in a secure place.

If your laptop is lost, remove that key from the server. Open:

~/.ssh/authorized_keys

Delete the matching public key line. Then save the file.

You can also use one key per device. That makes cleanup easy. Lost laptop? Remove only that laptop key.

Use Two Factor Authentication for Extra Armor

SSH can use two factor authentication. This means you need a key and a second proof. The second proof may be a code from an app or a hardware security key.

This is stronger, but it adds complexity. Test it carefully. Keep recovery access. Do not make your server so secure that even you cannot enter.

For many home Immich deployments, SSH keys plus VPN are already very strong. For public servers or shared admin teams, two factor is worth considering.

Limit Sudo Power

SSH login is only step one. After login, sudo decides what users can do. Do not give full admin power to everyone.

For your main admin user, full sudo may be fine. For a backup user, limited access is better. For example, a backup user may only need to read backup folders and run backup scripts.

Use the principle of least privilege. That means each user gets only the power they need. No more. No crown for the intern.

Watch the Logs

Logs tell stories. Some stories are boring. Some stories are scary. Read them sometimes.

Check SSH login attempts:

sudo journalctl -u ssh

Or on some systems:

sudo tail -f /var/log/auth.log

Look for strange usernames, repeated failures, or logins from unknown locations. If you see weird activity, rotate keys, check users, and review firewall rules.

Separate Immich Secrets from SSH Access

Immich uses configuration files, environment variables, database passwords, API keys, and storage paths. Keep those safe.

Do not put secrets in public repos. Do not copy them into chat apps. Do not leave backup files world readable.

Check permissions on your Immich folder:

ls -la

Use strict ownership. Only admin users should edit Compose files and .env files.

Also be careful with the Docker group. A user in the docker group can often gain root-like control. Do not add random users to it.

Back Up Before You Tinker

Security changes can break access. Backups save the day. Before major SSH or Immich changes, make sure you have backups.

Back up these items:

  • Your Immich upload library.
  • Your database.
  • Your Docker Compose files.
  • Your .env file.
  • Your SSH config.
  • Your list of authorized keys.

Test restores too. A backup that cannot restore is just a decorative file.

A Simple Secure SSH Checklist

Here is a quick checklist for an Immich server:

  • Create a normal admin user.
  • Use Ed25519 SSH keys.
  • Add a passphrase to your private key.
  • Disable password login.
  • Disable root login.
  • Allow only trusted users.
  • Use a firewall.
  • Put SSH behind a VPN if possible.
  • Install Fail2ban or a similar tool.
  • Keep the host and containers updated.
  • Protect Immich secrets and Docker access.
  • Review logs now and then.

Final Thoughts

Secure SSH is not magic. It is a set of simple habits. Use keys. Hide the admin door. Patch often. Watch for trouble. Keep backups.

Your Immich server holds memories. Treat it like a tiny museum. Give it locks, guards, and a calm plan. Then you can enjoy your photos without worrying that a bot named “admin123” is rattling the door at 3 a.m.

Register now and start getting backlinks for free!

Register