-
Notifications
You must be signed in to change notification settings - Fork 319
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
jj git push
is not working for me on Windows
#3322
Comments
the second one might be libgit2/libgit2#6612 |
I am getting the same issue on windows (not WSL): PS D:\repos\LeadLens> jj git push -c "@-"
Creating branch push-nroqnvwmpzqn for revision @-
Branch changes to push to origin:
Add branch push-nroqnvwmpzqn to e06c042721af
Error: Failed to authenticate SSH session: ; class=Ssh (23)
Hint: Jujutsu uses libssh2, which doesn't respect ~/.ssh/config. Does `ssh -F /dev/null` to the host work? |
Similar issue here; I am cloning a repository from a private GitLab service using Windows and the remote ssh key is ed25519, and getting "Error: Fetch failed: failed to set hostkey preference: The requested method(s) are not currently supported; class=Ssh (23)". If I comment out the known_hosts line, I instead get "Fetch failed: failed to start SSH session: Unable to exchange encryption keys; class=Ssh (23)" |
libssh2 error code 23 is |
I've tracked down the issue. The Windows Cryptography Next Generation API backend for libssh2 do not have support for ED25519 and libssh2-sys is defaulting to use it instead of OpenSSL when targeting win32 (either msvc or mingw). libssh2-sys must be compiled with the All distributions of git on windows use a combination of cygwin and git itself which are all compiled to use openssl, which is why it's not a common issue for windows git users. But when using libgit2 directly, this is something to be conscientious of I guess. |
By default, libssh2 uses Windows Cryptography Next Generation when targeting win32. The wincng backend does not support ED25519, which is a widely-used algorithm among git hosting services, and in some cases may be the only option on remotes in certain configurations. This change necessitates Windows users building jj to install openssl via vcpkg for the target triple x64-windows-static-md when building for MSVC, or otherwise have OpenSSL available at build time. This should also generally work when building for MinGW, though I did not try it. Fixes martinvonz#3322
By default, libssh2 uses Windows Cryptography Next Generation when targeting win32. The wincng backend does not support ED25519, which is a widely-used algorithm among git hosting services, and in some cases may be the only option on remotes in certain configurations. This change necessitates Windows users building jj to install openssl via vcpkg for the target triple x64-windows-static-md when building for MSVC, or otherwise have OpenSSL available at build time. This should also generally work when building for MinGW, though I did not try it. Fixes martinvonz#3322
By default, libssh2 uses Windows Cryptography Next Generation when targeting win32. The wincng backend does not support ED25519, which is a widely-used algorithm among git hosting services, and in some cases may be the only option on remotes in certain configurations. This change necessitates Windows users building jj to install openssl via vcpkg for the target triple x64-windows-static-md when building for MSVC, or otherwise have OpenSSL available at build time. This should also generally work when building for MinGW, though I did not try it. Fixes martinvonz#3322
By default, libssh2 uses Windows Cryptography Next Generation when targeting win32. The wincng backend does not support ED25519, which is a widely-used algorithm among git hosting services, and in some cases may be the only option on remotes in certain configurations. This change necessitates Windows users building jj to install openssl via vcpkg for the target triple x64-windows-static-md when building for MSVC, or otherwise have OpenSSL available at build time. This should also generally work when building for MinGW, though I did not try it. Fixes martinvonz#3322
By default, libssh2 uses Windows Cryptography Next Generation when targeting win32. The wincng backend does not support ED25519, which is a widely-used algorithm among git hosting services, and in some cases may be the only option on remotes in certain configurations. This change adds the feature `openssl-on-win32`, enabling the same one in `libssh2-sys`, and enables it in the CI release flow, ensuring that release builds are able to communicate with hosts using ED25519. Fixes martinvonz#3322
By default, libssh2 uses Windows Cryptography Next Generation when targeting win32. The wincng backend does not support ED25519, which is a widely-used algorithm among git hosting services, and in some cases may be the only option on remotes in certain configurations. This change adds the feature `openssl-on-win32`, enabling the same one in `libssh2-sys`, and enables it in the CI release flow, ensuring that release builds are able to communicate with hosts using ED25519. Fixes martinvonz#3322
By default, libssh2 uses Windows Cryptography Next Generation when targeting win32. The wincng backend does not support ED25519, which is a widely-used algorithm among git hosting services, and in some cases may be the only option on remotes in certain configurations. This change adds the feature `openssl-on-win32`, enabling the same one in `libssh2-sys`, and enables it in the CI release flow, ensuring that release builds are able to communicate with hosts using ED25519. Fixes martinvonz#3322
By default, libssh2 uses Windows Cryptography Next Generation when targeting win32. The wincng backend does not support ED25519, which is a widely-used algorithm among git hosting services, and in some cases may be the only option on remotes in certain configurations. This change adds the feature `openssl-on-win32`, enabling the same one in `libssh2-sys`, and enables it in the CI release flow, ensuring that release builds are able to communicate with hosts using ED25519. Fixes martinvonz#3322
By default, libssh2 uses Windows Cryptography Next Generation when targeting win32. The wincng backend does not support ED25519, which is a widely-used algorithm among git hosting services, and in some cases may be the only option on remotes in certain configurations. This change adds the feature `openssl-on-win32`, enabling the same one in `libssh2-sys`, and enables it in the CI release flow, ensuring that release builds are able to communicate with hosts using ED25519. Fixes martinvonz#3322
By default, libssh2 uses Windows Cryptography Next Generation when targeting win32. The wincng backend does not support ED25519, which is a widely-used algorithm among git hosting services, and in some cases may be the only option on remotes in certain configurations. This change adds the feature `openssl-on-win32`, enabling the same one in `libssh2-sys`, and enables it in the CI release flow, ensuring that release builds are able to communicate with hosts using ED25519. Fixes martinvonz#3322
By default, libssh2 uses Windows Cryptography Next Generation when targeting win32. The wincng backend does not support ED25519, which is a widely-used algorithm among git hosting services, and in some cases may be the only option on remotes in certain configurations. This change adds the feature `openssl-on-win32`, enabling the same one in `libssh2-sys`, and enables it in the CI release flow, ensuring that release builds are able to communicate with hosts using ED25519. Fixes martinvonz#3322
By default, libssh2 uses Windows Cryptography Next Generation when targeting win32. The wincng backend does not support ED25519, which is a widely-used algorithm among git hosting services, and in some cases may be the only option on remotes in certain configurations. This change adds the feature `openssl-on-win32`, enabling the same one in `libssh2-sys`, and enables it in the CI release flow, ensuring that release builds are able to communicate with hosts using ED25519. Fixes martinvonz#3322
Description
whenever i run
jj git push
, i get one of the two errors:Error: invalid or unknown remote ssh hostkey; class=Ssh (23); code=Certificate (-17)
Error: failed to set hostkey preference: The requested method(s) are not currently supported; class=Ssh (23)
Steps to Reproduce the Problem
i have no idea. i don't believe this is related to my .ssh/config, since
ssh -F /dev/null [email protected]
succeeds. i have the following env variables set on WSL:those aren't set on windows, but ssh-agent is somehow working anyway; at least,
ssh-add
succeeds.Expected Behavior
jj is able to push to the remote.
Specifications
The text was updated successfully, but these errors were encountered: