How to Add Another User Through SSH on Oracle Cloud
Managing access to your Oracle Cloud Infrastructure (OCI) instances often means bringing in additional team members, developers, or automated processes that need their own SSH credentials. Adding a new user via SSH isn't a single-click operation — it involves Linux user management, SSH key handling, and Oracle Cloud's own permission layers working together.
Here's a clear walkthrough of how the process works and what shapes the right approach for different setups.
What "Adding a User via SSH" Actually Means
When you spin up a compute instance on Oracle Cloud, you connect to it over SSH using a key pair. The instance runs a Linux distribution (commonly Oracle Linux, Ubuntu, or CentOS), and by default you get one administrative user — typically opc on Oracle Linux or ubuntu on Ubuntu-based images.
"Adding another user through SSH" means creating a new Linux system user on that instance and configuring SSH so that person (or process) can authenticate with their own key pair. This is separate from Oracle Cloud's IAM (Identity and Access Management) system, which controls who can interact with the OCI console and API — not who can log into the instance itself.
These two layers — OCI IAM and Linux system users — often get confused. Granting someone OCI console access does not give them SSH access to a running instance, and vice versa.
Step-by-Step: Creating a New SSH User on an OCI Instance 🔑
1. Connect to Your Instance as the Admin User
From your local terminal:
ssh -i /path/to/your-private-key.pem opc@<your-instance-public-ip> On Ubuntu-based instances, replace opc with ubuntu.
2. Create the New User
Once connected, create a new system user with:
sudo useradd -m -s /bin/bash newusername -mcreates a home directory at/home/newusername-s /bin/bashsets the default shell
If you want to give the user sudo privileges:
sudo usermod -aG sudo newusername On Oracle Linux, the sudo group is typically wheel instead:
sudo usermod -aG wheel newusername 3. Set Up SSH Key Authentication for the New User
The new user needs their own ~/.ssh/authorized_keys file containing their public key. The new user (or you, on their behalf) should generate a key pair. The public key gets placed on the server; the private key stays with the user.
sudo mkdir -p /home/newusername/.ssh sudo nano /home/newusername/.ssh/authorized_keys Paste the user's public key into that file, then set correct permissions:
sudo chmod 700 /home/newusername/.ssh sudo chmod 600 /home/newusername/.ssh/authorized_keys sudo chown -R newusername:newusername /home/newusername/.ssh Permissions matter here. SSH will silently refuse to use keys in files with overly permissive settings.
4. Verify the SSH Configuration
Check that your instance's SSH daemon allows the authentication methods you need. Open /etc/ssh/sshd_config and confirm:
PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keys If you made changes, restart the SSH service:
sudo systemctl restart sshd 5. Test the New User's Access
From the new user's machine:
ssh -i /path/to/their-private-key newusername@<your-instance-public-ip> Variables That Affect How You Do This 🛠️
The steps above cover the core process, but several factors determine what your actual workflow looks like:
| Variable | How It Changes Things |
|---|---|
| Linux distro on the instance | opc vs ubuntu default user; wheel vs sudo group names differ |
| Number of users to add | Manual steps work for one or two; larger teams benefit from automation tools like Ansible or cloud-init scripts |
| Level of access needed | Restricted shell, sudo access, or passwordless sudo each require different configurations |
| Key management approach | Some teams centralize keys in a shared secrets manager; others have each user generate their own pair |
| Compliance or security requirements | Some environments require disabling password auth entirely, enforcing key rotation, or logging all SSH sessions |
| Instance type | Bare metal instances and VM instances follow the same Linux user management principles, but how you reach them (bastion host, VPN, direct) changes the entry point |
The OCI-Specific Layer Worth Knowing
Oracle Cloud adds a feature called OS Management and also supports cloud-init scripts at instance launch, which can automate user creation at boot. If you're building instances that regularly need pre-configured users, cloud-init can inject authorized keys and create users without any manual SSH session.
Oracle also offers Bastion Service — a managed jump host that lets you create time-limited SSH sessions without exposing your instance's port 22 directly to the internet. If your instance sits in a private subnet, this becomes the primary way you'd access it, and new users would need to be provisioned through bastion sessions.
For teams using OCI's Instance Principal or Service Accounts, the user access model looks different again — those identities are IAM-based and don't map directly to Linux system users at all.
The Spectrum of Setups
A solo developer adding a colleague to a single development instance is a five-minute job following the steps above. A DevOps team managing dozens of instances across multiple availability domains needs a repeatable, auditable process — likely infrastructure-as-code tooling, centralized key management, and access logging.
Between those extremes are configurations involving jump boxes, restricted users with limited command access, service accounts for CI/CD pipelines, and temporary access grants. Each of these scenarios applies the same underlying SSH and Linux user mechanics but layers different tools and policies on top.
Whether the manual approach or an automated one fits your situation depends on the scale of your infrastructure, your team's size, your security posture, and how frequently user access changes. The technical foundations stay consistent — what shifts is how much of that process you manage by hand versus systematically.