User authentication methods

Rebex Buru SFTP server support username/password and public/private key authentication.

Buru SFTP Server currently supports two authentication modes - password and public key authentication. In this article we will give you an overview of each, how to set up authentication and few useful tips.

Password authentication

As the name suggests, the server expects the client to supply a password. The password can be validated either using locally stored password hash or Windows authentication capabilities (more on that later).

Local password authentication

Local password can be set when creating a new user or when updating an existing one:

# securely prompt for password (recommended)
burusftp user add myuser -p ... 

# set password directly (not recommended - visible, may be saved to shell command history)
burusftp user add myuser --password mysecretpassword ... 

# similarly for user update
burusftp user update myuser -p ...  
burusftp user update myuser --password mysecretpassword ...

Local passwords are “salted” using random 20-byte block, hashed using SHA-512 and saved to users.ldb file. The salt length and hash algorithm can be adjusted in the [server configuration settingshttps://www.rebex.net/doc/buru-sftp-server/configuration/config/users/).

Import users with password hashes

To enable user import from third party applications it is also possible to create (not update) users using only password hashes. Three values must be supplied:

  1. salt order (whether salt is prepended (salt-first) or appended (password-first) to the password),
  2. password hash (SHA-1, SHA-2 and MD5 are supported) in hex format, and
  3. salt (if used, otherwise use 0x for empty salt) in hex format.

The following example assumes that salt is prepended to the password, 0x1055... is the password hash (algorithm is deduced by hash length - in this case, MD5) and 0xa0392fed is the 4-byte salt.

burusftp user add myuser --password-hash salt-first,0x1055d3e698d289f2af8663725127bd4b,0xa0392fed ...

When user’s password hashing algorithm or salt length doesn’t match the configured value then password is automatically rehashed and updated on user’s login, unless explicitly disabled in the configuration. This means any unsafe hash values (MD5 or unsalted hashes) will be only kept until user logs in.

Windows authentication - Pro edition

Another option is to use an associated Windows account to validate the password. The account can be either a local Windows user or a domain user.

Associating a Windows account and enabling Windows authentication can be done the following way:

# these two commands are equivalent
burusftp user add myuser --win-account DOMAIN\winuser 
burusftp user add myuser --win-account DOMAIN\winuser --password-auth required --password-auth-mode windowsNetwork --impersonate on

# these two commands are also roughly equivalent
burusftp user update myuser --win-account DOMAIN\winuser
burusftp user update myuser --win-account DOMAIN\winuser --password-auth-mode windowsNetwork --password-auth required --impersonate on

When a SSH client logs in using his Buru username and a password belonging to the associated Windows account, Buru attempts to authenticate the user by calling LogonUser WinAPI function using the specified Windows account, password and logon type (windowsNetwork or windowsInteractive). The difference between those two methods can be found in Microsoft documentation.

File system access impersonation

Windows authentication allows Buru to access users’ files using their own Windows identity - impersonated acccess. Enabled impersonation makes Windows authentication mandatory as Windows password is needed for impersonated access and Buru does not store users’ Windows credentials. Impersonation is enabled by default when Windows authentication is turned on but can be disabled using --impersonate off option available for both user add and user update commands. Impersonation only applies to SFTP and SCP access - terminal process always runs using the service account.

When impersonation is turned off, the SFTP server accesses filesystem using the user under which the burusftp service is running.

Public/private key authentication

SSH protocol allows users to authenticate using their private key providing that the corresponding public key is associated with the user account on the server:

burusftp user add myuser --keys C:\mykey.pub
burusftp user update myuser --set-keys C:\mykey.pub

Several public keys can be associated with an user account. Then the user can log in using any of the corresponding private keys.

Buru stores public keys in the user database (users.ldb) and therefore the key files need to exist only when adding the keys.

SSH keys can be generated using ssh-keygen or PuTTYgen.

Multi-factor authentication

It is possible - and recommended - to combine multiple authentication modes (public key + password):

# both public key and password are required 
burusftp user add myuser --password mypwd --keys C:\mykey.pub --key-auth required --password-auth required 

# either public key or password is sufficient
burusftp user add myuser --password mypwd --keys C:\mykey.pub --key-auth enabled --password-auth enabled

Security recommendations

  • Use strong passwords
  • Do not use --password pwd if possible - password might get saved to shell history and is in plain sight
  • Use password-protected private keys to avoid key theft
  • Use account lockout to prevent bruteforce attacks, especially when using Windows authentication to prevent Windows account lockout
  • Use multi-factor authentication
  • Do not reuse passwords on different sites / servers

See also