Connecting to DA with an API script, or giving out your DA password?

DirectAdmin Support

DirectAdmin Support

Administrator
Staff member
Joined
Feb 27, 2003
Messages
9,158
How well do you trust a script or other person?
Even if you think you can, accidents can happen (bugs or human errors) where a password gets lose and discovered by someone who shouldn't know it.
Never trust anyone or anything with your plain-text password.

What can you do?

Use Login Keys!!

Login keys provide you with a separate password, other than your true DA password, which you can use for all external API scripts, or even if you need to give temporary access to a tech.
These keys can be restricted by:
- connecting IP
- which commands can be run
- and even given an expiry (so you don't need to worry about forgetting to disable the key)

You can even create multiple keys to have a different password for each person logging in, optionally restricted to their IP.

We highly recommend using Login Keys for any case where you need to give it out or save it to a script somewhere.

Even use them for yourself, locked to your own IP. You really don't need to use your true password for day-to-day operations (but you still need to know it for some cases)

Follow this guide to create your Login Key:
http://help.directadmin.com/item.php?id=523

John
 
This is very cool.

I have been working some with this and wanted to ask if there are plans to adapt the 3 out-of-box skins to display only the allowed features?

..or perhaps a 4th skin
EG: one menu with all CMD_ api on it so showing or not based on key.

Making a limited use key for a tech can get spent and disabled very quickly by clicking on disallowed menus/features. I may be mistaken but in some tests it seemed like: uses = clicks / CMD_ clicks.

The other thing I noticed with an HTM/CSS enabled key was that a disallowed click would require another use of the key / DA login.

Seems an 'not authorized' pop-up would be well received over the need to start over.
 
Interesting... I don't have the 'Login Keys' options to choose from as an Admin under my User Level domains.
I also can't turn the option on for my own or 80+ other existing domains.

Could this be because I don't have created any resellers at first and all other users have been created under the Admin-reseller?

I can see the LoginKeys-option at the Admin-user with /CMD_SHOW_USER, but with /CMD_MODIFY_USER the option is not visible.
 
BBM, from what I've read the skins may not have login keys selections integrated yet.

RE: http://www.directadmin.com/features.php?id=1298

Maybe the KB #523 was a bit early?

I've only used the API CMD to display the login key related area(s) and have no more than 'admin' at present which as you, has no login key related menu selections built in the skins that I can find.
 
Hello,

Both the Enhanced and Power_User skins do support Login Keys.

1) Ensure it's turned on, which it should be by default, eg:
Code: 
[root@server directadmin]# cd /usr/local/directadmin
[root@server directadmin]# ./directadmin c | grep login_keys
login_keys=1
login_keys_notify_on_creation=1
2) Make sure it's enabled for a given User/Reseller/Admin. It's set in their packages, but for a Reseller, the User Packages won't show it if that Reseller isn't allowed Login Keys.
The easy way is to check the conf files, eg:
Code: 
cd /usr/local/directadmin/data/users/[B]username[/B]
cat user.conf | grep login_keys
cat reseller.conf| grep login_keys
where for a User to see the Login Keys option in their User Level, they'd need to have
Code: 
login_keys=ON
in their user.conf file.

John
 
..my prior reply oversight:
If you don't yet have any domains created, then you can manually access the page via this URL: /CMD_LOGIN_KEYS

Since my domain-less admin is the only user I just went about testing using the manual access method.

I will test this again with "login_keys=ON" shortly, but in case you pass by again, John or anyone else knows, does the "ON" setting change the behaviour compared to what I'd written about in Post 2?
 
You must log in or register to reply here.
Back
Top