Re: Removing DSS and other unreasonable algorithms (Was: Missing signed-off for pkg chacha20 patches)

[Jakub Jelen <jjelen@xxxxxxxxxx>]

On Tue, 2018-06-19 at 15:51 +0100, Richard W.M. Jones wrote:
> On Tue, Jun 19, 2018 at 03:45:26PM +0100, Richard W.M. Jones wrote:
> > On Tue, Jun 19, 2018 at 04:35:49PM +0200, Jakub Jelen wrote:
> > > On Thu, 2018-06-14 at 16:03 +0200, Andreas Schneider wrote:
> > > > [...]
> > > > 
> > > > Looks like openssh removed support for ssh-dss. At least my
> > > > openssh
> > > > 7.7 
> > > > doesn't know about it at all.
> > > 
> > > The OpenSSH 7.7p1 still has the support for ssh-dss keys, but
> > > they are
> > > disabled by default for any use, unless you enable them using
> > > PubkeyAcceptedKeyTypes and friend configuration options. The
> > > reason why
> > > it is still there is probably because the DSA keys are mandatory
> > > part
> > > (REQUIRED) of RFC4253 (Section 6.6).
> > > 
> > > > I would remove it from libssh after the release of 0.8 together
> > > > with
> > > > SSHv1 
> > > > support.
> > > > 
> > > > I think we can remove it from pkd already? Comments?
> > > 
> > > Removing the ancient SSHv1, blowfish and other unreasonable
> > > algorithms
> > > makes sense for me.
> > 
> > Can we keep them in some way that allows us to connect to
> > RHEL 5 - era systems?
> > 
> > The background to this is that we currently use libssh2 (and intend
> > to
> > use libssh in the near future) to move VM workloads off old Xen
> > machines, and we do all that over ssh.
> > 
> > I'll just boot up a RHEL 5 instance to find out what algorithms it
> > offers ...
> 
> Attached is the ssh -v log from connecting to RHEL 5.11 using
> recent OpenSSH client.

It looks like you don't have any problem with connecting from OpenSSH
using SSH2 protocol with quite-reasonable ciphers to RHEL5.

The only issue here is that algorithms in this case rely on SHA1
(nothing else is supported in RHEL5 openssh-4.3p2). But removing SSH1
protocol and DSA public key algorithms does not affect you.

Side note is that these SHA1 based algorithms might not be available in
future by default and might need to be explicitly enabled.

-- 
Jakub Jelen
Software Engineer
Security Technologies
Red Hat, Inc.