summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorGravatar grawity@2ea26be48562f66fcb9b66307da72b1e2e37453f <grawity@web>2016-12-11 17:46:03 +0000
committerGravatar admin <admin@branchable.com>2016-12-11 17:46:03 +0000
commitb878991899f1f6624bbd3cceff11b1fa548183ba (patch)
tree145c59e44fc14b04dcad4c6a4807d169a515d354
parente28c63125a757a30c3a45f4e4191f05e81aa31a3 (diff)
-rw-r--r--doc/bugs/ssh___34__Include__34___breaks_user-specified_IgnoreUnknown.mdwn26
1 files changed, 26 insertions, 0 deletions
diff --git a/doc/bugs/ssh___34__Include__34___breaks_user-specified_IgnoreUnknown.mdwn b/doc/bugs/ssh___34__Include__34___breaks_user-specified_IgnoreUnknown.mdwn
new file mode 100644
index 000000000..b910ac408
--- /dev/null
+++ b/doc/bugs/ssh___34__Include__34___breaks_user-specified_IgnoreUnknown.mdwn
@@ -0,0 +1,26 @@
+### Please describe the problem.
+
+The OpenSSH client parses configuration in a "first match wins" manner, and this also applies to `IgnoreUnknown`. This means that when git-annex's `Include ~/.ssh/config` is processed, any user-specified `IgnoreUnknown` setting in the global configuration will be ignored because it has already been set. As a result, every time git-annex runs ssh, it immediately exits with an error:
+
+[[!format text """
+drop vol3 somefile.mkv (locking vol5...) (lockcontent failed) (checking vol5...)
+/home/grawity/.ssh/config: line 217: Bad configuration option: gssapikeyexchange
+/home/grawity/.ssh/config: terminating, 1 bad configuration options
+failed
+"""]]
+
+To be fair, this might be an OpenSSH bug (IgnoreUnknown ought to be merged), but it seems git-annex is triggering it unnecessarily.
+
+### What steps will reproduce the problem?
+
+1. In `~/.ssh/config`, have some unrecognized options (e.g. `GSSAPIKeyExchange`) and a corresponding `IgnoreUnknown`.
+
+2. Try to use a git-annex feature which directly invokes ssh, e.g. get or drop.
+
+### What version of git-annex are you using? On what operating system?
+
+6.20161210 on Arch, but I think this was introduced in a 201611* release.
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Yes, it's been taking care of my archives for nearly a year.