SSH Like a Pro: Creating an Isolated User on an EC2 Instance (Without Breaking Anything)

Posted on by — No Comments ↓

If you’ve ever deployed more than one project on a single server, you’ve probably felt this tension:

“I don’t want this new thing to interfere with what’s already running.”

That’s exactly the situation I found myself in.

I had:

  • an existing EC2 instance
  • a main user running a larger project
  • and a new, smaller service I wanted to deploy cleanly and safely

The solution wasn’t Docker or Kubernetes.

It was something much simpler — Linux users + SSH keys, done properly.

This post walks through:

  • why creating a separate user matters
  • how SSH authentication actually works
  • and how to log in as a new user securely, without passwords

The Goal

I wanted to:

  • create a new Linux user (cc)
  • isolate a new project under that user
  • log in directly as cc using SSH
  • keep everything secure and professional

No hacks. No shortcuts.

Step 1: Create a New User

First, SSH into the server as your existing user: 

ssh your-current-user@your-ec2-ip

Then create a new user: 

sudo adduser cc

You’ll be prompted to set a password and optional user details.
You can safely skip the extra fields.

Optionally (but recommended), give the user sudo access: 

sudo usermod -aG sudo cc

At this point, cc exists — but you cannot SSH into it yet.

Step 2: Understand What SSH Actually Authenticates

This is where most confusion happens.

SSH does not authenticate repositories.
It does not authenticate servers.
It authenticates users.

More specifically:

SSH proves that you own a private key, and the server checks whether the matching public key is allowed to log in as a specific Linux user.

Each user has their own allowlist: 

~/.ssh/authorized_keys

If a public key is not listed there → no login.

A brand-new user like cc has an empty allowlist.

Step 3: Identify the Correct SSH Key

On your local machine, test your existing SSH connection with verbosity enabled: 

ssh -v your-current-user@your-ec2-ip

Look for a line like: 

Offering public key: ~/.ssh/backend-key

This tells you:

  • which private key your laptop is using
  • and therefore which public key represents you

The matching public key is: 

~/.ssh/backend-key.pub

This is the only key you should use.

Step 4: Allow That Key to Log In as cc

On the server, create the SSH directory for the new user: 

sudo mkdir -p /home/cc/.ssh
sudo chmod 700 /home/cc/.ssh
sudo chown cc:cc /home/cc/.ssh

Now create the authorization file: 

sudo nano /home/cc/.ssh/authorized_keys

Paste the entire contents of your local backend-key.pub file into it.

Then fix permissions (this part is critical): 

sudo chown cc:cc /home/cc/.ssh/authorized_keys
sudo chmod 600 /home/cc/.ssh/authorized_keys

Step 5: Log In as the New User

From your local machine: 

ssh cc@your-ec2-ip

If everything is set up correctly, you’re in 🎉

You can confirm with: 

whoami
pwd

You should see: 

cc
/home/cc

“Why Can I Log In Without a Password?”

This surprises a lot of people — but it’s actually the point.

You are not logging in “without authentication”.
You are authenticating with cryptography, not passwords.

SSH keys are:

  • resistant to brute force
  • resistant to phishing
  • industry standard in cloud environments

This is more secure than password-based SSH.

If you want extra protection:

  • disable password SSH entirely
  • keep passwords for sudo only

That’s how most production systems are set up.

Optional: Clean Up Your Local SSH Config

To keep things tidy, you can name this connection in ~/.ssh/config: 

Host cc-ec2
    HostName your-ec2-ip
    User cc
    IdentityFile ~/.ssh/backend-key

Now you can simply run: 

ssh cc-ec2

Clear, explicit, and hard to mess up.

Why This Setup Is Worth It

By doing this, you get:

  • full isolation between projects
  • separate environments and dependencies
  • smaller blast radius if something breaks
  • a setup that scales with you

You didn’t just “make SSH work”.

You set up your server the way professionals do.

Final Thoughts

This entire process has nothing to do with Git repos and everything to do with identity and trust.

Once that mental model clicks, SSH stops feeling magical — and starts feeling solid.

If you run multiple services on one server, this pattern will serve you for years.

Happy hacking 🚀

Leave a Reply