How to Use SSH Keys for Secure NAS Management
Network-attached storage systems are often managed through a web interface, but SSH provides a direct command-line connection for administration, diagnostics and automation. When configured properly, SSH keys can make access to a Synology or QNAP NAS significantly harder to compromise than password-only login.
An SSH key pair uses a private key stored on your computer and a matching public key copied to the NAS. The server checks the pair before allowing access, so your password is not transmitted during authentication. A passphrase on the private key adds another layer of protection if your laptop is lost or stolen.
Secure remote NAS management is especially important when a device contains family photos, business documents, surveillance recordings or media libraries. Australian households using NBN connections, and small businesses in Sydney, Melbourne, Brisbane or Perth, should avoid exposing management services directly to the internet wherever possible.
Why SSH Keys Improve NAS Security
Password-based SSH access is vulnerable to guessing, credential stuffing and automated scanning. A strong password helps, but internet-facing services are constantly probed. SSH keys use cryptographic authentication, making random password attacks ineffective when password login is disabled.
The private key should never be uploaded to the NAS or copied into cloud notes, email messages or shared folders. The public key is safe to place on the NAS because it cannot be used to recreate the private key. If several administrators need access, each person should use a separate key pair.
A passphrase protects the private key itself. On Windows, macOS and Linux, an SSH agent can remember the unlocked key for the current session, reducing the need to type the passphrase repeatedly. Hardware security keys, such as FIDO2-compatible devices, can provide stronger protection for administrators handling valuable business data.
SSH keys do not replace ordinary NAS security. Firmware updates, multi-factor authentication for the web console, firewall rules, backup testing and least-privilege accounts remain essential. Key authentication protects one access path; it does not correct an exposed or outdated NAS.
Creating An SSH Key Pair
On a modern computer, Ed25519 is generally a sensible default because it provides strong security with a compact key. Open a terminal and run:
ssh-keygen -t ed25519 -C "nas-admin"
When prompted for a file location, accept the default or choose a clearly named file such as ~/.ssh/nas_ed25519. Set a long passphrase that is different from your NAS password. Do not select an unencrypted private key simply because it is more convenient.
The command creates two files: the private key, commonly ending in _ed25519, and the public key ending in .pub. Protect the private file with restrictive permissions:
chmod 600 ~/.ssh/nas_ed25519
chmod 644 ~/.ssh/nas_ed25519.pub
Windows users can create keys through PowerShell with the built-in OpenSSH client. Windows 11 normally includes this component, although it may need to be enabled under Optional Features. Keep a secure backup of the private key in an encrypted password manager or offline encrypted storage, while ensuring the backup is accessible if the primary computer fails.
Installing The Public Key On A NAS
First enable SSH in the NAS administration panel. On Synology DSM, this is normally under Control Panel, Terminal and SNMP, while QNAP QTS places SSH access in Network and File Services or a related administration area. Menu names can vary between firmware releases, so check the current vendor documentation before changing settings.
Connect initially with a temporary password-based session and create the SSH key directory for the correct user:
mkdir -p ~/.ssh
chmod 700 ~/.ssh
Copy the contents of your public key file into ~/.ssh/authorized_keys. The file should contain the complete key on one line:
chmod 600 ~/.ssh/authorized_keys
Some NAS platforms restrict shell access, use a customised home directory or require an administrator account for SSH. Do not assume that a web-console user and a shell user have identical permissions. Test the key with a new terminal window before closing your working session:
ssh -i ~/.ssh/nas_ed25519 nasadmin@192.168.1.50
Replace the username and address with your own values. If the connection succeeds without asking for the NAS account password, key authentication is functioning. Keep the original session open until the test is complete so a configuration mistake does not lock you out.
Hardening SSH Access
After verifying the key, disable password authentication if your NAS firmware supports it safely. The relevant SSH server settings may include PasswordAuthentication no, PermitRootLogin no and a non-default listening port. Changing the port can reduce background noise, but it is not a security control by itself.
Never permit direct root login for routine administration. Use a named administrator account and elevate privileges only when necessary. On a business NAS, create separate accounts for backup automation, monitoring and maintenance instead of giving every service full administrator access.
Restrict SSH to the local network or a trusted management VLAN whenever possible. A VPN, such as WireGuard hosted on a suitable router or gateway, is safer than forwarding TCP port 22 from the internet to the NAS. Many Australian NBN services use carrier-grade NAT, which can make inbound access unavailable by default; this is useful from a security perspective. If a static public address is required, ask the ISP about the exact exposure and firewall options.
Review authentication logs regularly. Repeated failed attempts, unexpected source addresses or unfamiliar successful logins may indicate misuse. Synology and QNAP security tools can block suspicious addresses, but automated blocking should support, not replace, a properly configured firewall and VPN.
Managing Keys Over Time
Treat SSH keys as credentials with a lifecycle. Label each key by person, device or task, such as sydney-laptop, office-backup or media-server. When an employee leaves, a laptop is sold, or a key may have been copied, remove the corresponding public key from authorized_keys immediately.
Do not share one private key between a household, IT contractor or small business team. Individual keys provide accountability and allow one person’s access to be revoked without disrupting everyone else. Keep a written record of which key belongs to which device, stored separately from the NAS.
For automated jobs, use a dedicated NAS account with access limited to the required shared folders. A backup key should not provide unrestricted shell administration. Where supported, forced commands and source-address restrictions can limit what a key is allowed to do.
Test recovery before relying on SSH during an outage. Confirm that the NAS can still be reached through the local network, that the VPN works, and that a second authorised administrator can connect. This matters during summer storms, power interruptions or NBN faults, when remote troubleshooting may be needed from another suburb or city.
Recommendations For A Safer NAS Setup
A practical security baseline for home users and Australian small businesses is:
- Use an Ed25519 key with a strong, unique passphrase.
- Keep SSH restricted to the LAN or an authenticated VPN.
- Disable password authentication only after testing key access.
- Use separate named accounts and avoid direct root login.
- Remove lost, retired or former staff keys promptly.
- Update NAS firmware, router firmware and SSH clients regularly.
- Store tested backups independently from the NAS.
The following settings illustrate the difference between a basic deployment and a more controlled setup. Exact feature names vary between DSM, QTS, QuTS hero and third-party NAS operating systems.
| Security area | Basic setup | Stronger setup |
|---|---|---|
| Authentication | Password and key login | Key login with passphrase; passwords disabled for SSH |
| Network exposure | Port forwarded to the NAS | LAN-only access or VPN through the router |
| Accounts | Shared administrator login | Individual named accounts with limited privileges |
| Key storage | Private key on one computer | Encrypted key backup with documented ownership |
| Monitoring | Occasional manual checks | Login alerts, firewall rules and log review |
| Recovery | One administrator | Tested second key and documented local access |
A secure SSH configuration should complement a 3-2-1 backup plan rather than replace it. RAID protects availability when a disk fails, but it does not protect against ransomware, accidental deletion or fire. Keep at least one backup disconnected or isolated from the NAS, and test restoration regularly.
For NAS owners in Australia, also consider local power conditions and data obligations. A UPS can give a device time to shut down cleanly during outages, while businesses handling personal information should review their responsibilities under the Privacy Act and Notifiable Data Breaches scheme. SSH keys reduce unauthorised administration risk, but sound governance protects the information stored inside the NAS.
Enable key-based SSH access on your NAS, test it from a separate terminal, then tighten network exposure and retire password login when you are satisfied with the result. With individual keys, restricted accounts, current firmware and verified backups, remote NAS administration becomes far more controlled without sacrificing the command-line access needed for maintenance.