assistant: Fix local pairing to not include newline in ssh pubkey, which is rejected on the other end for security reasons.

This commit is contained in:
Joey Hess 2015-07-02 14:50:20 -04:00
parent a8fcd68144
commit 20edbf850c
3 changed files with 21 additions and 1 deletions

View file

@ -223,11 +223,12 @@ startLocalPairing stage oncancel alert muuid displaysecret secret = do
- background. -}
thread <- liftAssistant $ asIO $ do
keypair <- liftIO $ genSshKeyPair
let pubkey = either error id $ validateSshPubKey $ sshPubKey keypair
pairdata <- liftIO $ PairData
<$> getHostname
<*> myUserName
<*> pure reldir
<*> pure (sshPubKey keypair)
<*> pure pubkey
<*> (maybe genUUID return muuid)
let sender = multicastPairMsg Nothing secret pairdata
let pip = PairingInProgress secret Nothing keypair pairdata stage

2
debian/changelog vendored
View file

@ -4,6 +4,8 @@ git-annex (5.20150618) UNRELEASED; urgency=medium
* assistant --autostart: First any daemons that are already running,
which might be left over from a previous login session and so unable to
use the ssh agent of a new login session.
* assistant: Fix local pairing to not include newline in ssh pubkey,
which is rejected on the other end for security reasons.
-- Joey Hess <id@joeyh.name> Thu, 02 Jul 2015 12:31:14 -0400

View file

@ -0,0 +1,17 @@
[[!comment format=mdwn
username="joey"
subject="""comment 4"""
date="2015-07-02T18:32:16Z"
content="""
In comment 2, we see a message containing a ssh key with a newline at the
end. That is the control character it's objecting to, and it has good
security reasons to not allow newlines in there (multiline ssh keys could
result in a ~/.ssh/authorized_keys that runs arbitrary commands).
I was able to reproduce that myself. The problem was that the assistant
didn't remove newlines when sending the ssh key. Fixed it.
This bug report is **closed**, for the second time.
If you see this message using any newer version of git-annex,
please file a new bug report.
"""]]