Copying an SSH Key from Windows to a Debian Server

Once key-based SSH authentication is in place you'll never type a password for that machine again. This guide covers copying an existing SSH public key from a Windows workstation to a Debian-based server - the quick way and the manual way - plus hardening steps to lock it down afterwards.

🔍Sanity Checks (Do This First)

Before anything else, confirm you actually have an SSH keypair on the Windows side.

1
Check for an existing keypair
Open PowerShell and list the .ssh directory:
shell
```
dir $env:USERPROFILE\.ssh
```
You should see one of:
- id_ed25519 + id_ed25519.pub — preferred (modern, fast, compact)
- id_rsa + id_rsa.pub — older but still widely supported
2
Generate a keypair if you don't have one
If no keypair exists, generate one now. Accept the default file location and optionally set a passphrase:
bash
```
ssh-keygen -t ed25519 -C "your-name@windows"
```
ℹ️
Ed25519 keys are shorter, faster, and more secure than RSA. Use them unless you have a specific compatibility reason not to.

🚀Method A - ssh-copy-id (Recommended)

The ssh-copy-id command reads your public key, connects to the server, creates the correct directories and files with the right permissions, and appends the key — all in a single step.

⚠️

Windows note: The ssh-copy-id command is not available in PowerShell by default. Run it from a Bash-compatible terminal on Windows such as Git Bash, which ships with Git for Windows.

1
Copy the public key to the server
From a Bash terminal (e.g. Git Bash), run:
bash
```
ssh-copy-id <user>@<server-ip>
```
Enter the remote user's password when prompted. This is the last time you'll need it.
2
Test passwordless login
bash
```
ssh <user>@<server-ip>
```
If you land on the remote shell without a password prompt — you're done. Skip ahead to the Hardening section.

✅

That's it. One command, correctly permissioned files, no manual steps. This is the recommended path.

🔧Method B - Manual Install (Explicit & Bullet-Proof)

Use this if ssh-copy-id is unavailable or you want full control and understanding of what's happening under the hood.

1
Copy the public key contents on Windows
In PowerShell, print the key:
shell
```
type $env:USERPROFILE\.ssh\id_ed25519.pub
```
You'll see a single line like:
text
```
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... your-name@windows
```
Copy the entire line to your clipboard.
2
SSH into the server (password login, one last time)
bash
```
ssh <user>@<server-ip>
```
3
Create the SSH directory with correct permissions
On the remote server, run:
bash
```
mkdir -p ~/.ssh
chmod 700 ~/.ssh
touch ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
```
⚠️
These permissions are critical. SSH will silently refuse key authentication if the directory or file permissions are too open.
4
Paste the public key
Open the authorized keys file in an editor:
bash
```
nano ~/.ssh/authorized_keys
```
- Paste the public key on a single line
- Save and exit (Ctrl+O, Enter, Ctrl+X)
5
Fix ownership
Ensure the .ssh directory is owned by the correct user:
bash
```
chown -R <user>:<user> ~/.ssh
```
6
Test from Windows
bash
```
ssh <user>@<server-ip>
```
No password prompt = success.

🐛Troubleshooting

Still being asked for a password? Work through these common failure points:

Check SSH Server Config

On the Debian server, open the SSH daemon configuration:

bash

sudo nano /etc/ssh/sshd_config

Ensure the following lines are present and not commented out:

text

PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

Then restart the SSH service:

bash

sudo systemctl restart ssh

Verify Permissions (Most Common Mistake)

Incorrect permissions are the number-one reason key auth silently fails:

bash

ls -ld ~ ~/.ssh ~/.ssh/authorized_keys

Expected output:

text

drwx------  <user> <user>  /home/<user>/.ssh
-rw-------  <user> <user>  /home/<user>/.ssh/authorized_keys

ℹ️

The home directory itself should not be world- or group-writable either. chmod 755 ~ or stricter is fine.

🔒Hardening (Strongly Recommended)

Once you've confirmed key-based login works, disable password authentication to close off brute-force attack vectors entirely.

🚨

Only do this after you have verified key login works. If you disable password authentication first, you will lock yourself out of the machine.

1
Edit the SSH daemon config
bash
```
sudo nano /etc/ssh/sshd_config
```

Set the following directives

text

PasswordAuthentication no
PermitRootLogin no

3
Restart the SSH service
bash
```
sudo systemctl restart ssh
```
From this point on, only machines whose public keys are in authorized_keys can connect.

⚡Optional: Per-Host SSH Config on Windows

Save yourself from typing full connection strings every time by defining a host alias in your local SSH config.

1
Open (or create) the SSH config file
shell
```
notepad $env:USERPROFILE\.ssh\config
```

Add a host block

text

Host myserver
  HostName <server-ip>
  User <user>
  IdentityFile ~/.ssh/id_ed25519

3
Connect using the alias
bash
```
ssh myserver
```
Clean. Elegant. No more remembering IPs or usernames.

📋Quick Reference

Fastest path (from Git Bash on Windows):

bash

# Copy key to server (one-time)
ssh-copy-id <user>@<server-ip>

# Connect — no password needed
ssh <user>@<server-ip>

✅

In Summary: Use ssh-copy-id from Git Bash for the fastest setup, or install the key manually for full control. Then disable password authentication on the server and optionally set up a host alias for effortless connections.

Filed under: SSH, Security, Windows, Debian, Linux, Key Authentication, Infrastructure, Home Lab