Skip to main content

Create a Non-Root User on Debian Linux

The recommended way to create a non-root user on a server is passwordless: the account has no usable password at all, you log in with an SSH key, and sudo is granted without a password prompt. There is no password to guess, phish, or reuse, and nothing to type when you sudo.

Do all of this while logged in as root (or via sudo), and keep that root session open until you have verified the new login works.

Step-by-step instructions​

  1. Create the user with no password.

    sudo adduser --disabled-password --gecos "" username

    --disabled-password creates the account and home directory but never sets a password, so password logins are impossible while key-based logins still work. --gecos "" skips the interactive "Full Name / Room Number" questions.

  2. Install your public key for the new user. You'll need a key pair on your local machine — see Set Up SSH Key Authentication if you don't have one yet.

    Because the account has no password, ssh-copy-id can't authenticate yet, so push the key through your existing root session. Run this from your local machine:

    ssh root@server "install -d -m 700 -o username -g username /home/username/.ssh && \
      cat >> /home/username/.ssh/authorized_keys && \
      chown username:username /home/username/.ssh/authorized_keys && \
      chmod 600 /home/username/.ssh/authorized_keys" < ~/.ssh/id_ed25519.pub

    Or, if you're already sitting at a root shell on the server, paste the key in by hand:

    install -d -m 700 -o username -g username /home/username/.ssh
    nano /home/username/.ssh/authorized_keys      # paste the .pub line, one key per line
    chown username:username /home/username/.ssh/authorized_keys
    chmod 600 /home/username/.ssh/authorized_keys

    SSH is strict about permissions: .ssh must be 700, authorized_keys must be 600, and both must be owned by the user — otherwise the key is silently ignored.

  3. Grant passwordless sudo. A user with no password can't answer a sudo password prompt, so the sudo rule has to be NOPASSWD. Put it in its own file under /etc/sudoers.d/ rather than editing /etc/sudoers:

    echo "username ALL=(ALL) NOPASSWD:ALL" | sudo tee /etc/sudoers.d/username
    sudo chmod 0440 /etc/sudoers.d/username
    sudo visudo -cf /etc/sudoers.d/username

    The last command validates the syntax and must print parsed OK. A broken sudoers file can lock you out of sudo entirely, so never skip it. The filename must not contain a dot or end in ~, or sudo will ignore the file.

    Adding the user to the sudo group is not needed with this rule, but is harmless if you prefer the group for consistency:

    sudo usermod -aG sudo username

  4. Verify the login from a second terminal, while the root session stays open:

    ssh username@server
    sudo whoami

    sudo whoami should print root with no prompt.

  5. Turn off password authentication for SSH (recommended). Once key login works, stop the server from accepting passwords at all. On Debian 12 and newer, drop a file into /etc/ssh/sshd_config.d/:

    sudo tee /etc/ssh/sshd_config.d/99-hardening.conf <<'EOF'
    PasswordAuthentication no
    KbdInteractiveAuthentication no
    PermitRootLogin prohibit-password
    EOF

    sudo sshd -t && sudo systemctl restart ssh

    sshd -t tests the config before the restart. PermitRootLogin prohibit-password keeps root reachable by key (useful for recovery) while blocking root password logins; use no if you want root SSH shut off completely — but only after confirming your non-root user works.

    On Debian 13, sshd is socket-activated; if a config change doesn't seem to take effect, restart the socket instead:

    sudo systemctl restart ssh.socket

Key considerations​

  • "SSH cert" vs. SSH key: this guide uses ordinary public-key authentication — a key pair, with the public half in authorized_keys. True SSH certificates are keys signed by an SSH certificate authority (ssh-keygen -s), which is worth the extra machinery when you're managing many users or hosts, but is overkill for a single server.
  • Keep a recovery path. A passwordless account can't log in at a physical or virtual console, and can't be reached with su - username from another non-root account. Make sure you retain root console access (Proxmox console, cloud provider serial console, hypervisor terminal) before disabling password logins.
  • Passwordless sudo is a deliberate trade-off. It means anyone holding your private key has instant root. That's an acceptable trade for a single-admin homelab or personal server; on a shared or higher-risk machine, set a strong password with sudo passwd username and drop the NOPASSWD: prefix instead.
  • adduser vs. useradd: both exist, but adduser is preferred on Debian as it is an interactive wrapper that sets up home directories and default configurations automatically, whereas useradd is a lower-level, non-interactive tool more suited to scripting.
  • Docker: if the user needs to manage Docker without root, see this Reddit discussion.

Sources​