I lost SSH access to my home server after accidentally setting /home/user to 777 – how I restored it with a live USB

I hit a wall yesterday when I accidentally set /home/user to 777 and lost SSH access.
The server was a 2026‑era Debian‑based homebox running systemd‑managed services.
SSH refuses to log in if any file under the user’s home directory is writable by others, so the key‑based login failed immediately.
The only way to fix it was to boot from a live USB, mount the root filesystem, and restore the correct ownership and permissions.

Why 777 broke SSH

OpenSSH checks the permissions of the user’s home directory, .ssh, and the private key files.
If any of those are group‑ or world‑writable, the daemon exits with:

Authentication refused: bad ownership or modes for directory /home/user

The check is hard‑coded in the SSH source (see the check_dir function in authfile.c on kernel.org).
So a single chmod 777 /home/user turns a perfectly good login into a hard lockout.

Quick diagnosis

If you’re stuck, the first thing to do is confirm that the SSH daemon is running and that the key files exist:

systemctl status sshd
ls -ld /home/user
ls -l /home/user/.ssh/id_rsa

If the directory shows drwxrwxrwx and the key is world‑readable, you’re in trouble.
You’ll need root access to fix it, which is why a live USB is the simplest path.

Preparing the live USB

Create a bootable USB with a recent Debian or Ubuntu ISO.
I used dd on a Linux host:

sudo dd if=debian-12.5.0-amd64-netinst.iso of=/dev/sdX bs=4M status=progress && sync

Boot into the live environment.
In BIOS/UEFI, disable Secure Boot if it blocks the USB.
The live session gives you a root shell without needing a password.
Identify the root partition.
On my system it was /dev/sda2:
```
lsblk -f
```

Mounting the system

Mount the root filesystem and bind‑mount necessary virtual filesystems for a chroot:

mkdir /mnt/root
mount /dev/sda2 /mnt/root
mount --bind /dev /mnt/root/dev
mount --bind /proc /mnt/root/proc
mount --bind /sys /mnt/root/sys

If you’re using LVM or encrypted partitions, adjust the mount commands accordingly.
For LVM, use vgchange -ay before mounting; for encryption, cryptsetup open first.

Resetting ownership and permissions

Now that the system is mounted, we can chroot into it:

chroot /mnt/root /bin/bash

Inside the chroot, run:

# Restore ownership
chown -R user:user /home/user

# Reset permissions
chmod 700 /home/user
chmod 700 /home/user/.ssh
chmod 600 /home/user/.ssh/id_rsa
chmod 644 /home/user/.ssh/id_rsa.pub

If you’re unsure of the exact ownership, you can look at /etc/passwd:

grep '^user:' /etc/passwd

The output will show the UID/GID; use those if you prefer numeric values.

Trade‑off: chroot vs. systemd‑nspawn

Using chroot is quick but bypasses systemd’s init system.
If you prefer a more “real” environment, systemd-nspawn can start a container that behaves like a full system:

systemd-nspawn -D /mnt/root

Inside the container, the same chown/chmod commands apply.
The container approach is safer on systems with SELinux or AppArmor, as it respects those policies.

Rebooting

Exit the chroot or container, unmount everything, and reboot:

exit          # leave chroot
umount -R /mnt/root
reboot

After the reboot, SSH should accept the key again.
Test from another machine:

ssh -i ~/.ssh/id_rsa [email protected]

If you still see permission errors, double‑check the permissions of /home/user/.ssh and its contents.

Post‑repair checks

Verify SSH configuration:
```
grep -E 'PermitRootLogin|PasswordAuthentication' /etc/ssh/sshd_config
```
Make sure you’re not inadvertently allowing password logins.
Audit the home directory:
```
find /home/user -perm -002 -print
```
This lists any files that are group‑writable.
Ideally, nothing should appear.

Check the audit log (if enabled):

journalctl -u sshd | grep "Authentication refused"

Lessons learned

What went wrong	Prevention
`chmod 777 /home/user`	Use `chmod 700` for home dirs; avoid 777 unless you know the implications.
No backup of permissions	Keep a simple script that backs up `/etc/passwd` and `/etc/group` before major changes.
Relying on SSH key only	Enable `PasswordAuthentication no` and `PermitRootLogin no` to reduce attack surface.
Forgetting to unmount	Always double‑check mounts before rebooting to avoid data corruption.

Security‑friendly habits

Use umask 077 for new files in the home directory.
This ensures that newly created files are not world‑readable by default.
Enable StrictModes yes in sshd_config (default).
It forces the daemon to check permissions on every login attempt.
Regularly audit: sudo pam-auth-update can add pam_unix.so checks for permissions.

Quick checklist for future mishaps

Verify permissions before changing anything: ls -ld /home/user.
Keep a minimal backup of /etc/passwd and /etc/group.
Use chmod 700 for home directories and .ssh.
Test SSH key login from a different machine after changes.
Keep the live USB handy for emergency repairs.