A Buru user can authenticate with two methods: password and public key. Each is configured independently per user and the two can be combined into multi-factor authentication. Password authentication is accepted by every protocol (SFTP, SCP, SSH, FTP, FTPS, and Web Administration), while public key authentication is accepted only by SSH-based protocols (SFTP, SCP, SSH).

See Manage Users (Web Admin) or Manage Users (CLI) for the procedures that configure these methods on a user account.

Password authentication

The user supplies a password, which is verified in one of two modes:

• Local — the password is hashed and stored in the user database. Hashing algorithm, salt size, and rehash behavior are configured globally in the users section of config.yaml.
• Windows PRO — the password is checked against a local Windows account or an Active Directory domain account via the LogonUser API. The server can additionally impersonate that Windows identity when accessing files, so NTFS permissions apply directly — see File Access & Permissions.

Windows mode comes in two flavors that differ in the type of token Windows hands back after a successful logon:

Public key authentication

One or more SSH public keys are associated with the account. The user proves possession of the matching private key.

You can attach any number of keys to a single user — useful for rotating keys without losing access, or for letting the same user sign in from different devices.

Generating a key pair

Key pairs are generated on the client side; only the public half is ever handed to the server. The usual tools:

• ssh-keygen — ships with OpenSSH (Windows 10/11, every Linux and macOS). Runs from any terminal.

  ssh-keygen -t ed25519 -C "elaine@laptop"

  By default the key pair is written to ~/.ssh/id_ed25519 and the public half to the same path with a .pub suffix. Protect the private key with a passphrase when prompted.

• PuTTYgen — part of the PuTTY suite. Click Generate, move the mouse to seed entropy, save the private key as a .ppk file, and copy the OpenSSH-formatted public key from the top text field. The Buru server accepts both OpenSSH authorized_keys lines and SSH2/PuTTY public key files.

Only the public half (the .pub file or its contents as a string) is registered with the server; the private key must never leave the user's machine.

Hardware-backed keys

Public key authentication also supports keys held on a hardware token, so the private key never leaves the device. Common options include YubiKey, Nitrokey, SoloKey, and OnlyKey. The resulting public key is registered with Buru the same way as a software key.

Combining methods

Each method (password and public key) has an independent state of disabled, enabled, or required:

• disabled — not accepted at all.
• enabled — accepted if offered, but not mandatory.
• required — the user must complete this method to log in.

The states combine as follows:

• Both enabled — the user can log in with either method on its own. Whichever one they offer first that succeeds, lets them in.
• Both required — true multi-factor authentication. The user must present a valid password and a valid public key on every login.
• One required, the other disabled — only the required method is accepted.