How to SSH Into a Linux Server from Windows

SSH is how you open a secure command-line session on a remote Linux server.

If you are on Windows, the basic command looks like this:

ssh username@server-address

For example:

ssh [email protected]
ssh [email protected]

That is the short version. Type the command, accept the host key the first time, enter the password or use your SSH key, and now you are typing commands on the Linux server instead of your Windows laptop.

The part beginners trip over is not usually the command itself. It is the surrounding stuff: which username to use, whether the server allows passwords, why the terminal says “connection refused,” why the password prompt looks frozen, or why pasting a command from a ticket suddenly feels like defusing a printer that has personally wronged you.

This guide walks through SSH from Windows in a help desk friendly way: what to install, what command to run, what the prompts mean, and how to troubleshoot the common errors without randomly changing firewall rules until something catches fire.

What you need before you SSH

Before touching the terminal, collect four things:

Thing you need	Example	Where it usually comes from
Server address	192.168.1.50 or web01.example.com	Ticket, admin, cloud console, inventory system
Username	alex, support, ubuntu, ec2-user	Admin docs, onboarding notes, server image default
Authentication method	Password or SSH key	Ticket, password vault, cloud provider, admin
Network access	VPN, office network, allowed IP	VPN client, firewall rules, jump box

Do not skip the network access part. If the Linux server is private and you are sitting at home without VPN, SSH will not work no matter how confidently you squint at PowerShell.

Step 1: Open Windows Terminal or PowerShell

Modern Windows includes an OpenSSH client by default. The easiest place to use it is Windows Terminal.

Open one of these:

• Windows Terminal
• PowerShell
• Command Prompt

Then check whether SSH is available:

ssh -V

You should see output similar to:

OpenSSH_for_Windows_9.5p1, LibreSSL 3.8.2

If Windows says ssh is not recognized, install the OpenSSH Client:

1. Open Settings.
2. Go to System → Optional features.
3. Search for OpenSSH Client.
4. Install it.
5. Reopen Windows Terminal and try ssh -V again.

In managed work environments, software policies may hide or block this. If so, ask for the OpenSSH Client or use the approved terminal tool your team already supports.

Step 2: Connect with username and server address

The normal SSH format is:

ssh username@server-address

Examples:

ssh [email protected]
ssh [email protected]
ssh [email protected]

If the server uses the default SSH port, that is all you need.

The default SSH port is 22.

If your server uses a custom port, add -p:

ssh [email protected] -p 2222

That uppercase/lowercase detail matters: -p is the port option for ssh. Do not use random examples from scp or other tools and assume every option means the same thing.

Step 3: Understand the first host key prompt

The first time you connect to a server, you may see this:

The authenticity of host '192.168.1.50 (192.168.1.50)' can't be established.
ED25519 key fingerprint is SHA256:abc123...
Are you sure you want to continue connecting (yes/no/[fingerprint])?

This is normal on first connection. SSH is asking whether you trust that this server is really the server you meant to connect to.

If this is a lab machine, a fresh VM, or a server your team just created, typing yes is often fine.

In a real company environment, especially production, you should verify the fingerprint when possible. That might mean checking documentation, asking the server owner, or comparing against your cloud console.

After you type yes, Windows saves the host key in your known hosts file. Future connections will not ask again unless the server key changes.

The beginner mistake: seeing a scary paragraph and blindly typing whatever makes it go away. Do not train yourself to treat security prompts like cookie banners.

Step 4: Enter your password or use your SSH key

If the server allows password login, you will see a password prompt:

support@server01's password:

When you type, the cursor may not move. That is normal. Linux password prompts usually do not show dots, stars, vibes, or emotional support.

Type the password and press Enter.

If the server uses SSH keys, you might connect without a password prompt, or you may be asked for the passphrase that unlocks your private key.

A private key is usually stored somewhere like:

C:\Users\YourName\.ssh\id_ed25519

If you need to specify a particular key file, use -i:

ssh -i C:\Users\YourName\.ssh\work-server-key [email protected]

If the path has spaces, wrap it in quotes:

ssh -i "C:\Users\YourName\.ssh\work server key" [email protected]

Do not email private keys to yourself. Do not paste them into tickets. Do not put them in Teams because “it is just internal.” That is how future-you gets a meeting titled “quick sync” with too many managers on it.

Step 5: Know when you are on the Linux server

After a successful login, your prompt changes. It may look like:

support@web01:~$

That means your commands now run on the remote Linux server.

Try a few safe read-only commands:

whoami
hostname
pwd
ls
uptime

What they do:

Command	Why it helps
whoami	Confirms which Linux user you logged in as
hostname	Confirms which server you are on
pwd	Shows your current directory
ls	Lists files in the current directory
uptime	Shows how long the server has been running and load averages

Run hostname before doing anything risky. It is boring, and that is the point. Boring checks prevent “oops, wrong server” moments.

Step 6: Leave the SSH session safely

To close the SSH session, run:

exit

Or press:

Ctrl+D

Your prompt should return to PowerShell or Windows Terminal on your local machine.

If your SSH session freezes, try pressing Enter first. If the network dropped, you can use the SSH escape sequence:

Enter
~.

That means press Enter, then type tilde and period. It closes a stuck SSH client session.

Common SSH errors from Windows

SSH errors look mean, but most of them point to a specific problem.

Connection timed out

Example:

ssh: connect to host 203.0.113.10 port 22: Connection timed out

Usually means your Windows machine cannot reach the server on that port.

Check:

• Are you on VPN?
• Is the server powered on?
• Is the server address correct?
• Is SSH allowed through the firewall?
• Does your current network block outbound SSH?

Useful Windows test:

Test-NetConnection 203.0.113.10 -Port 22

If TcpTestSucceeded is False, SSH is not reachable from where you are.

Connection refused

Example:

ssh: connect to host 203.0.113.10 port 22: Connection refused

This usually means the server is reachable, but nothing is accepting SSH on that port.

Possible causes:

• SSH service is not running.
• SSH is listening on a different port.
• The firewall is rejecting the connection.
• You have the wrong server.

On the Linux side, an admin might check:

sudo systemctl status ssh
sudo systemctl status sshd
sudo ss -tlnp | grep ':22'

Different distributions name the SSH service differently. Debian and Ubuntu often use ssh; RHEL-style systems often use sshd.

Permission denied

Example:

Permission denied, please try again.

This means you reached SSH, but authentication failed.

Check:

• Did you use the right username?
• Are you using the right password?
• Does the server allow password login?
• Does your public key exist in ~/.ssh/authorized_keys for that user?
• Are you accidentally trying admin when the cloud image expects ubuntu or ec2-user?

Username mistakes are extremely common. The server can be perfectly healthy while you are politely knocking on the wrong account.

Permission denied (publickey)

Example:

Permission denied (publickey).

This means the server expects an SSH key and did not accept the key you offered.

Try specifying the key directly:

ssh -i C:\Users\YourName\.ssh\work-server-key [email protected]

You can also run verbose mode to see which keys SSH tries:

ssh -v [email protected]

Verbose mode is noisy, but helpful. Look for lines about Offering public key and Authentications that can continue.

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED

This one deserves attention.

Example:

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!

It means the saved host key for that server no longer matches what the server is presenting now.

Sometimes this is harmless: the server was rebuilt, the IP was reused, or a lab VM was recreated.

Sometimes it is not harmless: you may be connecting to a different machine than you think.

Do not automatically delete the known hosts entry on a production system just to make the warning disappear. Verify why the key changed.

On Windows, known hosts usually lives here:

C:\Users\YourName\.ssh\known_hosts

If you confirm the change is expected, you can remove the old key with:

ssh-keygen -R server01.company.com
ssh-keygen -R 203.0.113.10

Then connect again and accept the new host key.

A beginner-safe SSH workflow for support tickets

When a ticket says “SSH into the server and check it,” use a simple workflow:

1. Confirm the server name or IP.
2. Confirm you are on VPN or the right network.
3. Connect with ssh username@server.
4. Run hostname and whoami.
5. Run only read-only checks first.
6. Save command output in the ticket.
7. Escalate before restarting services, changing files, or deleting anything.

Good first checks:

hostname
whoami
uptime
df -h
free -h
systemctl --failed

Those commands tell you where you are, who you are, how loaded the server is, whether disk space is a problem, whether memory is tight, and whether systemd sees failed units.

If you need logs:

journalctl -p warning --since "1 hour ago"

If you are checking a specific service:

systemctl status nginx
journalctl -u nginx --since "30 minutes ago"

Swap nginx for the actual service name. Guessing service names is normal. Pretending you did not guess is optional but traditional.

Windows Terminal tips that make SSH less annoying

A few small habits help a lot.

Use copy/paste carefully

Windows Terminal can paste long commands into the remote Linux shell. That is useful, but dangerous if you paste a command you do not understand.

Before pressing Enter, read the command. Especially if it includes:

• sudo
• rm
• chmod -R
• chown -R
• curl ... | bash
• anything that edits files under /etc

The terminal will not know you were “just following the ticket.” It will simply do the thing.

Keep server notes somewhere sane

For repeated servers, keep approved connection notes:

Server: web01
Address: web01.company.local
User: support
Auth: SSH key from password vault
Port: 22
VPN required: yes

Do not store passwords in random markdown files or sticky notes. Connection notes are fine. Secrets belong in the password vault.

Use SSH config for servers you connect to often

Once you are comfortable, you can create an SSH config file at:

C:\Users\YourName\.ssh\config

Example:

Host web01
  HostName web01.company.local
  User support
  Port 22
  IdentityFile C:\Users\YourName\.ssh\work-server-key

Then you can connect with:

ssh web01

This is not required for beginners, but it reduces typo risk once you manage more than a couple servers.

What to practice next

SSH is not really one skill. It is the doorway to the rest of Linux support work.

Once you can connect, practice:

• Moving around with pwd, ls, and cd.
• Checking disk space with df -h and du -sh.
• Reading logs with journalctl and tail.
• Checking services with systemctl.
• Finding text with grep.
• Knowing when not to run sudo just because a command failed.

That is where Shell Samurai fits nicely: it gives you a safe place to build the command-line muscle memory before your first real production SSH session feels like someone handed you root access and a live grenade.

Practice Linux commands in Shell Samurai before you SSH into a real server.

Quick SSH from Windows cheat sheet

Task	Command
Check SSH client version	ssh -V
Connect to server	ssh username@server-address
Connect on custom port	ssh username@server-address -p 2222
Use a specific key	ssh -i C:\Users\You\.ssh\keyfile username@server
Run verbose troubleshooting	ssh -v username@server
Test port 22 from Windows	Test-NetConnection server-address -Port 22
Remove stale host key	ssh-keygen -R server-address
Leave remote session	exit

FAQ

Can I SSH from Windows without PuTTY?

Yes. Modern Windows includes OpenSSH, so you can SSH from Windows Terminal, PowerShell, or Command Prompt with the ssh command. PuTTY still exists and some teams use it, but it is no longer required for basic SSH access from Windows.

What username should I use for SSH?

Use the account your team or server provider gave you. Common cloud defaults include ubuntu, ec2-user, admin, and sometimes root, but do not guess on production. The wrong username can make a working server look broken.

Why does my password not show while typing?

That is normal. SSH password prompts usually do not display characters, dots, or stars. Type the password and press Enter.

Is SSH safe over the internet?

SSH is encrypted, but that does not mean every SSH exposure is a good idea. Production servers should use strong authentication, patched SSH services, firewall rules, least-privilege accounts, and ideally VPN or restricted source IPs.

Should beginners use SSH keys or passwords?

For real work, SSH keys are usually better than passwords when managed properly. Beginners should first understand the login flow, then learn key basics: private key stays private, public key goes on the server, and passphrases protect private keys if the file is stolen.