On 05/01/2017 04:48 PM, Cristian Ionescu-Idbohrn wrote:> On Mon, 1 May 2017, Cristian Ionescu-Idbohrn wrote: >> >> Example, 'Macs'. >> >> On the man page I read: >> >> "Multiple algorithms must be comma-separated. >> ... >> If the specified value begins with a '-' character, then the >> specified algorithms (including wildcards) will be removed" >> >> It seems that just one algo name is supported on such a line, example: >> >> Macs -umac-64* >> >> But this form is not supported: >> >> Macs -umac-64*,-hmac-sha1* >> >> nor is this: >> >> Macs -umac-64* >> Macs -hmac-sha1* >> >> And I have difficulties in finding _one_ pattern that matches _only_ >> the above algo families, but nothing else. >> >> Can you confirm this behaviour? Can it be improved?I believe this is expected behavior and limitation of the current behavior. The manual page also says > For each parameter, the first obtained value will be used. [...] > [...] will be removed *from the default set instead of replacing them*. Therefore: * Only the default set is affected * The second Macs option is ignored (because Macs are already set) This might be confusing especially when specifying multiple values and improving that would be very nice.> More observations. > > After doing one of the above in /etc/ssh/sshd_config: > > # sshd -tT | sort | egrep '^macs' > macs umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com, > hmac-sha2-512-etm at openssh.com,hmac-sha1-etm at openssh.com, > umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 > > umac-64* is gone, but I can still use umac-64 at openssh.com to login: > > $ ssh -oMacs=umac-64 at openssh.com localhost > > Can you confirm this behaviour?I would investigate the debug log with -vvv switches to see what is actually offered by server and client. -- Jakub Jelen Software Engineer Security Technologies Red Hat
On Tue, 2 May 2017, Jakub Jelen wrote:> > I believe this is expected behavior and limitation of the current behavior. > The manual page also says > > > For each parameter, the first obtained value will be used. [...] > > > [...] will be removed *from the default set instead of replacing them*. > > Therefore: > * Only the default set is affected > * The second Macs option is ignored (because Macs are already set)Yes. I missed that. Sorry :(> This might be confusing especially when specifying multiple values and > improving that would be very nice.Yes, please.> I would investigate the debug log with -vvv switches to see what is > actually offered by server and client.Alright, I just did: $ ssh -vvv -oMacs=umac-64 at openssh.com localhost : 2>&1 | egrep -i 'macs|umac' debug2: MACs ctos: umac-64 at openssh.com debug2: MACs stoc: umac-64 at openssh.com debug2: MACs ctos: umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 debug2: MACs stoc: umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 No error/warning/anything. I should also mention that this is the Debian packaged openssh 7.5p1. It applies some 31 patches to the source. I can't tell if they interfere with the proper behaviour, it doesn't seem so, but I can't exclude the risc. Colin might. Cheers, -- Cristian
On Tue, May 02, 2017 at 06:17:47PM +0200, Cristian Ionescu-Idbohrn wrote:> $ ssh -vvv -oMacs=umac-64 at openssh.com localhost : 2>&1 | egrep -i 'macs|umac' > debug2: MACs ctos: umac-64 at openssh.com > debug2: MACs stoc: umac-64 at openssh.com > debug2: MACs ctos: umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 > debug2: MACs stoc: umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 > > No error/warning/anything. > > I should also mention that this is the Debian packaged openssh 7.5p1. > It applies some 31 patches to the source. I can't tell if they > interfere with the proper behaviour, it doesn't seem so, but I can't > exclude the risc. Colin might.A clean build from upstream git master produces identical output from the above test command. -- Colin Watson [cjwatson at debian.org]
On Tue, 2 May 2017, Jakub Jelen wrote:> On 05/01/2017 04:48 PM, Cristian Ionescu-Idbohrn wrote: > > On Mon, 1 May 2017, Cristian Ionescu-Idbohrn wrote: > > > > > > Example, 'Macs'. > > > > > > On the man page I read: > > > > > > "Multiple algorithms must be comma-separated. > > > ... > > > If the specified value begins with a '-' character, then the > > > specified algorithms (including wildcards) will be removed" > > > > > > It seems that just one algo name is supported on such a line, example: > > > > > > Macs -umac-64* > > > > > > But this form is not supported: > > > > > > Macs -umac-64*,-hmac-sha1* > > > > > > nor is this: > > > > > > Macs -umac-64* > > > Macs -hmac-sha1* > > > > > > And I have difficulties in finding _one_ pattern that matches _only_ > > > the above algo families, but nothing else. > > > > > > Can you confirm this behaviour? Can it be improved?Back here, then...> I believe this is expected behavior and limitation of the current > behavior. The manual page also saysCouldn't find this part:> > For each parameter, the first obtained value will be used. [...]Which manual page was that on? But I found this:> > [...] will be removed *from the default set instead of replacing them*. > > Therefore: > * Only the default set is affected > * The second Macs option is ignored (because Macs are already set) > > This might be confusing especially when specifying multiple values > and improving that would be very nice.Created bz#2715 with: By accident, I just discovered a list of this form: Macs=-umac-64*,hmac-sha1* is supported (the '-' operates on the whole list). This form: Macs=-umac-64*,-hmac-sha1* ('-' in front of each pattern) is not supported. Ideally, a mix like this: Macs=-umac-64*,+foo*,-hmac-sha1* offers the best flexibility, IMO. Cheers, -- Cristian
On 05/08/2017 02:16 PM, Cristian Ionescu-Idbohrn wrote:> On Tue, 2 May 2017, Jakub Jelen wrote: >> I believe this is expected behavior and limitation of the current >> behavior. The manual page also says > > Couldn't find this part: > >>> For each parameter, the first obtained value will be used. [...] > > Which manual page was that on?In manual page of ssh_config. The logic in client and server configurations is very similar.> > But I found this: > >>> [...] will be removed *from the default set instead of replacing them*. >> >> Therefore: >> * Only the default set is affected >> * The second Macs option is ignored (because Macs are already set) >> >> This might be confusing especially when specifying multiple values >> and improving that would be very nice. > > Created bz#2715 with:That makes sense. Thanks. -- Jakub Jelen Software Engineer Security Technologies Red Hat