Deploy keys do not work on Windows

[mpdude]

Using GitHub deploy keys as described in the README file does not work in Windows. Using "plain" keys (i. e. without the repo mapping provided in the comment) works, but you might be limited in how many of these keys can be tried before the remote server aborts the connection.

When deploy keys are used, this action writes the public key information (as shown by ssh-add -L) into a file, and configures SSH via IdentityFile to use this identity when connecting to the host. Also, IdentitiesOnly is turned on to try only the particular key.

On Linux systems (at least, the Ubuntu-based virtual action environments) and OS X, this works: It identifies the key to use via the public key part, but fetches the key from the SSH Agent.

On Windows, it fails. Here's the output from the ssh -v level:

debug1: Will attempt key: C:\\Users\\runneradmin/.ssh/5965bf89ab6e2900262e3f6802dfb4d65cb0de539d0fbb97d381e7130a4ba7e9 ED25519 SHA256:phogSrSHUbBX0b8klUZDZrXx68sb1gat5rDrA67VX4Y explicit
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp256-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-ed25519,ecdsa-sha2-nistp521,ecdsa-sha2-nistp384,ecdsa-sha2-nistp256,rsa-sha2-512,rsa-sha2-256,ssh-rsa,ssh-dss>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: C:\\Users\\runneradmin/.ssh/5965bf89ab6e2900262e3f6802dfb4d65cb0de539d0fbb97d381e7130a4ba7e9 ED25519 SHA256:phogSrSHUbBX0b8klUZDZrXx68sb1gat5rDrA67VX4Y explicit
debug1: Server accepts key: C:\\Users\\runneradmin/.ssh/5965bf89ab6e2900262e3f6802dfb4d65cb0de539d0fbb97d381e7130a4ba7e9 ED25519 SHA256:phogSrSHUbBX0b8klUZDZrXx68sb1gat5rDrA67VX4Y explicit
Load key "C:\\Users\\runneradmin/.ssh/5965bf89ab6e2900262e3f6802dfb4d65cb0de539d0fbb97d381e7130a4ba7e9": invalid format

As you can see, SSH on Windows complains that the key is in an invalid format. This is because the file contains the public key part, but IdentityFile should point to a private key file.

There is a bug report over at PowerShell/Win32-OpenSSH#1550 which describes that IdentitiesOnly will make SSH ignore keys from the SSH Agent. However, since removing IdentitiesOnly in this action here does not solve or work around the issue. So, the two things might be related, but it's not exactly the same problem.

One way of working around this would be to write the private key files to disk (at least under Windows), so that ssh can pick the right identity from the file. Writing keys to disk or file, however, is something this action has tried to avoid in the first place: With keys on disk, any subsequent action or process might read/steal the key. With the current action design, the private keys are passed right from GitHub Secrets into the ssh-agent process and cannot be recovered from there later on. So, I'm a bit reluctant to make this change.

I can raise an issue over at https://github.com/PowerShell/Win32-OpenSSH/, however I have no idea if this is the right place to report, how quickly the issue could be fixed and when an update would make it into virtual Windows environments.

[cecton]

Maybe a stupid question but can you write it down to disk, ssh-add, then delete it right after adding it? I understand it is not ideal but it might be an okay workaround for now

[mpdude]

No, it has to be available at a later stage when e.g. Git uses SSH, so after this action here has finished.

[cecton]

I just made a test locally on Linux and I confirm that the key is actually loaded in memory. You can safely delete the file right after adding it if you want.

[leafac]

I understand that if you write the keys to disk they become available to whatever runs later in the action, but can you please help me understand why that’s a problem?

You should trust the things you’re running anyway, because even if they can’t access the key, they can use it via the agent. You may not be giving people the keys to your house, but you’re leaving the door open.

[cecton]

Even when you use ssh-agent and share it through ssh (ssh -A), your keys are actually accessible by the remote machine as long as the ssh session is opened.

Though to avoid leaking the key by mistake I would simply delete the file right after it is added (if that works on Windows). It works on Linux so I suspect the key is loaded into memory and it doesn't matter if the file is still there.

[mpdude]

Please help testing if the #63 PR fixes the issue for you.

In your GHA workflow files, uses: webfactory/ssh-agent@use-git-ssh-suite should do the trick.

[cecton]

It's still failing for me, no change in the error message. Thanks a lot for your time!!

[cecton]

I will do some investigation too

[cecton]

Ok it's working.

@mpdude with v0.5.0 it fails. So what you did in your branch really made the difference!

   Warning: Permanently added the RSA host key for IP address '140.82.121.4' to the list of known hosts.
  git@github.com: Permission denied (publickey).
  fatal: Could not read from remote repository.

  Please make sure you have the correct access rights
  and the repository exists.

With webfactory/ssh-agent@use-git-ssh-suite it depends:

1. the Git CLI works (which is what you only care about)
2. cargo fails (which is supposed to use ssh agent which works on Linux and OSX)

NOTE for other cargo users, you will need to add this to your workflow before running any cargo command:

      - name: Update cargo config to use Git CLI
        run: Set-Content -Path $env:USERPROFILE\.cargo\config.toml "[net]`ngit-fetch-with-cli = true"

@mpdude for me you can merge and close this ticket. Thanks again for your time

(cc @fstephany)

[mpdude]

@cecton Thanks for the report!

I don't know about Cargo/Rust... but would it make sense to add a section to the README file explaining this (and could you also explain what this change does and why it is necessary then?).

Feel free to open a PR for it!

[cecton]

You're 💯 right, thanks!!

[mpdude]

I think this has been resolved by #63, and just released as v0.5.1.

Make sure you update your workflow definitions if you have been affected by this.