Repository navigation
Deploy keys do not work on Windows #62
Description
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.
Activity
cecton commentedon Feb 27, 2021
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 commentedon Feb 27, 2021
No, it has to be available at a later stage when e.g. Git uses SSH, so after this action here has finished.
cecton commentedon Feb 27, 2021
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 commentedon Feb 27, 2021
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 commentedon Feb 27, 2021
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 commentedon Mar 4, 2021
Please help testing if the #63 PR fixes the issue for you.
In your GHA workflow files,
uses: webfactory/ssh-agent@use-git-ssh-suiteshould do the trick.cecton commentedon Mar 4, 2021
It's still failing for me, no change in the error message. Thanks a lot for your time!!
cecton commentedon Mar 4, 2021
I will do some investigation too
cecton commentedon Mar 4, 2021
Ok it's working.
@mpdude with v0.5.0 it fails. So what you did in your branch really made the difference!
With
webfactory/ssh-agent@use-git-ssh-suiteit depends:NOTE for other cargo users, you will need to add this to your workflow before running any cargo command:
@mpdude for me you can merge and close this ticket. Thanks again for your time
(cc @fstephany)
mpdude commentedon Mar 4, 2021
@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 commentedon Mar 4, 2021
You're 💯 right, thanks!!
mpdude commentedon Mar 10, 2021
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.