From aca9e4f0b41152a58b6154d93162a664de50c255 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Sun, 14 Apr 2013 15:34:59 -0400 Subject: [PATCH] =?UTF-8?q?random=20ssh=20keys=20(=E2=95=AF=C2=B0=E2=96=A1?= =?UTF-8?q?=C2=B0=EF=BC=89=E2=95=AF=EF=B8=B5=20=E2=94=BB=E2=94=81=E2=94=BB?= =?UTF-8?q?=20gnome-keyring?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit assistant: Work around horrible, terrible, very bad behavior of gnome-keyring, by not storing special-purpose ssh keys in ~/.ssh/*.pub. Apparently gnome-keyring apparently will load and indiscriminately use such keys in some cases, even if they are not using any of the standard ssh key names. Instead store the keys in ~/.ssh/annex/, which gnome-keyring will not check. Note that neither I nor #debian-devel were able to quite reproduce this problem, but I believe it exists, and that this fixes it. And it certianly won't hurt anything.. --- Assistant/Ssh.hs | 13 ++++++++++--- debian/changelog | 6 ++++++ ...assword_login___40__nearly__41___impossible.mdwn | 10 +++++++++- 3 files changed, 25 insertions(+), 4 deletions(-) diff --git a/Assistant/Ssh.hs b/Assistant/Ssh.hs index 98b21b13b2..10eb025ace 100644 --- a/Assistant/Ssh.hs +++ b/Assistant/Ssh.hs @@ -160,11 +160,18 @@ genSshKeyPair = withTempDir "git-annex-keygen" $ \dir -> do {- Installs a ssh key pair, and sets up ssh config with a mangled hostname - that will enable use of the key. This way we avoid changing the user's - regular ssh experience at all. Returns a modified SshData containing the - - mangled hostname. -} + - mangled hostname. + - + - Note that the key files are put in ~/.ssh/annex/, rather than directly + - in ssh because of an **INSANE** behavior of gnome-keyring: It loads + - ~/.ssh/*.pub, and uses them indiscriminately. But using this key + - for a normal login to the server will force git-annex-shell to run, + - and locks the user out. Luckily, it does not recurse into subdirectories. + -} setupSshKeyPair :: SshKeyPair -> SshData -> IO SshData setupSshKeyPair sshkeypair sshdata = do sshdir <- sshDir - createDirectoryIfMissing True sshdir + createDirectoryIfMissing True $ parentDir $ sshdir sshprivkeyfile unlessM (doesFileExist $ sshdir sshprivkeyfile) $ do h <- fdToHandle =<< @@ -178,7 +185,7 @@ setupSshKeyPair sshkeypair sshdata = do setSshConfig sshdata [ ("IdentityFile", "~/.ssh/" ++ sshprivkeyfile) ] where - sshprivkeyfile = "key." ++ mangleSshHostName sshdata + sshprivkeyfile = "annex" "key." ++ mangleSshHostName sshdata sshpubkeyfile = sshprivkeyfile ++ ".pub" {- Setups up a ssh config with a mangled hostname. diff --git a/debian/changelog b/debian/changelog index 2ec6a02113..e23fa3c5bd 100644 --- a/debian/changelog +++ b/debian/changelog @@ -32,6 +32,12 @@ git-annex (4.20130406) UNRELEASED; urgency=low Thanks, guilhem for the patch. * Added per-remote annex-rsync-transport option. Thanks, guilhem for the patch. + * assistant: Work around horrible, terrible, very bad behavior of + gnome-keyring, by not storing special-purpose ssh keys in ~/.ssh/*.pub. + Apparently gnome-keyring apparently will load and indiscriminately use + such keys in some cases, even if they are not using any of the standard + ssh key names. Instead store the keys in ~/.ssh/annex/, + which gnome-keyring will not check. -- Joey Hess Sat, 06 Apr 2013 15:24:15 -0400 diff --git a/doc/bugs/The_restricted_ssh_key_pair_makes_password_login___40__nearly__41___impossible.mdwn b/doc/bugs/The_restricted_ssh_key_pair_makes_password_login___40__nearly__41___impossible.mdwn index aba111a264..b98e09b32a 100644 --- a/doc/bugs/The_restricted_ssh_key_pair_makes_password_login___40__nearly__41___impossible.mdwn +++ b/doc/bugs/The_restricted_ssh_key_pair_makes_password_login___40__nearly__41___impossible.mdwn @@ -18,4 +18,12 @@ git-annex version: 4.20130324, Ubuntu 11.04 **Please provide any additional information below.** - +> [[done]]. Although I have not 100% reproduced this, I have seen +> enough of the source code to gnome-keyring to be pretty sure it's at +> fault, and that my fix works. +> +> If this is happening to you, you can fix it by making a `~/.ssh/annex/` +> directory and moving `~/.ssh/key.annex*` to it. Then you'll need to edit +> `~/.ssh/config` to use the new path to the key. And you'll need to run +> `ssh-add -D` to clear out the bogus keys from the ssh agent (or log out +> and back in). --[[Joey]]