Skip to content

Instantly share code, notes, and snippets.

@SpaceShot
Last active February 16, 2022 17:06
Show Gist options
  • Save SpaceShot/edf6e923e08ae6542b1279cce9b208cb to your computer and use it in GitHub Desktop.
Save SpaceShot/edf6e923e08ae6542b1279cce9b208cb to your computer and use it in GitHub Desktop.
Using Native OpenSSH Client in Windows 10

Using Native OpenSSH Client in Windows 10

Overview

Some time ago I needed to ssh into a Linux machine. For eons, a common way to do this way to use PuTTY. The point of this is not to discourage you from using PuTTY. PuTTY is fantastic.

So I had two motivations for checking out the native OpenSSH client in Windows 10:

  1. I heard SSH was now a native, but optional feature.
  2. Using PuTTY is very much a "Windows" thing to do. I wanted to gain a little of that "command line" speed and zen by being able to SSH in from any command prompt.

Why not Git Bash?

The vast majority of developers have Git on their machine and it probably shipped with Git Bash. Many developers erronesouly believe you can only use Git through Git Bash. This is an unnecessary practice that I think really slows you down.

openssl and an open ssl agent are built int, and I was using it happily until I ran into a problem. If Git Bash was closed and reopened (working from memory here), I found I had to essentially set up the openssl agent again with my identities. The key files were fine, but the agent seemed to "reset". Then I noticed it was creating a new instance of the agent process in Windows so there would be dozens. The native client/server had none of these issues, understandably.

Why not WSL?

At the time I wrote this, WSL either wasn't around or was in very early days. WSL2 is pretty nice, and could be a great option. In fact, if you are using SSH from WSL2, it might be the better option. However, I often need key creation and identity support in Windows itself, especially to SSH into another machine, so I would rather not cross the boundary for no reason when I don't have to.

Check if OpenSSH Client is Installed

Quick GUI way

Click the Start button and type Manage Optional Features and Windows will find this for you.

Windows Settings App

Open the Settings App (the look and feel of this changed in Windows 1909 but is essentially the same).

Apps and Features > Manage Optional Features OR Click Start button and type "Manage Optional Features" and Windows will find it for you.

OpenSSH Client is installed

Powershell

# Install ssh client from PowerShell
Add-WindowsCapability -Online -Name OpenSSH.Client*

You could now just begin using ssh right away, until you need key management.

Enable ssh-agent service

(Apparently this is disabled but installed by default in recent versions of Windows 10)

Check if ssh-agent service is Disabled

  • Open an Administrator Powershell.

  • Type Get-Service ssh-agent | select -property name, status, displayname, starttype

Check if the StartType property is set to disabled. If so, you won't be able to start the service.

ssh-agent is Disabled

Enabling the ssh-agent service from PowerShell

You could go find the OpenSSH Authentication Agent service in the GUI, but here's the PowerShell way to enable it:

Set-Service -Name ssh-agent -StartupType Manual

If you want it to start with Windows you could use this instead:

Set-Service -Name ssh-agent -StartupType Automatic

To start the service, use:

Start-Service ssh-agent

List the keys you have added to the agent

ssh-add -l

or

ssh-add -L

Adding an SSH authentication key

Now that the ssh-agent is running, you can utilize ssh-add to add private key based identities to a secure store. After you've done this you could delete the private key from the machine (if you have it backed up somewhere else) so it's not laying around.

You can't use the PuTTY ppk format for this, however.

PS C:\Users\cagom> ssh-add .\sshkey_id

Creating an SSH key pair

Why?

  • So you can set the public key to some machine you want to ssh into.

Easy way

  1. ssh-keygen

More info:

ssh-keygen - Generate a New SSH Key

Login (no tunneling)

If you are given a login name, you have to supply this with the -l parameter so it is passed along when logging in.

Putty lets you supply the name after you start the session. Not so here (that I know of).

ssh X.Y.Z.A -l <login name> -v

Login (tunneling)

ssh X.Y.Z.A -l <login name> -L 127.0.0.1:4443:localhost:4443 -L 127.0.0.1:4200:localhost:4200 -L 127.0.0.1:8888:localhost:8888

Why? If you want to access ports on the remote, you need to tunnel them to your local machine over SSH.
For example, your remote machine might host a service of some kind on a port. By tunneling you can access it as if it were locally hosted.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment