These are my notes (mostly for myself!) on getting SSH authentication through GPG under a variety of Windows 10 environments like native SSH (see c:windowssystem32openssh*), Windows Subsystem for Linux (WSL) and minGW / GIT Bash. Why? So you have a single, GPG based identity on a secure, removable hardware key store like a OpenPGP card (e.g. Yubikey 5) and your SSH keys are based off that GPG identity. No naked RSA SSH keys floating around on disk.

• Git Use Private Ssh Key
• Ssh Command Use Private Key

Sep 18, 2019 It will then use this key to establish a secure SSH connection with the worker nodes, without saving the private key on any master node storage. You can review the copyfile.py on the master node or on GitHub. In the getprivatekey function, you can read the secret value, which includes the private key. If you are running Windows and PuTTYTray for SSH, you can use the built-in key generator from PuTTY to create a new key pair. Click the Keygen button at the bottom of the PuTTY Configuration window to get started. Then in the Key Generator window, check that the Type of key. It will then use this key to establish a secure SSH connection with the worker nodes, without saving the private key on any master node storage. You can review the copyfile.py on the master node or on GitHub. In the getprivatekey function, you can read the secret value, which includes the private key. Use of proper SSH key management tools tools is recommended to ensure proper access provisioning and termination processes, regularly changing keys, and regulatory compliance. SSH keys can be generated with tools such as ssh-keygen and PuTTYgen. These tools ask for a phrase to encrypt the generated key with. PGP / GPG Private Key Protection. The ssh client allows you to selects a file from which the identity (private key) for RSA or DSA authentication is read. The default is /.ssh/identity for protocol version 1, and /.ssh/idrsa and /.ssh/iddsa for protocol version 2. Identity files may also be specified on a per-host basis in the configuration file.

This document does NOT cover generating the GPG keys or moving the GPG profile and keys to the Yubikey. If you want that, see this.

NOTE: Everywhere here, replace sid with your username as appropriate e.g. Emergency 5 crack. c:Userssid becomes c:Users<yourusername>

Overall idea

The core idea is to install and setup gpg natively on Windows 10. We use gpg-agent to perform SSH authentication via the pageant protocol. So we’ll be building bridges (via sockets and named pipes) to make those cross-environment connections. The complexity comes from the fact that the ends of those bridges (sockets and named pipes) are incompatible, the openssh(=non-pageant) ssh authentication protocol is unreliable and there are multiple SSH installations in most cases.

Windows 10 setup

I actually already had gpg4win but it simply wouldn’t prompt me for the GPG PIN i.e. authentication failed no matter what I tried. After struggling for a day with this, I uninstalled it completely and started fresh. In addition to having your private key on the YubiKey, it is highly recommended you have an air-gapped or offline backup of your public and private keys.

1. [Optional] Uninstall gpg4win and then delete the c:Userssid.gnupg and C:UserssidAppDataRoaminggnupg folders.
2. Install gpg4win (download)
3. Re-import your GPG public key and private key into GPG per this guide. The actual private key stays on the OpenPGP card, just a link to it is imported into GPG.
4. Edit %APPDATA%gnupggpg-agent.conf to have
   enable-putty-support
5. Download WSL-SSH-Pageant and install it somewhere e.g. C:toolswsl-ssh-pageant
6. Start the bridge on the Windows side by
   C:toolswsl-ssh-pageantwsl-ssh-pageant-amd64-gui.exe -systray -verbose -wsl C:toolswsl-ssh-pageantwsl-ssh-agent.sock
7. Start Windows’ GPG agent by the following powershell command
   & 'C:Program Files (x86)GnuPGbingpg-connect-agent.exe' /bye

Automating it

To start the above bridge automatically at startup, do this:

1. Open C:UserssidAppDataRoamingMicrosoftWindowsStart MenuProgramsStartup
2. Put one shortcut that runs 'C:Program Files (x86)GnuPGbingpg-connect-agent.exe' /bye
3. Put another shortcut that runs 'C:toolswsl-ssh-pageantstart wsl-ssh-pageant.bat'
4. create a file C:toolswsl-ssh-pageantstart wsl-ssh-pageant.bat which has the following. This ensures that a permanent terminal window isn’t kept dangling

If you don’t have the newer cross platform PowerShell (pwsh) used in the above command, install it from here (preferred) or use the older powershell.exe.

SSH auth in WSL

This routes WSL’s SSH authentication across to GPG’s SSH agent using the bridge we setup earlier

1. Issue this command in a WSL terminal
   export SSH_AUTH_SOCK=/mnt/c/tools/wsl-ssh-pageant/wsl-ssh-agent.sock
2. test with something like ssh sid@lab-linux13-ubuntu18. You should see a GUI PIN prompt on the Windows 10 side

Automating it

Open a WSL terminal, edit ~/.profile file to add

SSH auth in Windows 10

Windows 10 now ships with a native OpenSSH client that lives in c:windowssystem32openssh. If you just want to open a command prompt or powershell window and ssh away, this is for you.

1. Run $env:SSH_AUTH_SOCK='.pipewinssh-pageant' in powershell
2. test with something like ssh sid@lab-linux13-ubuntu18. You should see a GUI PIN prompt on the Windows 10 side

Make GIT use SSH + GPG

Chances are you also want to be able to issue a git command in a regular windows terminal for your work e.g. git fetch. The issue is there are two SSHs even in the pure native Windows 10 side. One in c:windowssystem32openssh and the other installed by GIT at C:Program FilesGitusrbin – and GIT will use it’s version and not the version we just setup above.

To fix that, open a Windows Powershell terminal and type $env:GIT_SSH='C:Windowssystem32OpenSSHssh.exe' and then test it works by issuing git fetch from a suitable git repository (make sure the GIT repo has your corresponding SSH key registered). If all works, you should see the PIN prompt.

Automating it

1. Windows 10 Start Button -> type environment variables -> Edit environment variables for your account -> User variables for sid -> New
2. Name = SSH_AUTH_SOCK and value = .pipewinssh-pageant -> Ok
3. Repeat with Name = GIT_SSH and value = C:Windowssystem32OpenSSHssh.exe -> Ok

SSH auth in Git-Bash (mingw)

When you install git for windows, you get a bash shell that’s based off “Minimalist GNU for Windows” – a minimalist development environment for Windows. GIT runs within that.

1. Run eval $(/usr/bin/ssh-pageant -r -a '/tmp/.ssh-pageant-$USERNAME')
2. test with something like ssh sid@lab-linux13-ubuntu18. You should see a GUI PIN prompt on the Windows 10 side

If you’re using SourceTree, switch to putty SSH authentication and

Automating it

Just add the following to your git-bash’s ~/.bashrc or .profile file

WSL setup for running GPG

If all you care is SSH on WSL using gpg-agent on Windows, then the SSH auth bridge setup above is all you need. You do not need this additional bridge. But if you want to use the gpg binary within WSL (e.g. encrypting files), then you need another bridge to handle the gpg communications into the Windows world.

1. Download npiperelay (link) with GPG support and unzip it to something like c:toolnpiperelaynpiperelay.exe
2. install socat by sudo apt install socat
3. in WSL run (it’s all one line)
   socat UNIX-LISTEN:'$HOME/.gnupg/S.gpg-agent,fork' EXEC:'/mnt/c/tools/npiperelay/npiperelay.exe -ei -ep -s -a 'C:/Users/sid/AppData/Roaming/gnupg/S.gpg-agent',nofork
4. Test by running gpg --card-status in WSL, it should work

Automating it

Add the following to the end of your WSL’s ~/.profile file

Ending comments – Yubico and the state of the ecosystem

Overall, I’m rather disappointed with the quality of software and how they all (don’t) interoperate smoothly. I also contacted Yubico to see if they had any internal documentation since external documentation about this was sparse. Astonishingly their just sent back unrelated links to 3rd party blog posts. If git for Windows, OpenSSH, and GPG don’t work well out of the box, Yubico should be stepping up and providing guidance to smooth that journey since they’re selling security devices that are heavily dependent on that ecosystem.

Troubleshooting

Www thq com wwe13 free download. Windows 10’s default OpenSSH authentication agent was disabled but it is unclear if this is a necessary requirement.

Start button-> Services -> OpenSSH Authentication Agent -> Stop

More Linux resources

If you have ever worked as a sysadmin (or you want to in the future), you need a good grasp of SSH. I will not run you through the general concept as it has already been hashed out here at Enable Sysadmin. However, I do want to look at a potentially better way to use it. SSH is the single most used remote access protocol in the world. Therefore, it makes sense that we should try to improve its use as much as possible.

I used SSH to remotely connect to thousands of customer machines during my time as a support engineer, and I am sure that others have had a similar experience. With traditional SSH authentication, you need the username and password for the account you want to log in to every time that you wish to access a system. Doesn't sound that bad, right? But, what happens when you need to jump back and forth between systems regularly? Or what if your responsibilities include remote sessions to the same 100 systems throughout the day for health checks? There is another way to accomplish the log in, and with a little upfront investment, it can be far more efficient overall.

Process hardening

It is objectively true that an encrypted key is a much harder target than a username and password for those with ill intentions. Although it can take a little learning, creating and using SSH key-based authentication is worth the investment for every sysadmin.

Here is how it works. You generate a public key and a matching private key. The private key file acts as a password and should be kept safe. However, the public key is copied to the target systems that you connect to regularly. You place the public key in your account home directory on the target server. When you try to log in, the keys are verified, and access is granted.

Now, there are two ways that you can do this. One is more convenient, and the other is a bit tedious but with added protection to you. The convenient way is not to specify a password along with the private key. The result is that you do not have to enter a password when you use your private key for authentication. This means that if someone gets their hands on your private key, they can use it to authenticate, as well. The other method is to password-protect your private key so that you are prompted for the password when authenticating (think two-factor authentication using both the private key and the password).

ssh-keygen without a password

To generate an SSH key pair, use the following command:

By default, your private and public keys are saved in your ~/.ssh/id_rsa and ~/.ssh/id_rsa.pub files, respectively.

ssh-keygen with a password

Creating a password-protected key looks something like this:

Use the -f option to specify the file where the keys will be saved. In the example above, the private and public keys are stored in the /home/user/.ssh/key-with-pass and /home/user/.ssh/key-with-pass.pub files, respectively.

Warning

During further SSH key pair generation, if you do not specify a unique file name, you are prompted for permission to overwrite the existing id_rsa and id_rsa.pub files. If you overwrite the existing id_rsa and id_rsa.pub files, you must then replace the old public key with the new one on ALL of the SSH servers that have your old public key.

Once you have generated the keys, they are stored in the /user/home/.ssh/ directory with the following permissions:

• Private key - 600
• Public key - 644

You aren't done yet. Let's look at the final step in successful SSH key-based authentication.

Git Use Private Ssh Key

Sharing keys

For all of this to work, you need to share your public key with the remote machines you are trying to SSH to. Use the ssh-copy-id command to copy your public key over to the destination system. By default, the file path is /home/user/.ssh/id_rsa.pub. You issue the command, specify the file you are sharing, then the user/host we are sharing it with. It should look like this:

Ssh Command Use Private Key

Now that you have shared the public key with the destination host, you can authenticate to the remote server by passing the matching private key. If you specified a file path for your private key, you need to give it here. Otherwise, it defaults to /home/_user_/.ssh/id_rsa.

Seen here:

Advantages and summary

The advantages of using SSH key-based authentication are clear. Passwords are stolen every day, mainly due to human error but also due to attacker skill and determination. An encrypted key, and more specifically, a password-protected encrypted key, makes your SSH authentication even more difficult to attack. You still need to strike a balance of availability and security, but that is handled differently in every environment.

[ Free online course: Red Hat Enterprise Linux technical overview. ]