Margin desk · Intermediate · 20 minutes
How to connect to a VPS with SSH — Root on Somebody Else's Box Is a Liability
The provisioning email is sitting in your inbox with a root password in it, and that is now a fact about your business rather than about the server.
Straight answer first
Treat the provisioning credentials as a liability from the first login: change the password immediately, store it in a password manager rather than a client folder, install one key per person rather than one key per company, and prove key login works in a second terminal before you disable passwords. On a client box the audit trail matters as much as the access, because you will eventually need to say who did what.
Read on for the order of operations, the exposure to watch for, and the version of this job you can push across the rest of your accounts.
Written by the Hosting Seller staff · Checked 24 August 2026
Intermediate
Bench skill
5
Stages to sign-off
Free
Escalation, included
Tested
Proven on the platform you resell
Written for the person who answers the phone when this goes wrong: 20 minutes of work, a intermediate hand on the keyboard, one client account to do it in.
The undo is named wherever one exists, because a rollback you can perform while the client is still on the line beats a clever configuration you cannot reverse.
The email with the root password in it
It has been sitting in your inbox, and possibly in a forwarded thread, since the box was provisioned. Change the password on first login with passwd, then store it somewhere designed for the job rather than in a client folder or a note in your project tool.
This matters more for a reseller than for someone running their own server, because the credential is not yours. If it leaks, the conversation you are having is about your operational practice rather than about a password.
One key per person, never one per company
A shared key is untraceable and unrevocable in any useful sense: when someone leaves you rotate a credential every remaining person depends on, usually in a hurry. Install a separate public key for each person who needs access.
Then make each of them a named sudo-capable user rather than everybody logging in as root. The audit trail improves the moment you do, and who ran that stops being a question with no answer.
The config file that doubles as your inventory
Add each server to ~/.ssh/config with a short alias, the key path and the username. It becomes one short command forever after, and that file quietly turns into an inventory of every client box you touch.
Keep the aliases matching your client naming everywhere else: the account name in the panel, the project folder, the billing record. Consistency across those four places is what stops the wrong command running on the wrong client's server at the end of a long day.
Whether this box should exist at all
A VPS gives you root and gives you every future update, patch and certificate renewal alongside it. For a client application that genuinely needs root, that is the right trade. For a client website, a reseller account with cPanel is not a compromise, it is the better answer.
The honest test is who answers the client's next password reset. On a managed account they do it themselves in a panel; on a bare VPS they open a ticket with you. Multiply that by your client list before you provision.

The kit sitting behind the accounts you sell
Setup is free, which matters most when you are testing whether a client segment is worth having at all. Nothing is due before you start selling, and the reseller guarantee runs to seven days.
Daily backups cover every client account and Imunify360 stands on every client site, so the two things clients panic about are already handled before they ask.
- The one panel the whole trade knows
- Staging copies before anything goes live
- WordPress Toolkit, updates applied
- Seven-day guarantee on reseller plans
Why Hosting Seller
On every plan, as standard
The handover note is part of the job
Each runbook ends with what to write down, because an account you cannot document is an account you cannot hand on or sell.
Five stages, no padding
Every stage is a decision or a command, with the genuinely fiddly parts marked fiddly.
Per-person access, not per-company
Keys and named users are set up so somebody leaving is a five-minute job rather than a rotation everyone feels.
Tested on the platform you resell
WHM, cPanel, LiteSpeed, Softaculous: the screens in the runbook are the screens inside the account you sold.
Figures you can safely repeat to a client
Uptime targets, guarantee windows and account limits are stated as they actually are, so nothing you quote comes back at you later.
The build-or-buy question, asked
Who answers the client's next password reset gets checked before you commit to running a bare server for them.
First Steps
From choosing to live
- 1
Log in once with the provisioned details
ssh root@the-address from any terminal, Windows included. Accepting the host fingerprint on first connection is normal — that is the server introducing itself, and SSH will warn you if it ever changes.
- 2
Change the password and store it properly
Run passwd immediately, then put the new credential in a password manager. A client folder, a chat thread and a project-tool note are all the wrong place, and all three are where it usually ends up.
- 3
Install one key per person
ssh-keygen on each person's own machine, then their public key onto the server. Shared keys cannot be revoked without disrupting everybody, which is precisely why offboarding turns into an incident.
- 4
Prove key login before you close the door
Confirm key authentication works in a second, separate terminal, and only then set PasswordAuthentication no. That order is the entire reason people do not lock themselves out of a client's server.
- 5
Create named users and record the alias
A sudo-capable account per person, with root kept for emergencies. Then add the box to ~/.ssh/config under an alias matching the client's name in your panel and your billing.
In the Box
Packed with every plan
- Site migration done for you by our staff, at no charge
- Staging copies, so changes get tested before clients see them
- DDoS filtering handled out at the network edge
- Private nameservers running under your own brand
- Packages you build, name and price yourself
- Daily backups taken across every client account
- Softaculous in every account you create
- Client-account caps of 100, 250 or 500 by tier
- A 7-day guarantee on reseller plans, 30 days on hosting
- A 99.9% uptime target, watched by monitoring day and night
Across the Counter
Things people ask us all the time
Should a client ever have root on a box I manage?
Only where they are genuinely willing to own what they break, and it is agreed in writing. Otherwise give them what they actually need — a panel, an application login, or a named sudo user with a documented scope — and keep the root credential inside your own operation.
How do I give a contractor access without sharing a key?
Add their own public key and a named user, then remove both when the engagement ends. Sharing a key means every departure becomes a rotation affecting everyone, which is exactly the work you were trying to avoid.
Someone left the team. What do I actually do?
Remove their public key from every authorized_keys file, delete their named user, and rotate anything they could read. This is why per-person keys matter: the alternative is rotating a credential the whole team depends on, in an afternoon, badly.
Is a VPS or a reseller account the right home for a client site?
Ask who answers the client's next password reset. A reseller account gives them cPanel and self-service while giving you WHM; a bare VPS gives you root and every future patch, certificate and support request that comes with it. For most client websites the account wins on your time alone.
Read next
DirectAdmin Reseller Hosting
Lighter reseller hosting on DirectAdmin, at a leaner price tag.
WordPress Hosting
WordPress kept in order for you: LiteSpeed caching, staging copies and daily backups.
Moving your site to another host? Start with this checklist.
A step-by-step order of work for a move your visitors never spot: which files to copy first, how to carry email across without losing one message, the right moment to repoint DNS, and the two mistakes behind nearly every hour of downtime people ring us about.
Take the client list somewhere it can grow.
Overselling on from the start, packages you name yourself, and a support desk that answers your clients as well as you.
See DirectAdmin Reseller Hosting plans