Services Spotlight:

Guide To Setting Up SSH on Windows 7

Written By Corlew Solutions
Updated February 9, 2015
Published March 7, 2014
Why Corlew Solutions?

We write great software and provide amazing technical support. Contact us today if you need help with a software project:

  • Website: Send an inquiry
  • Email:

Article Technology Info

This article discusses the following technologies:

Supporting Editors & Tools

The following tools are used in this article:

  • GitBash - Linux Command Line Shell for Windows

This article will guide you through the process of installing and configuring SSH for use on Windows 7 (32 bit and 64 bit) machine. We assume you are just getting started with SSH or need a bit of a refresher.

In order to use SSH, it will obviously need to be installed on your system. We will install SSH by installing the Git source control application which comes bundled with OpenSSH (an open source implementation of SSH) and Git Bash (a command line tool that will allows Linux-like commands to be executed on Windows). We will not be covering Git in this tutorial or spend any time configuring it for proper use, but it gives us a quick way to get up and running. If you really really don’t want Git on your system, you can head over to the OpenSSH for Windows Download page, and grab another application which bundles OpenSSH..

Let’s get started.

Initial Setup

A Note About the Home Directory

In *Nix based operating systems, the ~ represents the home directory of the logged in user. For Windows 7 this equates to C:\Users\{username} where {username} is the name of the currently logged in user.

Install Git, GitBash and OpenSSH

If you haven’t already installed Git, head over to the Git SCM Website, download the Windows installer and run it. If you would like more help on configuring Git for Windows 7, check out our tutorial - How To Install Git 1.9.X on Windows 7.

Erase SSH settings

This section will explain how to erase all of your SSH settings and start over if you already had SSH working on your system. It’s completely optional and you can safely skip it if you’re starting from scratch, but we have included it in case you would like to “reset” and start over at some point.

As a precaution, you may want to copy the contents of ~/.ssh to a new directory just in case you need to reference something later. In particular, the ~/.ssh/confg (if it exists), contains settings you might want to keep around if you manually entered them into the file.

To create a backup copy, execute:

cp -r ~/.ssh ~/.ssh.bak

Next remove all of the files inside of the ~/.ssh directory:

rm ~/.ssh/known_hosts #Deletes hosts your machine has previously connected to
rm ~/.ssh/id_rsa #Deletes your RSA private key
rm ~/.ssh/  #Deletes your RSA public key
rm ~/.ssh/id_dsa #Deletes your DSA private key
rm ~/.ssh/  #Deletes DSA your public key
rm ~/.ssh/config #Deletes the SSH config file

Some or all of those files may not exist. known_hosts will automatically be recreated as you use SSH and is completely safe to remove. config contains configuration settings for SSH and hosts you want to connect to; it will also be regenerated if needed (but any manual settings that were added will be lost). The *_rsa* and *_dsa* files are you public and private keys. These can also be regenerated, however, if you were using them in the past, this will break the connection to those servers; you will need to reinstall the new public keys on the servers/services you use (as shown below).

Finally, remove any saved identities from ssh-agent (see Configuring SSH-Agent below for more information).

ssh-add -D  # Deletes any stored SSH information that has been recently used

If you get an error stating Could not open a connection to your authentication agent, then ssh-agent is not running (see the Configuring SSH-Agent section below for more info about ssh-agent). To fix this, run the following command to start ssh-agent and rerun the delete command:

eval `ssh-agent -s` # Start ssh-agent - note the ticks in the command
ssh-add -D # Deletes any stored SSH information that has been recently used

Verify SSH is Working

This section will walk you through a couple checks to make sure SSH is running and working on your system.

Is SSH Running?

First, let’s see if SSH is running. Open up GitBash and execute:

ssh -v

You should get something similar to the following output:

OpenSSH_4.6p1, OpenSSL 0.9.8e 23 Feb 2007
usage: ssh [-1246AaCfgkMNnqsTtVvXxY] [-b bind_address] [-c cipher_spec]
           [-D [bind_address:]port] [-e escape_char] [-F configfile]
           [-i identity_file] [-L [bind_address:]port:host:hostport]
           [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port]
           [-R [bind_address:]port:host:hostport] [-S ctl_path]
           [-w local_tun[:remote_tun]] [user@]hostname [command]

Can We Connect To A Server Via Password?

Our ultimate goal is to be able to use SSH to connect to a server using public/private key authentication. However, we can also use a regular old username and password with SSH as well. Let’s give that a shot and make sure SSH is able to connect. You will need a username and password to run this test. Open GitBash and execute:

ssh #user should be the name a username that is allowed to login to your server

You should receive something similar to the following message:

The authenticity of host ' (ipaddress)' can't be established.
RSA key fingerprint is fe:24:18:e5....
Are you sure you want to continue connecting (yes/no)?

Go ahead and type yes. You’ll get a message about the server being added to the list of known hosts and the connection being closed. At this point, if you’re curious, you can open up the ~/.ssh/known_hosts file and it will have a line in there for your server.

Depending on your version of SSH, the system may be waiting for you to enter your password or you may have been returned to the command prompt. If it is waiting for your password, type it now, otherwise, rerun the ssh command and then enter your password and press Enter. The password is the one that corresponds to the username on the server.

If all is working properly, you will login to the server and your command prompt will change. Type exit to logout and return to your local machine’s command prompt.

At this point, we have established that you can connect to your server via SSH using a regular password for the user account. Let’s take things a step further and authorize by a public/private key pair instead of that archaic password. To do that, we need to first create the keys.

Generate Public & Private SSH Keys

SSH can use a public and private key to authenticate instead of a username and password. The public key gets stored on a server you would like to connect to and the private key remains on your personal device/computer. Public keys are visible to everyone and they contain encrypted information that can (theoretically) only be unlocked with your private key.

Look for Existing SSH Keys

The first step is to see if you have existing keys on your computer. Execute the following commands to view your keys:

cd ~/.ssh
ls -la

If you see files called or, then you already have public keys defined. id_rsa is your private key. You can delete these files (if they exist) and generate new keys below, or use them. Note: If you delete them, you will need to upload the new public key on any services that were using the old public key .

Generate New SSH Keys

You may choose to use either the RSA or DSA algorithms when creating your key and you can give your key any label you like. The question of which algorithm is better is debatable, but after a little Googling you will probably find more people recommending RSA (and DSA was created by the NSA which clearly cannot be trusted any more).

The command below creates keys using the RSA algorithm with your email address as the label. In the command -t rsa specifies the type of encryption to use which could be changed to -t dsa if desired. The -C option attaches a comment/label that services can read and display on their system to give your public key some context in chase you’re using more than one public/private key. You can let the keygen create a default label for you by removing the -C option. The keygen script will build a label for you that will look something like username@network_name.

Start the key generation process by executing:

ssh-keygen -t rsa -C "your_email_address_here_or_other_identifier"

You will be prompted for the name of the file. You can either accept the default of id_rsa or give it a new name. It doesn’t matter. It’s the encrypted data inside the files that matter. id_rsa is a sensible default as it will save you from having to type in the file name in other places since most tools assume the default file name.

Next, you’ll be asked to enter a passphrase if you want one. It is highly recommended that you use a passphrase. SSH can use public/private keys without without a passphrase, but consider the case where your machine is physically compromised. Someone will be able to access your remote computers and services directly using your passphrase-less SSH keys. Passphrases give you an extra layer of security.

Enter passphrase (empty for no passphrase): # Type your passphrase
Enter same passphrase again:  # Type your passphrase again

The key generation script will finish and you will see the final output:

Your identification has been saved in /c/Users/you/.ssh/id_dsa.
Your public key has been saved in /c/Users/you/.ssh/
The key fingerprint is:
15:64:c6:85:bf:45:99:1e:9a:9b:5e:57:87:95:47:e0 your_label_here

At this point, your keys have been generated and the key files are located in the ~/.ssh folder. You may be wondering if you’ll have to type your passphrase every time you use SSH. Fortunately, we will be adding some configuration that will limit the number of times you will need to enter your passphrase.

A Note About Multiple Keys

You can create as many public/private key pairs as you like. You may for instance install one public key on one remote machine and install a second public key on another machine. To do this, you would simply run the ssh-keygen command multiple times, supplying a different file name and comment/label each time.

Configuring ssh-agent

Even though you have created a public and private key, they are unusable at this point. You may want to define a bunch keys, but only activate certain ones. This is where the ssh-agent tool comes into play; it holds a list of identities that are allowed to authenticate. It also helps manage the passphrase so you don’t have to type it in every time. When you are prompted at various points for your passphrase, that information gets stored in the ssh-agent for a period of time. The ssh-agent can be configured to re-ask after a set period of time, or remember until the user logs out or the computer is shut down.

Manually Start the Agent

Before we can use the agent we have to start it by executing:

eval `ssh-agent -s`  # Note the tick marks in the command.  This should respond with "Agent pid xxxxx"

The agent will stay running until it is killed or GitBash is closed. A little later, we will configure ssh-agent to automatically start when GitBash is opened.

Keep the agent running for now since we need to use it. In the future, you can manually stop ssh-agent by executing:

ssh-agent -k # Stops ssh-agent

Add Identities

Let’s start by clearing out the identities in your ssh-agent so we have a clean slate. ssh-add is the tool that is used to add and remove RSA or DSA identities from/to the agent.

First let’s remove all known identities from ssh-agent and start fresh.

ssh-add -D  #Erases ssh-agent identities

Now let’s list the identies known by the ssh-agent:

ssh-add -l  # Lists fingerprints of all identities currently represented by the agent.
The agent has no identities.

Now that we have a public/private key pair, we can add our identity to the agent. The following command will look for a file named ~/.ssh/id_rsa or ~/.ssh/id_dsa. If you want to add a different identify, simply add the path to the private key file name:

ssh-add  #If you gave a specific file name, you will need to use ssh-add ~/.ssh/private_key_file_name

With your identity added, the ssh-add -l command will now show that it knows about your private key.

ssh-add -l
#2048 d6:fb:0f:75:db:24:a5:97:55:d4:48:f6:7c:65:e5:c4 /c/Users/you/.ssh/id_rsa (RSA)

In the future, when you try to connect to a server that has the public key installed, you will be prompted for the passphrasefor the corresponding private key. If the private key identity is removed from the ssh-agent and you try to connect to a server, SSH will try to connect you via a normal username/password for the server.

Start SSH Agent when GitBash Opens

GitHub and Bitbucket provide scripts that load the SSH agent when GitBash starts and keeps it around until you logout, shutdown or kill the agent. This will dramatically decrease the number of times you need to enter the passphrase.

First, create a .bashrc file:

touch ~/.bashrc

Open the file with your favorite text edtior and paste the following script which comes from BitBucket:


# start the ssh-agent
function start_agent {
    echo "Initializing new SSH agent..."
    # spawn ssh-agent
    /usr/bin/ssh-agent | sed 's/^echo/#echo/' > "${SSH_ENV}"
    echo succeeded
    chmod 600 "${SSH_ENV}"
    . "${SSH_ENV}" > /dev/null

if [ -f "${SSH_ENV}" ]; then
     . "${SSH_ENV}" > /dev/null
     ps -ef | grep ${SSH_AGENT_PID} | grep ssh-agent$ > /dev/null || {

Now, close GitBash and reopen it. The SSH Agent will automatically add your identify (you may be prompted for your passphrase if you added one). From here on out, you shouldn’t be asked for your passphrase as much. Github has an alternative script that is more powerful. Either script will work.

You can configure the time the ssh-agent will remember the passphrases by finding the appropriate lines in the script that call ssh-add and adding -t {seconds} to the call.

Connecting to a Server

At this point we have SSH running on our Windows machine and ssh-agent knows about our private key files. In order to use public/private keys to authenticate on a server, the server needs to have the public key information.

Uploading the Public Key

While we don’t have public/private key authentication enabled just yet, we can still use SSH to connect to our server using a regular old password:


The user we’re trying to setup, has an authorized_keys file which lives in ~/.ssh/authorized_keys. If the file doesn’t exist we need to create it. The following commands make that happen:

cd ~ #Navigates to the home directory of example_user
mkdir .ssh  #Creates directory
touch .ssh/authorized_keys  #Creates file if it doesn't exist

Next we need to paste the contents of our file into the authorized_keys file. The information must occupy a single line in the authorized_keys file.

Open the file with a text editor on your windows machine and copy the file contents to your clipboard, or you can can open another instance of GitBash and run the following command:

clip < ~/.ssh/  #Copies the contents of the to the Windows clipboard.

Next, we need to get the information on our clipboard into a new line in the authorized_keys file. Depending on GitBash or the terminal program you’re using, the steps might be slightly different. The following lines should do this, but be careful not to press enter until the last step.

echo "  #DO NOT press enter yet.
#Now go to the top left icon of GitBash (in the title bar) and select the Edit/Paste menu option.  Finish the command by typing.
" >> .ssh/authorized_keys  #Now press enter

You can also try and open the nano text editor and paste the line through nano, but nano currently does not work well inside of GitBash (the file contents are getting jumbled).

nano ~/.ssh/authorized_keys

The public key must be on it’s own line and occupy a single line in the authorized_keys file.

Change File Permissions

Before we can connect, we need to quickly make sure the file permissions are correct on the .ssh folder and authorized_keys file. Execute:

chmod 700 .ssh    # Owner read/write/execute, group none, other none
chmod 600 .ssh/authorized_keys   # Owner read/write, group none, other none


WIth the public key installed, you can now connect to the server using public/private key authentication. First, exit out of the current connection by typing:


Now, try and reconnect with ssh. If everything is setup properly, when you execute ssh, you should connect straight in (although you might be asked for your passphrase and/or to verify the host).

Connect to 3rd Party Service Via SSH

Every service you use is going to be slightly different. Github has instructions for adding your public key to their service; Bitbucket has instructions (step 6) as well.

With your public key installed on your server/service of choice, the next step is see if you can connect to them using your keys. Your service will likely have instructions on how to do this. For Github the command is:

ssh -T

For Bitbucket, execute

ssh -T

When you connect for the first time, SSH might tell you that it doesn’t know the host:

The authenticity of host ' (' cannot be established.
RSA key fingerprint is 97:8c:1b:f2:6f:14:6b:5c:3b:ec:aa:46:46:74:7c:40.
Are you sure you want to continue connecting (yes/no)? yes

Go ahead and type yes. You will then be asked for your passphrase:

#Warning: Permanently added the RSA host key for IP address '' to the list of known hosts.
#Enter passphrase for key '/c/Users/you/.ssh/id_rsa':

After supplying your passphrase, Github will respond with:

#Hi user! You've successfully authenticated, but GitHub does not provide shell access.

Bitbucket gives:

#logged in as roberts10.

#You can use git or hg to connect to Bitbucket. Shell access is disabled.

Once you have connected to your service, you are good to go. Shell access may or may not be disabled depending on what you’re trying to do; Github and Bitbucket do not provide shells.

We hope you found this article useful. If you see any mistakes, missing features or ways to improve it, please let us know in the comments below so we can update its contents. If you're willing to link to us, we would sincerely appreciate it!


Corlew Solutions is a Web Design and Web Application Development company based in Fairfax Virginia, minutes away Washington D.C. If you're looking for great web design from the Northern Virginia area or web design from the Washington D.C. area we can help. Contact Us today!

comments powered by Disqus