Multiple Levels of security are mandatory these days.  A single password is only 1 level, and if lost or stolen, an attacker would be able to login if there are no other levels of security.  If you need to give out your DirectAdmin password for any reason, either for an API script, or even to a remote tech, or it's best not to hand out your true password.

DirectAdmin has a feature called Login Keys which allow you to have multiple other passwords for your DirectAdmin account, but these other password can be set with heavy restrictions.
These include:

• Number of CMD_ requests can be limited to a specific number, or unlimited.
• Login Key can be set to expire at a certain time
• Key can be deleted after expiry or after all requests are used.
• Key can be set to not allow HTM_, IMG_ or CSS_ requests, making it very difficult to use DA with a browser.
• Ability to restrict the key to a limited number of commands (CMD_*) or Level groupings.
• Key can be set to only allow specific IPs or simple ranges (1.2.3.4-5)

---

To create your own Login Key, first Login to DirectAdmin as the account the key is for, eg: "admin".

1) Browse to the Login Keys page:

User Level -> Login Keys

If you don't yet have any domains created, then you can manually access the page via this URL:

/CMD_LOGIN_KEYS

2) Click "Create new Login Key" to get started with a new key.

3) Enter all fields as needed.

• You'll need to specify a Key Name.  Note that this is only for your own tracking purposes, it will not be the username for the login. Your current DirectAdmin username will still be used, along with the key as the password
• Specify a Key Value, or use the random button for a longer value.  The text will be shown to your when the key is created
• Expiry can be set if you only want this key to be temporary
• You can specify the Number of Uses if you only want the give key to be valid for a certain number of requests. For long-term APIs you'd use 0 for unlimited.
• The Clear Key option will typically only be used with temporary keys, handy for temporary tech logins, so you don't need to worry about forgetting to disable the key after it's expiry is passed (or all "uses" are consumed).
• The Allow HTM option is only used if this key is going to be used for a person to login with a browser.  API keys should not have this option enabled.
• Commands will let you specify which CMD_ or CMD_API_ calls are allowed to be used with this key.  This will depend on what your key needs.  If you are creating this key for an API/script, then you'd want to limit it to the smallest set of CMD_API commands you can.  Contact the author of the script to find out which commands the script needs.   Restricting the commands will make the key more secure because, if the key is lost or stolen, and the other features of the key are not applicable, the attacker would only be able to run the listed commands, which, depending on which values are enabled, might not be sufficient for them to do any damage.
• Remember that the commands ALL_USER, CMD_LOGIN_KEYS, or CMD_API_LOGIN_KEYS all allow access to the Login Keys for this, meaning that with this access, they can change the keys, which defeats the purpose, so make sure that you select your list of commands carefully.
• The Allowed IPs options lets you limit which IPs can connect with this key, one entry per line.  You can specify a simple IP range such as 1.2.3.4-6.
  

4) When testing your Login Key, it's often useful to run DA in debug mode, level 2000, which will have DA tell you why a login is being rejected.
http://help.directadmin.com/item.php?id=293

---

Examples

A) Power Reseller
Although this has not be tested, in theory, you can create a 2nd Admin account, and only allow them the Commands:

All_RESELLER
ALL_USER
CMD_ACCOUNT_RESELLER
CMD_RESELLER_SHOW

and Deny the command

CMD_LOGIN_KEYS
CMD_API_LOGIN_KEYS
CMD_PASSWD

Never expires, unlimited uses, clear key disabled, and allow html enabled.
This will give someone a Reseller Account, plus some Admin privileges.
Note that this is not fool-proof.  There are overlapping commands that would still allow them to delete an Admin account or change their true password (via non-obvious means), so you would still need a certain degree of trust of this account.  However, it would be useful to help prevent accidents/errors by that account.

B) User Level API to create/manage email accounts
As this is a script, it will never expire, will have unlimited uses, we don't need "clear key", and "allow htm" is not required.
The list of commands should only need to be:

CMD_API_POP
CMD_API_EMAIL_VACATION

and lastly, the IP field should contain just 1 IP, which is the IP that will connect to DA from the script. If the script is local, you'd specify 127.0.0.1.  If your connecting form a remote server, you'd enter the main IP of the remote server.

C) DNS Clustering with the Multi Server Setup
DA only needs a small set of commands to control the dns on a remote box. The "allow" list would be as follows:

CMD_API_DNS_ADMIN
CMD_API_LOGIN_TEST
CMD_API_USER_EXISTS

and you can set the IP of the remote box that needs to connect to this slave, as nobody else should be connecting with this key other than the master.

D) Key for Technical Support
If access to your server is requested, instead of providing the true admin password, you could provide a full-access Login Key instead.  For this use any key name, eg: "support", a random password (use the generator button), set an Expiry to say 5 days in the future (however long you thing it will need), Uses=0, Clear Key = yes, Allow HTM = yes, and enter the current admin password at the bottom. It can be restricted to an IP, but if different techs may be logging in, it's simplest to allow any.