sshOpenSSH client for Windows

Purpose

ssh opens a secure, encrypted connection to a remote host: an interactive shell, a single command, or a tunnel carrying other traffic. Everything travels over port 22 inside SSH's encryption, so it is safe across untrusted networks. The concepts are in encryption in transit and authentication basics.

Connect

ssh [email protected]
ssh -p 2222 [email protected]

The first time, ssh shows the server's host-key fingerprint and asks you to confirm; it is stored in %USERPROFILE%\.ssh\known_hosts.

Key authentication

ssh-keygen -t ed25519 -C "you@workstation"
type %USERPROFILE%\.ssh\id_ed25519.pub | ssh user@host "cat >> ~/.ssh/authorized_keys"
ssh -i %USERPROFILE%\.ssh\id_ed25519 user@host

Key authentication is stronger than passwords and required for automation. Private key files must have tight permissions or OpenSSH refuses them; the chmod calculator explains the Unix side, and on Windows the file must not grant read access to other users.

Run one command

ssh user@host "df -h && uptime"

Port forwarding

ssh -L 5901:localhost:5900 user@host
ssh -L 3307:db-internal:3306 user@jump-host

The first tunnels a local port 5901 to the remote host's VNC port; the second reaches a database (3306) that only the jump host can see. This is the safe way to reach services that should not be exposed directly.

Troubleshooting

ssh -v user@host

-v (or -vv, -vvv) prints the negotiation: which key methods were tried, why authentication failed, the server version. Before blaming ssh, confirm the port is reachable:

Test-NetConnection host.example.com -Port 22

See Test-NetConnection.

Common mistakes

• Loose key-file permissions. ssh ignores a private key other users can read.
• Confusing the client and server. The ssh command is the client; to accept incoming connections the machine needs the OpenSSH server feature installed and running.
• Removing a known_hosts entry without verifying the new fingerprint, which defeats the protection against machine-in-the-middle attacks.