Solved Bug: can't run reseller_to_user.sh: unauthorized

k1l0b1t

k1l0b1t

Verified User
Joined
May 10, 2020
Messages
494
Location
Belgium
The reseller_to_user.sh script fails
root@webserver:/usr/local/directadmin/scripts# ./reseller_to_user.sh client admin
{"type":"UNAUTHORIZED"}
 
hi @k1l0b1t, it might hint that something is not right with automatic server hostname detection. Script contents were migrated to the backend code so now script only perform API call.

To authorize itself it uses root-auth mechanism. It works by creating a login-key for main admin account and generating URL suitable for API requests. Try executing da root-auth-url as root to see what it returns.

For example such command should work fine:

Code: 
# curl -s $(da root-auth-url)/api/version
{"commit":", ..., "os":"linux_amd64"}

If it fails it might mean DA was unable to generate correct URL to itself (for example bad hostname is configured), or failed to generate admin owned login-key (in this case errors in error log should help to understand why.)
 
If I run `da root-auth-url` itself, I get the correct hostname back.

When I run it in combination with a command, I get the unauthorized though.
root@webserver:~# curl -s $(da root-auth-url)/api/version
{"type":"UNAUTHORIZED"}root@webserver:~#

Looking into /var/log/directadmin/login.log I do see the server ip failing to log in as itself (I assume when making the root auth key for internal use?)

When I go to the login key section, and click on the log buttn for the root-auth key I get:
Unable to read ./data/users/admin/login_keys/rootauth/key.log
the file does not seem to exist either.

last log entries for that key go back to february (when I manualy look up the directory and open key.log.1)
 
Hmm lets check:

Code: 
# da c | grep login_keys=
login_keys=1


# grep login /usr/local/directadmin/data/users/admin/user.conf
login_keys=ON


# stat /usr/local/directadmin/data/users/admin/login_keys/rootauth/key.conf
  File: /usr/local/directadmin/data/users/admin/login_keys/rootauth/key.conf
  Size: 287           Blocks: 8          IO Block: 4096   regular file
Device: fe01h/65025d    Inode: 792005      Links: 1
Access: (0600/-rw-------)  Uid: (  107/diradmin)   Gid: (  113/diradmin)
Access: 2022-04-27 07:54:30.820944513 -0400
Modify: 2022-04-27 07:54:30.800944418 -0400
Change: 2022-04-27 07:54:30.800944418 -0400
 Birth: -
 
Code: 
root@webserver:/usr/local/directadmin/data/users/admin/login_keys# da c | grep login_keys=
login_keys=1
root@webserver:/usr/local/directadmin/data/users/admin/login_keys# grep login /usr/local/directadmin/data/users/admin/user.conf
login_keys=ON
root@webserver:/usr/local/directadmin/data/users/admin/login_keys# stat /usr/local/directadmin/data/users/admin/login_keys/rootauth/key.conf
  Bestand: /usr/local/directadmin/data/users/admin/login_keys/rootauth/key.conf
  Grootte: 287          Blokken: 8            IO-blok: 4096   normaal bestand
Apparaat: fe01h/65025d   Inode: 2630172      Koppelingen: 1
Toegang: (0600/-rw-------)   UID: (  107/diradmin)   GID: (  113/diradmin)
Toegang:   2022-04-27 13:59:08.791611453 +0200
Gewijzigd: 2022-04-27 13:59:03.115621038 +0200
Veranderd: 2022-04-27 13:59:03.115621038 +0200
Ontstaan:  2022-04-27 13:59:03.115621038 +0200
root@webserver:/usr/local/directadmin/data/users/admin/login_keys#
 
Fixed:

After looking at some shadow hashes for new users, I noticed $6$, which probably is created by DirectAdmin. Changing password makes it use the debain-default, which is set in /etc/pam.d/common-password

So a simple fix is setting that to use sha512crypt instead of yescrypt and changing password.
 
In the alpha release channel we already have support for modern crypt methods. We expect it to get released with the next DA release.
 
You must log in or register to reply here.
Back
Top