File Permissions
File Permissions & Disable Root Login
After configuring SSH access for the new user, the next steps are to:
- Fix the permissions of
authorized_keys - Inspect authentication attempts
- Disable direct root login
- Restart the SSH daemon
- Verify that root login is actually disabled
A. Why File Permissions Matter for SSH
SSH is very strict about file permissions.
The authorized_keys file contains the public keys that are allowed to authenticate as a user, so its permissions should not allow unauthorized users to modify it.
The course uses 644, but a more restrictive and commonly recommended SSH setup is:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod means change file mode bits.
It changes who can:
- read a file
- write to a file
- execute a file
B. Understanding r, w, and x
Linux file permissions use three basic permissions:
r → read
w → write
x → execute
You can inspect permissions with:
ls -la
For example:
-rw-r--r--
The permission groups represent different levels of access.
The course does not go deeply into the complete permission model yet, but the important point here is that chmod changes these access permissions.
C. What Do 700 and 600 Mean?
Set the SSH directory and key file permissions with:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
The directory permission 700 means:
Owner → read + write + enter the directory
Group → no access
Others → no access
The file permission 600 means:
Owner → read + write
Group → no access
Others → no access
The important idea in this section is:
Only the owner should be able to modify
authorized_keys.
The file does not need execute permission because authorized_keys is not a script or executable program.
authorized_keys
├── Read ✓
├── Write ✓ for owner
└── Execute ✗
The exact numeric permission system will be covered in more detail later. For now, the important point is that no other local user can access the SSH directory or modify authorized_keys.
D. Inspect Authentication Logs
Before disabling root login, the course demonstrates why server security matters by looking at the authentication log.
sudo cat /var/log/auth.log
Logs are stored under:
/var/log/
The authentication log records information about authentication activity, including attempts to connect to the server.
Conceptually:
Even a brand-new server that has barely been online may already receive login attempts.
You may see attempts using:
- common usernames
root- common passwords
- common ports
- different exploits
The key lesson is:
The moment a public server comes online, automated systems may begin trying to connect to it.
This is why the course puts significant emphasis on server security.
E. Why Disable Root Login?
root has unrestricted access to the operating system.
If someone successfully logs in directly as root:
That is especially dangerous because attackers commonly try usernames such as:
root
admin
...
The approach used in the course is therefore:
At this point, we no longer need to SSH directly into the server as root.
Instead:
ssh <username>@<server-ip>
Then, when elevated permissions are required:
sudo <command>
Root still exists on the system; we are simply preventing direct SSH login as root.
F. Verify the New User Before Disabling Root
This order is extremely important.
Before disabling root login, make sure the new user can successfully:
1. Log in through SSH
2. Authenticate using the SSH key
3. Use sudo
The safe sequence is:
If you disable root login before confirming the new user works, you could lose access to the server.
Do not change the SSH configuration before completing the previous steps.
G. Open the SSH Configuration
The SSH daemon has its own configuration file.
The course opens it with:
sudo vi /etc/ssh/sshd_config
Breaking this path down:
/etc/
└── ssh/
└── sshd_config
sshd refers to the SSH daemon.
A daemon is a process that runs in the background and provides a system service.
In this case:
sshd
→ listens for incoming SSH connections
Because /etc contains system configuration, editing these files generally requires elevated permissions.
That is why we use:
sudo vi ...
instead of simply:
vi ...
The course warns that modifying sshd_config incorrectly can quickly lock you out of the server.
Do not modify SSH configuration casually unless you understand what the setting does.
H. Disable Root SSH Login
Inside:
/etc/ssh/sshd_config
find the root login configuration.
The relevant setting is:
PermitRootLogin
Change it so root login is not permitted:
PermitRootLogin no
Conceptually:
The server still has a root user.
We are only disabling the ability to directly authenticate through SSH as root.
I. Other SSH Configuration Options
The SSH configuration contains many other security-related settings.
For example, it can control things such as:
Password authentication
SSH authentication behavior
SSH port
Root login
...
However, the course specifically warns against changing unrelated settings without understanding them.
Changing SSH configuration incorrectly can result in:
For this setup, the important change is simply disabling root login.
J. Why Restart the SSH Daemon?
Changing:
/etc/ssh/sshd_config
does not necessarily mean the running SSH process immediately uses the new configuration.
The SSH daemon reads its configuration when it starts and keeps that configuration in memory.
Conceptually:
If we later edit:
sshd_config
the already-running process still needs to reload or restart before the new configuration takes effect.
Before applying the change, validate the configuration:
sudo sshd -t
If the command prints no error, reload Ubuntu's ssh service. Reloading is safer than restarting because it applies the configuration without unnecessarily interrupting the running service:
sudo systemctl reload ssh
The safe sequence is:
K. Root Still Exists
Disabling root SSH login does not delete the root user.
Root is still part of the operating system.
The difference is:
Direct SSH as root
→ Disabled
Root privileges through sudo
→ Still available
Normally, we stay logged in as our regular user:
jem
and elevate individual commands when necessary:
sudo <command>
The course mentions that it is possible to switch into a root shell, but generally recommends against operating as root.
The preferred model remains:
L. Test That Root Login Is Disabled
After reloading SSH, keep the current session open. Open a second Terminal window and use it to test the configuration. This leaves you with a working session if the new connection fails.
In the second Terminal, first confirm that the regular user can still connect:
ssh <username>@<server-ip>
Then try logging in as root:
ssh root@<server-ip>
If everything was configured correctly, the server should deny the login.
That failure is actually the expected result.
The final state should be:
root@server
→ ❌ Direct SSH login denied
jem@server
→ ✅ SSH key authentication works
jem + sudo
→ ✅ Can perform privileged operations when necessary
M. Final Security Model
After completing these steps, the server authentication model looks like this:
Direct root SSH access is blocked:
Complete Flow
Key Takeaway
The goal is to avoid exposing an unrestricted root account directly through SSH.
Instead of:
we use:
The important configuration steps are:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
sudo vi /etc/ssh/sshd_config
Set:
PermitRootLogin no
Then run sudo sshd -t and, if no errors are reported, use sudo systemctl reload ssh so the new configuration takes effect.
Most importantly, never disable root login until you have confirmed that the new user can successfully log in and use sudo.