cPanel's Terminal gives you a shell in the browser, and SSH Access lets you connect from a real terminal. Both reach the same place with the same permissions, your account, not the server, and both are off by default on most shared plans.
What you can and cannot do
You are your account's user. You can read and write your own files, run commands as yourself, and use tools the server has installed.
You cannot install system packages, restart services, read other accounts, or do anything requiring root. Those commands exist and refuse, which is correct in place of a limitation to work around.
If a task genuinely requires root, a shared plan is not the tier for it, VPS hosting is.
Terminal in the browser
If your account has it, Terminal appears under Advanced in cPanel. Click it and you have a shell, already authenticated as your account.
Convenient for a quick command, and it has one real drawback: closing the browser tab kills whatever was running. For anything that takes minutes, that matters.
SSH from your own terminal
Better for real work. Under Security, SSH Access lets you manage keys.
Generate a key pair, authorise the public key, and connect:
ssh -p 22 [email protected]
Use a key instead of a password. Automated guessing against SSH is continuous, and a key ends that category outright.
If the port is not 22 on your server, your welcome email will say. Connecting to the wrong port produces a connection refused that looks like SSH being disabled.
What it is actually useful for
Five things, and they are all things the file manager does badly or not at all.
Finding what filled the disk. du -sh * in your home directory, then descending into the largest one. Far faster than clicking through a file manager, and it usually finds a backup plugin's output within seconds.
Searching across files. grep -r "text" . answers "which file contains this" immediately.
Moving and archiving. Creating or extracting an archive on the server is instant compared with transferring thousands of files.
Running WP-CLI if it is available, database search-and-replace, plugin updates, user management, all faster than the dashboard and scriptable.
Reading logs. tail -f on the error log while you reproduce a problem shows the error as it happens, which is a different experience from downloading a file and searching it.
The commands worth knowing
du -sh * # what is using space here df -h # how much of the quota is used grep -r "text" . # find text in files tail -50 error_log # last 50 log lines tail -f error_log # watch the log live find . -mtime -1 # files changed in the last day
That last one is genuinely useful after a suspected compromise: recently modified files in a site nobody has edited is a strong signal.
Long jobs need to survive disconnection
A command running in an SSH session dies if the connection drops, and browser Terminal dies when the tab closes.
If screen is available, use it for anything slow:
screen -S work # run the command, Ctrl+A then D to detach screen -r work
Otherwise keep long operations to things you can restart safely.
Be careful with two things
rm -rf deletes without confirmation and there is no trash. A mistyped path is not recoverable except from your own backup.
And redirecting output over a file with > replaces it silently. Use >> when you mean to append.
Both are ordinary shell behaviour and both are more consequential here than on your own machine, because the file manager's trash does not apply.
If it is not available
Shell access is off by default on shared plans and is granted per account. If you have a specific need, ask, and expect to be asked what for, since it is a reasonable question.
Resellers grant it from WHM per account, and it stays granted until somebody removes it. There is more in WHM account functions.
On a WordPress site, one tool turns most admin jobs into a single command, and works when the admin area does not. See How to Use WP-CLI on Your Hosting Account.
Confirm which PHP you are actually running
The PHP available in a shell session is frequently not the one serving the website, and every command run against the wrong one produces confusing results.
php -v which php /usr/local/bin/ea-php83 -v
On a cPanel server the version a user gets is decided by the PHP selector rather than by the panel's MultiPHP setting, and the two can disagree. A composer install or a WP-CLI command run under the wrong version installs dependencies the site cannot use.
Where they differ, call the versioned binary explicitly rather than relying on the default. There is more on establishing which the site uses in MultiPHP Manager.
Finding what is filling the account
The single most common reason to open a terminal, and three commands answer it:
du -h --max-depth=1 ~ | sort -h | tail -15
find ~ -type f -size +100M -exec ls -lh {} \; 2>/dev/null | head
find ~ -xdev -type d -exec sh -c 'echo "$(ls -A "$1" | wc -l) $1"' _ {} \; 2>/dev/null | sort -rn | head
The first finds large directories, the second large files, and the third directories with enormous numbers of small files, which is a different problem, because an account can run out of files while having space left.
That third case produces errors saying the disk is full on an account that plainly is not. Understanding inodes goes into it.
Searching a codebase properly
grep -rn --include='*.php' 'wp-config' ~/public_html | head grep -rlZ 'eval(base64_decode' ~/public_html | xargs -0 ls -l
Restricting by file type keeps the search fast on a large site. The second form lists matching files with their dates, which matters when looking for injected code. A cluster of files modified at the same unfamiliar time is the pattern to look for.
Finding something there is the start of an investigation instead of the end. Cleaning up a hacked WordPress site explains the sequence, including why removing the file is not sufficient.
Two commands worth having ready
tail -f ~/logs/example.com 2>/dev/null | grep -v '\.css\|\.js\|\.png' mysqldump -u user -p dbname | gzip > ~/backup-$(date +%F).sql.gz
The first watches live requests with the asset noise removed, which makes a pattern visible immediately: particularly a single address requesting the same expensive path repeatedly.
The second is a database backup taken in one line, which is worth running before any change you might regret. Note the password is prompted for rather than written into the command, which keeps it out of the shell history; a command containing a password is stored in a file that is readable for as long as the account exists.