Linux Permission Denied Error Fix: SSH Key, Sudo, and chmod

1. SSH Private Key Permissions Are Wrong (Most Common Cause)

You try to SSH into a server and get Permission denied (publickey). I've seen this trip up sysadmins for years. Here's the deal: OpenSSH is paranoid about your private key's permissions. If it's readable by anyone except you, it refuses to use it. The fix is simple.

1. Check your private key's permissions with ls -la ~/.ssh/id_rsa. If it shows -rw------- you're good. If it shows -rw-r--r-- or anything else, fix it.
2. Run chmod 600 ~/.ssh/id_rsa. That sets it to read/write for the owner only. No group, no others.
3. Also check ~/.ssh/config if you use one — any IdentityFile paths must point to files with 600 permissions.

But wait — the .ssh directory itself also matters. If it's world-writable or owned by the wrong user, OpenSSH nopes out too. Run chmod 700 ~/.ssh. This locks the directory so only you can read or write it.

Real-world scenario: You copy a key from a backup tarball. The tarball preserves restrictive permissions? Wrong — it might expand them to 644. Always verify after a copy.

2. Sudoers File Has a Permission Error

Another flavor of Permission denied pops up when you try sudo commands and get sudo: /etc/sudoers is world writable or sudo: no valid sudoers sources found. This is a different beast from SSH keys, but it's just as common.

The file /etc/sudoers must have permissions 0440 (owner read, group read, no others). If someone accidentally chmods it to 644 or 777, sudo panics.

1. Boot into single-user mode or use a live CD to fix this. On most systems, you can reboot, hold Shift for GRUB, select recovery mode, then root shell.
2. Mount the root filesystem as read-write: mount -o remount,rw /.
3. Run chmod 0440 /etc/sudoers.

Don't edit sudoers with a regular text editor — use visudo. It validates syntax before saving. I've seen admins lock themselves out by typing sudo nano /etc/sudoers and making a typo. Visudo does a syntax check and won't save broken config.

Another gotcha: files in /etc/sudoers.d/ must also be 0440. If you add a custom sudo rule and the file isn't 0440, sudo ignores it entirely. Check with ls -la /etc/sudoers.d/.

3. Filesystem Mounted with noexec or nosuid

This one's sneakier. You have correct permissions but still get Permission denied when trying to run a script or binary. Usually it's a partition mounted with noexec.

Check mounts with mount | grep noexec. Common culprits: /tmp, /var/tmp, /home, and external drives. If you compiled a binary or copied a script to /tmp and try to run it, noexec blocks execution.

1. Move the file to a partition without noexec, like /usr/local/bin.
2. Or remount the partition with exec: sudo mount -o remount,exec /tmp. This is temporary unless you edit /etc/fstab.

I once spent an hour debugging why a Python script wouldn't run from /tmp. The script had 755 permissions, correct shebang, everything. The answer? /tmp was noexec,nodev,nosuid. Moved it to /opt and it worked instantly.

Also check for nosuid — if you need setuid binaries (like passwd or ping), they won't work on a nosuid partition either.

Quick-Reference Summary Table

If none of these help, check dmesg and journalctl -xe for more clues. Sometimes SELinux or AppArmor blocks you — but that's a separate issue for another day. Start with these three fixes, and you'll resolve 90% of Linux permission denied errors.