[PATCH] git-gui: search for all current SSH key types
OpenSSH has supported Ed25519 keys since version 6.4 (2014-01-30), and
ECDSA keys since version 5.7 (2011-01-24). git-gui fails to find these
key types in its Help/Show SSH Key dialog.
Teach git-gui to show Ed25519 and ECDSA keys as well.
This was originally reported in
https://github.com/git-for-windows/git/issues/1487 and subseqently in
https://public-inbox.org/git/f65780f29e48994380e2bce87c6f071101146...@deerlm99ex2msx.ww931.my-it-solutions.net/
Signed-off-by: Beat Bolli <dev+...@drbeat.li>
---
Cc: Alexander Gavrilov <angavri...@gmail.com>
Cc: Pat Thoyts <pattho...@users.sourceforge.net>
git-gui/lib/sshkey.tcl | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/git-gui/lib/sshkey.tcl b/git-gui/lib/sshkey.tcl
index aa6457bbb..589ff8f78 100644
--- a/git-gui/lib/sshkey.tcl
+++ b/git-gui/lib/sshkey.tcl
@@ -2,7 +2,10 @@
# Copyright (C) 2006, 2007 Shawn Pearce
proc find_ssh_key {} {
- foreach name {~/.ssh/id_dsa.pub ~/.ssh/id_rsa.pub ~/.ssh/identity.pub} {
+ foreach name {
+ ~/.ssh/id_dsa.pub ~/.ssh/id_ecdsa.pub ~/.ssh/id_ed25519.pub
+ ~/.ssh/id_rsa.pub ~/.ssh/identity.pub
+ } {
if {[file exists $name]} {
set fh[open $name r]
set cont [read $fh]
--
2.15.0.rc1.299.gda03b47c3
Issue: Git Gui: show ssh key don't show key type id_ed25519.pub
Hello,
Maybe someone can fix this issue.
Thanks
Git Gui: show ssh key don't show key type id_ed25519.pub
Setup
. Which version of Git for Windows are you using? Is it 32-bit or 64-bit?
$ git --version --build-options
** 2.16.1windows.2 **
. Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or
64-bit?
$ cmd.exe /c ver
** Microsoft Windows [Version 10.0.16299.214] **
. What options did you set as part of the installation? Or did you choose the
defaults?
# One of the following:
> type "C:\Program Files\Git\etc\install-options.txt"
> type "C:\Program Files (x86)\Git\etc\install-options.txt"
> type "%USERPROFILE%\AppData\Local\Programs\Git\etc\install-options.txt"
$ cat /etc/install-options.txt
** insert your machine's response here **
. Any other interesting things about your environment that might be related
to the issue you're seeing?
** insert your response here **
Details
. Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other
** insert your response here **
. What commands did you run to trigger this issue? If you can provide a
http://stackoverflow.com/help/mcve
this will help us understand the issue.
** insert your commands here **
. What did you expect to occur after running these commands?
** insert here **
. What actually happened instead?
** insert here **
. If the problem was occurring with a specific repository, can you provide the
URL to that repository to help us with testing?
** insert URL here **
Description
Under ~/.ssh are only one ssh key pair of type ed25519
( id_ed25519 and id_ed25519.pub)
Git GUI don't show it
C:\Users\goldfinger2\.ssh>dir /b
agent.env
authorized_keys
id_ed25519
id_ed25519.pub
Win32-OpenSSH Beta currently supports only one key type (ed25519).
https://github.com/PowerShell/Win32-OpenSSH/issues/973
https://blogs.msdn.microsoft.com/powershell/2017/12/15/using-the-openssh-beta-in-windows-10-fall-creators-update-and-windows-server-1709/
Steps to Reproduce
1. Open Git Gui
2. Select Help
3. Show SSH Key : No Keys found
Expected behavior: Showing the ed25519 Key
Reproduces how often: 100%
Additional information
The problem is located in the find_ssh_key function in sshkey.tcl.
Which is not searching after id_ed25519.pub
find_ssh_key {} {
foreach name {~/.ssh/id_dsa.pub ~/.ssh/id_rsa.pub ~/.ssh/identity.pub} {
>> This looks like a problem in upstream Git GUI. Would you mind reporting this
>> to the Git mailing list at git@vger.kernel.org?
>> Or even better, write the patch yourself? ;-) This looks like a problem in
>> upstream Git GUI.
>> Would you mind reporting this to the Git mailing list at
>> git@vger.kernel.org? Or even better, write the patch yourself? ;-)
Re: ssh key
On Sat, 28 May 2016 16:47:06 +0300 matveevma <matvee...@jinr.ru> wrote: > Can i add SSH id_rsa.pub to GIT by shell terminal? Hi! First things first: this list has nothing to do neither with Github nor with shells of any sort. Please note that Github it not Git, it rather is a hosting for Git projects, so if you have a Github-specific question please direct it to Github support channels [2, 3], thanks. As to the essence of your question, it appears that Github has a rich RESTful API, so you should be able to register your SSH key using `curl` or a similar tool using Github webAPI calls described in [1]. 1. https://developer.github.com/v3/repos/keys/ 2. https://help.github.com/ 3. https://github.com/contact -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
ssh key
Hi, Can i add SSH id_rsa.pub to GIT by shell terminal? Thank you! Mikhail. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: .gitmodules containing SSH clone URLs should fall back to HTTPS when SSH key is not valid/existent
Am 29.05.2014 04:07, schrieb Jonathan Leonard: The title pretty much says it all. But you do not give much information about your special use case. I assume you have submodule repositories for which some developers have a valid ssh key and others don't (maybe because they should only have read access via https)? If that is the case you might want to look into access control tools like gitolite. Lack of this feature (or presence of this bug [depending on your perspective]) is a major PITA. But why is https special? Why not fall back to the git protocol? Or http? (And no: I'm not serious here ;-) After the first failed clone of the submodule at via SSH the developer could also just do a git config submodule.name.url https://host/repo and override the URL from .gitmodules. But maybe I misunderstood why you want to have a fall back? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: .gitmodules containing SSH clone URLs should fall back to HTTPS when SSH key is not valid/existent
Jens Lehmann jens.lehm...@web.de writes: Am 29.05.2014 04:07, schrieb Jonathan Leonard: The title pretty much says it all. But you do not give much information about your special use case. Perhaps git grep insteadOf Documentation/ is all that is needed? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: .gitmodules containing SSH clone URLs should fall back to HTTPS when SSH key is not valid/existent
But you do not give much information about your special use case. I assume you have submodule repositories for which some developers have a valid ssh key and others don't (maybe because they should only have read access via https)? Precisely. Specifically this is for a collection (17 or more) of GitHub-hosted projects which are maintained by only a couple of people (who have the ability to directly push via git:// or ssh://). Everyone else (including deployments and ordinary users) who clones the repo should be able to just grab the code via HTTPS and have it work. If that is the case you might want to look into access control tools like gitolite. We are using GitHub. Lack of this feature (or presence of this bug [depending on your perspective]) is a major PITA. But why is https special? Why not fall back to the git protocol? Or http? (And no: I'm not serious here ;-) HTTPS isn't special except in that it is the least privileged transport type (and thus should be the last resort). Whether to fallback to git:// from ssh:// or vice versa is inconsequential to this request. After the first failed clone of the submodule at via SSH the developer could also just do a git config submodule.name.url https://host/repo and override the URL from .gitmodules. Yes, this would work. But it would be a painful manual step which we would not want to force on ordinary users (and would not want to experience ourselves either). It should be noted that this is only really a problem as the other options GitHub gives us are also equally (or more) painful: a) - a unique deploy key per machine and project. (which at current would be 17 * 3 keys all manually maintained via clicking through a GUI [unless we wanted to automate via GitHub API (which is also a non-trivial amount of work)]). - or - b) - a fake 'team' with read-only access with a single fake GitHub account as member thereof. I imagine this feature would be convenient for non-GitHub scenarios as well though. --Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: .gitmodules containing SSH clone URLs should fall back to HTTPS when SSH key is not valid/existent
On Thu, May 29, 2014 at 04:12:38PM -0700, Jonathan Leonard wrote: We are using GitHub. [...] But why is https special? Why not fall back to the git protocol? Or http? (And no: I'm not serious here ;-) HTTPS isn't special except in that it is the least privileged transport type (and thus should be the last resort). Whether to fallback to git:// from ssh:// or vice versa is inconsequential to this request. That's not quite true. git:// is the least privileged transport, as it always anonymous and read-only (there ways to allow insecure pushes over it, but GitHub does not enable them). Https is actually the most flexible protocol, in that the same URL works of the box for both logged-in and anonymous users (the latter assuming the repo is publicly available). The server only prompts for credentials if necessary. For that reason, it's a good choice for things like submodule URLs baked into .gitmodules files. The reasons not to are: 1. It isn't _quite_ as efficient or robust as the regular git protocol, though in practice it's generally not a big deal. 2. Pushers may prefer to authenticate with ssh keys (e.g., because they run ssh agent). I hope with modern credential helpers that logging in via http should not be a pain, either, though. After the first failed clone of the submodule at via SSH the developer could also just do a git config submodule.name.url https://host/repo and override the URL from .gitmodules. Yes, this would work. But it would be a painful manual step which we would not want to force on ordinary users (and would not want to experience ourselves either). Using insteadOf of in your global ~/.gitconfig would make this a one-liner per-user. So one option would be to reverse things. Put https URLs into the .gitmodules file, so most people have to do nothing, and then developers who really want to do git-over-ssh can do a one-time: git config --global url@github.com:.insteadOf https://github.com/ -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: .gitmodules containing SSH clone URLs should fall back to HTTPS when SSH key is not valid/existent
On Fri, May 30, 2014 at 11:12 AM, Jonathan Leonard johana...@gmail.com wrote: But you do not give much information about your special use case. I assume you have submodule repositories for which some developers have a valid ssh key and others don't (maybe because they should only have read access via https)? Precisely. Specifically this is for a collection (17 or more) of GitHub-hosted projects which are maintained by only a couple of people (who have the ability to directly push via git:// or ssh://). Everyone else (including deployments and ordinary users) who clones the repo should be able to just grab the code via HTTPS and have it work. If that is the case you might want to look into access control tools like gitolite. We are using GitHub. Lack of this feature (or presence of this bug [depending on your perspective]) is a major PITA. But why is https special? Why not fall back to the git protocol? Or http? (And no: I'm not serious here ;-) HTTPS isn't special except in that it is the least privileged transport type (and thus should be the last resort). Whether to fallback to git:// from ssh:// or vice versa is inconsequential to this request. The problem is that a ssh:// url can't necessarily be transformed into a correct https:// or git:// with a simple sed 's/ssh/https/' chances are other parts of the URL will need changing. Which quickly becomes non-trivial. One solution that we use at work is to use relative paths (e.g. ../code/mod1.git) in .gitmodules (assuming the submodules are all part of the same project). That way if you clone the superproject over https:// all the submodules use that too. This works well for us using local mirrors across multiple sites _and_ different protocols. Another option would be to have a policy of storing the most permissive transport in .gitmodules which makes it easy for users and puts the special config requirements on the maintainers. Both of these are obviously solutions you need to convince the maintainer(s) of the superproject to implement. Perhaps what git could do is allow multiple urls for a submodule and at git submodule init time try them in order until the fetch is successful. Or provide a mechanism to map transports, arguably this is the url.foo.insteadOf mechanisim that has already been suggested. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
.gitmodules containing SSH clone URLs should fall back to HTTPS when SSH key is not valid/existent
The title pretty much says it all. Lack of this feature (or presence of this bug [depending on your perspective]) is a major PITA. --Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
