User authentication methods
Buru SFTP Server ('Buru') 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.
Note: This article explains configuring the authentication using Buru command line interface. All these tasks can also be conveniently performed using Web administration.
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
# 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 settings.
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:
- salt order (whether salt is prepended (
salt-first) or appended (
password-first) to the password),
- password hash (SHA-1, SHA-2 and MD5 are supported) in hex format, and
- salt (if used, otherwise use
0xfor 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.
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 in 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.
Note: Windows authentication and local password authentication are obviously mutually exclusive.
Windows authentication and impersonation are available in the Pro edition only.
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.
When impersonation is turned off, the SFTP server accesses filesystem using the user under which the
burusftp service is running.
Note: SSH aliases are not supported when impersonation is turned on.
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.
Is 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
- Use strong passwords
- Do not use
--password pwdif 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