Bug#743434: openssh-client: wildcard host precedence and CanonicalizeHostname

2014-04-04 Thread Alexander Volkov
2014-04-04 12:43 GMT+04:00 sergio : > On 04/04/2014 11:11 AM, Alexander Volkov wrote: > > > The answer you need was in the first letter - change the order of > > blocks in local config. Even after rereading foo matches the first > > block that has no delegate option. > > > The order doesn't matter

Bug#743434: openssh-client: wildcard host precedence and CanonicalizeHostname

2014-04-04 Thread sergio
On 04/04/2014 11:11 AM, Alexander Volkov wrote: > The answer you need was in the first letter - change the order of > blocks in local config. Even after rereading foo matches the first > block that has no delegate option. The order doesn't matter as: > This is simply not true due to the above.

Bug#743434: openssh-client: wildcard host precedence and CanonicalizeHostname

2014-04-04 Thread Alexander Volkov
03.04.2014, в 11:58, sergio написал(а): > On 04/03/2014 04:52 AM, Russ Allbery wrote: > >> That host block doesn't match that ssh command. Try changing it to: >> >> Host foo foo.mydomain.com >> >> and see if you get different behavior. He said that you wrote "host foo.mydomain.com" and use

Bug#743434: openssh-client: wildcard host precedence and CanonicalizeHostname

2014-04-03 Thread sergio
> /usr/share/doc/openssh-client/changelog.Debian.gz > openssh (1:6.5p1-1) unstable; urgency=medium should be http://www.openssh.com/txt/release-6.6 * ssh(1): if hostname canonicalisation is enabled and results in the destination hostname being changed, then re-parse ssh_config(5) files

Bug#743434: openssh-client: wildcard host precedence and CanonicalizeHostname

2014-04-03 Thread sergio
On 04/03/2014 04:52 AM, Russ Allbery wrote: > That host block doesn't match that ssh command. Try changing it to: > > Host foo foo.mydomain.com > > and see if you get different behavior. Have you noticed CanonicalizeHostname and CanonicalDomains? This block matches that ssh command otherw

Bug#743434: openssh-client: wildcard host precedence

2014-04-02 Thread Russ Allbery
Colin Watson writes: > While I don't have a fully working GSSAPI setup right now, I've > double-checked that the option parsing part of this really does work > correctly (gdb a fresh build of the ssh client, break on > read_config_file, "continue" then "finish" to get past the two parsing > runs,

Bug#743434: openssh-client: wildcard host precedence and CanonicalizeHostname

2014-04-02 Thread Russ Allbery
sergio writes: > host foo.mydomain.com > GSSAPIKeyExchange yes > GSSAPIAuthentication yes > GSSAPIDelegateCredentials yes > GSSAPIRenewalForcesRekey yes > % ssh foo klist > klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_UID) That host block does

Bug#743434: openssh-client: wildcard host precedence and CanonicalizeHostname

2014-04-02 Thread sergio
On 04/03/2014 12:53 AM, Russ Allbery wrote: > The rule, rather, is that the first match takes precedence. You want to > write this as ... and then it should work as you expect. Sorry. The real buggy combination is: /etc/ssh/ssh_config: host * GSSAPIDelegateCredentials no ~/.ssh/config: hos

Bug#743434: openssh-client: wildcard host precedence

2014-04-02 Thread Russ Allbery
mail...@sergio.spb.ru writes: > Right now wildcarad host '*' takes precedence over all other > declarations: > host * > GSSAPIDelegateCredentials no > host foo > GSSAPIKeyExchange yes > GSSAPIAuthentication yes > GSSAPIDelegateCredentials yes The rule, rather, is that th

Bug#743434: openssh-client: wildcard host precedence

2014-04-02 Thread mailbox
Package: openssh-client Version: 1:6.6p1-2 Severity: normal Right now wildcarad host '*' takes precedence over all other declarations: host * GSSAPIDelegateCredentials no host foo GSSAPIKeyExchange yes GSSAPIAuthentication yes GSSAPIDelegateCredentials yes % ss