This currently fails with:

2020-02-04T21:28:52.4592331Z ##[group]Run ./
2020-02-04T21:28:52.4592902Z with:
2020-02-04T21:28:52.4599986Z   ssh-private-key: ***
***


2020-02-04T21:28:52.4600504Z   ssh-auth-sock: /tmp/ssh-auth.sock
2020-02-04T21:28:52.4601159Z ##[endgroup]
2020-02-04T21:28:52.5330356Z Preparing ssh-agent service on Windows
2020-02-04T21:28:52.5705188Z [SC] ChangeServiceConfig SUCCESS
2020-02-04T21:28:52.5736739Z Adding GitHub.com keys to C:\Users\runneradmin/.ssh/known_hosts
2020-02-04T21:28:52.5763082Z Starting ssh-agent
2020-02-04T21:28:52.7900317Z Adding private key to agent
2020-02-04T21:28:52.9223344Z Error connecting to agent: No such file or directory
2020-02-04T21:28:52.9234640Z ##[error]Command failed: ssh-add -
Error connecting to agent: No such file or directory

2020-02-04T21:28:52.9326562Z ##[error]Node run failed with exit code 1
2020-02-04T21:28:52.9348747Z Cleaning up orphan processes

git config --global core.sshCommand "'C:\Windows\System32\OpenSSH\ssh.exe'"

It sounds like the error you get is that git is using the builtin ssh and not the windows one that you started.

To me it looks as if it fails on ssh-add - already.

I just got this process working on Windows, similar to how others have, but one thing that hasn't been pointed out:

After enabling the service (start=demand), the service needs to be started through Windows, not by running ssh-agent. This is done by running net start ssh-agent.

Note that this does not explicitly use a socket file, but it appears that the Windows installation of OpenSSH already knows how to find the ssh-agent if the service is running (ie. ssh-add - should work without needing anything additional once the service is running).

I don't know how to translate this into a github-action but the following powershell script got the ssh-agent running on the windows-2016 image . In my case the goal was to allow deploy-key access to a github repo.

` - name: setup ssh key for rules_support deploy

  run: |
      choco install --no-progress -my openssh --params '"/SSHAgentFeature"'
      refreshenv
      Write-Output 'Starting ssh-agent service...'
      Get-Service -Name 'ssh-agent' | Set-Service -StartupType Manual
      Start-Service -Name 'ssh-agent'
      New-Item -ItemType Directory -Force -Path '~/.ssh' *>$null
      $env:SSH_KEY | &ssh-add -
      &ssh-keyscan -H "$(
        @($env:SSH_HOST) + (Resolve-DnsName $env:SSH_HOST).IPAddress -Join ','
      )" | Add-Content '~/.ssh/known_hosts'
  shell: powershell
  env:
    SSH_KEY: ${{ secrets.SSH_KEY }}
    SSH_HOST: github.com`

@Raynos, @The-EG and @bldrvnlw

Could you give this PR/branch a try? All you should need to do is to use @try-windows instead of @v0.4.1 in your action files.

@leafac I saw your comment over at vercel/pkg#837.

If you have a real Windows use case for this action, could you give this branch a try?

The docker demo fails because the ubuntu docker image has not ssh installed. So either use a docker image with openssh-client installed or install it in the action with

   - run: apt update && apt install -y openssh-client

I'll wait a few more days for feedback in #30 or #59. If we can resolve those as well, I'll cut a v0.5.0 release including all new features.

You'll get an "The specified service already exists" error if you try to over install with chocolatey. That makes it rather awkward to use as a no-op, not a cheap one in any case because you would have to build filtering around it.

Ok, let’s ignore Windows 2016 then.

This doesn't work for me on Windows either. It gives me a permission denied error at the last step on windows but not on Ubuntu. I am using a deploy key on the private company repo. Let me know if it's worth making a new issue for this

name: CI

# Controls when the action will run. 
on:
  # Triggers the workflow on push or pull request events but only for the dev branch
  push:
    branches: [ dev ]
  pull_request:
    branches: [ dev ]

  # Allows you to run this workflow manually from the Actions tab
  workflow_dispatch:

# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
  # This workflow contains a single job called "build"
  build:
    # The type of runner that the job will run on
    runs-on: windows-latest # The app is intended primarily for Windows
    # runs-on: ubuntu-latest # Debug; this cannot build windows builds!!!

    # Steps represent a sequence of tasks that will be executed as part of the job
    steps:
      # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
      - uses: actions/checkout@v2
      
      # We depend on another private repo of ours so we need to set up SSH agent with a key
      - uses: webfactory/ssh-agent@v0.5.0
        with:
          ssh-private-key: ${{ secrets.SSH_PRIVATE_KEY }}
          
      - name: Debug
        run: git clone git@github.com:*********.git 

Can you share the Action output/log?

Yes sir, I actually made a fresh public repo with this workflow and the same one but on Ubuntu, I also made a private repo with a deploy key. I add the key as a secret. You can see the workflow logs for yourself.

Here is the Ubuntu one and here is the Windows version.

Feel free to mess around with the workflow files and re-run them

Could you make the Windows action run ssh-add -l (does that even work on Windows)? in the run: step, before it does the git clone?

And do you know how to enable SSH verbosity for the git clone operation on Windows?

I don't think I could edit the workflows and/or make them run, could I?

I'm experimenting the same issue and since it's also a private repo I can't share much 😅

Basically the SSH Agent steps worked and said "Keys added". 👍 but at the next step cargo (Rust) fails to use the key to clone a private dependency.

Ok, understand.

Please at first make sure the agent started in the first step is still alive/running when the next step starts, and that keys are still loaded.

Does ssh-add -l in a dedicated run: entry list the keys?

Ok I will try all of that but it will probably be on Monday if you don't mind.

I tried with a matrix build in this repo, and yes, it fails – but only when using with deployment keys.

https://github.com/webfactory/ssh-agent/runs/1990796091?check_suite_focus=true

Unfortunately, I am not familiar with Windows and do not have a direct Windows machine myself, so probably I'd need a little help.

Here's my guess what happens:

After the keys have been loaded, they are listed with ssh-add -L and parsed for the key comments that indicate the deployment key/repo mapping. The respective line from ssh-add -L, which should equal the .pub part of the key, is then put into a file.

Then, when connecting, this file is used as the IdentityFile, corresponding to the ssh -i ... argument.

Under Linux, this file can contain the public key part (from the .pub file), and the corresponding private key will be loaded from the agent.

Could somebody please try if the SSH Agent on Windows works the same way? Can a private key be loaded from the agent by providing the public key part through the -i command line argument?

Could somebody please try if the SSH Agent on Windows works the same way? Can a private key be loaded from the agent by providing the public key part through the -i command line argument?

It appears that the answer is negative:

PS C:\Users\micro\.ssh> ssh-add -L
Error connecting to agent: No such file or directory
PS C:\Users\micro\.ssh> ssh-agent
PS C:\Users\micro\.ssh> ssh-add -L
ssh-ed25519 [REDACTED]
PS C:\Users\micro\.ssh> ssh-add -L > TEST
PS C:\Users\micro\.ssh> cat TEST
ssh-ed25519 [REDACTED]
PS C:\Users\micro\.ssh> ssh -i TEST git@github.com
PTY allocation request failed on channel 0
Hi leafac! You've successfully authenticated, but GitHub does not provide shell access.
Connection to github.com closed.
PS C:\Users\micro\.ssh> Stop-Service ssh-agent
PS C:\Users\micro\.ssh> ssh-add -L
Error connecting to agent: No such file or directory
PS C:\Users\micro\.ssh> ssh -i TEST git@github.com
Load key "TEST": invalid format
git@github.com: Permission denied (publickey).

N.B.: I have 2 days of experience with Windows, so the test above may not make sense. I’m used to macOS/Linux, but was tired of having my stuff breaking on Windows and having to use VirtualBox to figure it out, so last weekend I bought a PC for this kind of investigation.

A bit more of investigation shows that it might not be so easy to fix this... 😞

Let's better move the discussion to a new issue: #62. 

#63 is the PR trying to fix it.

Ok I will try all of that but it will probably be on Monday if you don't mind.

Totally forgot to answer here sorry! And I don't remember exactly what issue I had... It seems what you did fixed it for me

Hm, it doesn't seem to work for me, running on windows-latest.
I have it configured to run on macos, ubuntu and windows. Only windows fails, the others succeed:

  build:
    strategy:
      matrix:
        include:
          - os: macos-latest
          - os: ubuntu-latest
          - os: windows-latest
    runs-on: ${{ matrix.os }}
    steps:
    - uses: actions/checkout@v3

    - uses: webfactory/ssh-agent@v0.7.0
      with:
        ssh-private-key: ${{ secrets.SSH_PRIVATE_KEY }}

    - run: cargo build --release

# ...

It invokes Rust's cargo build tool to build a binary from the current repo.
Cargo needs to use ssh authentification to download dependencies (crates) from private repos.
It only works on macos-latest and ubuntu-latest, but NOT on windows-latest. It fails to authenticate when downloading private repos:

    Updating crates.io index
    Updating git repository `ssh://git@github.com/Boscop/foo-bar`
error: failed to get `foo-bar` as a dependency of package `views v0.1.0 (D:\a\project\project\views)`

Caused by:
  failed to load source for dependency `foo-bar`

Caused by:
  Unable to update ssh://git@github.com/Boscop/foo-bar#bb3d1d22

Caused by:
  failed to clone into: C:\Users\runneradmin\.cargo\git\db\foo-bar-560e3bc8203f0bcd

Caused by:
  failed to authenticate when downloading repository

  * attempted ssh-agent authentication, but no usernames succeeded: `git`

  if the git CLI succeeds then `net.git-fetch-with-cli` may help here
  https://doc.rust-lang.org/cargo/reference/config.html#netgit-fetch-with-cli

Caused by:
  error authenticating: failed connecting agent; class=Ssh (23)
Error: Process completed with exit code 1.

Note: By default, cargo uses the git library that it's linked to, to download repos. But when setting net.git-fetch-with-cli to true in ~/.cargo/config.toml (or setting env var CARGO_NET_GIT_FETCH_WITH_CLI=true), it will use the installed git executable to fetch repos instead.
I tried both ways, because locally on my windows computer that works, but it didn't make it work in the Github action.

Btw, the output of the webfactory/ssh-agent step makes it seem like it was setup correctly:

Adding GitHub.com keys to C:\Users\runneradmin/.ssh/known_hosts
Starting ssh-agent
SSH_AUTH_SOCK=/tmp/ssh-dFriuo1f3YxM/agent.34
SSH_AGENT_PID=35
Adding private key(s) to agent
Identity added: (stdin) (<redacted>)
Key(s) added:
256 SHA256:<redacted> (ED25519)
Configuring deployment key(s)
Comment for (public) key 'ssh-ed25519 <redacted>' does not match GitHub URL pattern. Not treating it as a GitHub deploy key.

Any idea why git (called by cargo) fails to use the SSH key (only when running on windows)?
I'd really appreciate any hints :)

@Boscop this issue here dealt with Windows in general, not Rust in particular, and it has been closed. Please open a new issue.

Also, have a look at what #63 figured out. Does Rust/Cargo use these SSH binaries? If not, can you make it do so? How?

For me v0.8.0 fails on our private github runner on the Windows build. It works correctly on our Linux build (under wsl). The issue is that for some reason in our Windows build it is not able to clone the linked private repo because "Host key verification failed".

I've tried multiple things suggested, including updating OpenSSH on the Windows side to the latest beta release, but nothing helped.

After switching to v0.7.0 both the Windows and the Linux builds now work as intended.

So I don't know what changed between v0.7.0 and v0.8.0 but for me it regressed the Windows side of things to the point that it has become unusable.

I also having the same issue as @PJKuyten. Downgrade to 0.7.0 fix the issue.

Downgrading von 0.9.0 to 0.7.0 worked for me as well

What is the status of this action for windows runners? I have no problem in linux-latest and macos-latest runners, but windows-latest show all kind of weird issues when trying to setup the ssh connection. I have tried some workarounds that seem to work one time, and then they fail and i'm unsure how to continue so i would greatly appreciante any help