Use an authorized reseller or administrator for account permissions, or ask support when you are the customer. Identify the user, required commands, intended key and access end date. Preserve a separate server-administrator recovery route.

1. Review the user or package SSH permission and the server supported shell or jail arrangement. Enable only the required access through the supported account controls.
2. Provide the verified server hostname, port and username. Add the authorized public key through the supported key-management workflow and protect the private key on the user device.
3. Test a new SSH connection and inspect the server host-key fingerprint through a trusted channel before accepting it.
4. Confirm the shell starts as the intended hosting user and can access only its permitted resources. Test the required deployment or maintenance command without using root.
5. If the DirectAdmin web terminal is available, verify its role and SSH prerequisites separately. Record the access grant and revoke it when no longer needed.

Confirm a fresh connection works and the user cannot perform unauthorized administrative operations. Check file ownership after a test deployment so files remain manageable by the hosting account.

If login fails, distinguish account permission, key authentication, shell restrictions, network rules and a brute-force block. Do not grant unrestricted shell or administrator privileges simply to make one command run. An administrator can sometimes perform a controlled command as the user without enabling permanent customer SSH access. Remove obsolete keys separately from changing a password.

• Setting up DirectAdmin two-step authentication
• Investigating a DirectAdmin brute-force block
• Installing an SSH key without losing existing server access
• Adding a PHP extension through DirectAdmin CustomBuild

• DirectAdmin: Managing With SSH
• DirectAdmin: Web Terminal