[Ach] Settings for OpenSSH - missing client side configuration.

Dariusz Puchalak Dariusz at Puchalak.net
Wed Jul 16 09:08:43 CEST 2014


On Wed, Jul 16, 2014 at 01:26:50AM +0200, Aaron Zauner wrote:
> Hi Dariusz,
> 
> Thanks for your input! A few remarks on your e-mail:
> 
> Dariusz Puchalak wrote:
> > Hi,
> > 
> > I just skimed over Applied Crypto Hardening.
> > Excelent guide! Thanks. :)
> > 
> > I have some remarks:
> > 
> > 1. On the OpenSSH part, you missed client side
> > configuration.
> > Just as you can specify server side sshd_config
> > you can also specify client side ssh_config.
> 
> As other people have pointed out: it's not the scope of the project, we
> do not provide client-side configuration recommendations; this just
> would be far too much to maintain.

As i have seen one said that it's out of scope, and another
that it's important to also secure client side.
I disagree with you, understand your point of view. :)

Please reconsider that system is as secure as the weakest link in the chain.
Be it human, client or server part.

> having said this - you can easily adapt the OpenSSH server settings for
> your clients.

Yes - that's what I know, but no so many of the others. :(

I do deliver Linux (and security too) technical trainings from
major linux vendors. 
Official materials don't mention ssh client side configuration,
as far as I remember. So future sysadmins might not know it.

I did quite a few presentations about OpenSSH on different conferences
(even security ones) and was really supprised, that most of people
who listen to me didn't know about such basic things like what we are
talking about.

Even few known security resarchers told me that they enjoy my presentations
and learnt something new. :) I just present things that
are already mention in manual.

I just do ask you to verify what I'm saing by doing
simple exercise. Ask your friend, coworkers how to protect 
your self from abuse of ssh keys used with cron (or other automated
unsupervised tasks) and where is it in the documentation.
I mean thins like command=...,from=...,no-agent-forwarding,no-port-forwarding
This is in sshd man page  section AUTHORIZED_KEYS FILE FORMAT.

I know this is out of scope, but I just wanted to show you
that many people don't read documentation for various reasons.

On business side, the sysadmins job is to make something work. 
He/she usually doesn't have time to read all the manuals.

If it is going to be copy&paste thae I think it is essentail to 
at least mention it.

[..]

> Putty is ancient crap with their own crypto implementation nobody ever
> cared to audit. Just saying. You can't even use all the HMACs that

Yeah, I know. I always tell my audience that using putty
is like eating ice creams over the glass. ;>

I think, that what you just said is worth mentioning in the
paper. 

> OpenSSH provides, for example: RIPEMD-160 will not work - simply because
> it's not implemented.
> 
> > 
> > In example part of my config file
> > (can be /etc/ssh/ssh_config and/or ~/.ssh/config)
> > Host *
> >         StrictHostKeyChecking ask
> >         ForwardAgent no
> >         ForwardX11 no
> >         ForwardX11Trusted no
> >         GatewayPorts no
> >         Protocol 2
> >         CheckHostIP yes
> >         Ciphers aes256-ctr,aes128-ctr
> >         MACs hmac-sha2-512,hmac-sha2-256,hmac-ripemd160
> >         KexAlgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1
> > 	HostKeyAlgorithms ssh-rsa-cert-v01 at openssh.com,ssh-rsa-cert-v00 at openssh.com,ssh-rsa
> >         ServerAliveInterval 30
> >         TCPKeepAlive yes
> >         PreferredAuthentications publickey,password
> >         IPQoS lowdelay throughput
> 
> Actually for current OpenSSH versions (upstream - 6.5+) I don't
> recommend to change their defaults at all unless you have a very
> specific environment and reason to do so. Their defaults are excellent
> nowadays. To the best of my knowledge they have never been "bad".
> 
> For example: the KeyExchange algorithms you listed are not selected
> correctly; you'd probably want to prefer Group 14. OpenSSH does support

Yes, you are right!, thanks. :)

> UMAC instead of SHA - which on recent intel and AMD platforms will give
> you a huge performance improvement over SHA. I did some benchmarks about
> two months back, the difference can be as much as 30%. Still need to
> publish those somewhere. Disabling X11 forwarding is unique to your
> setup, some people might need that for GUI applications. It also

Again out of scope for this paper, but that's what they can change
on per host setup in config file.
Forwarding X11 is security problem. If you are have root rights
on machine to which I connected you can see my screen
and read my key that I press on the keyboard. (xauth, xwd)

I even once saw presentation on major security conference in
Poland, where presenter said how cool is it to use
agnet forwarding! which is completely unsecure - it's much better 
to use ProxyCommand.

> supports AES-GCM, which will be a bit faster than AES-CTR (and a lot
> faster if you've not used UMAC, as I mentioned).
> 
> These are the current defaults:
> https://github.com/openssh/openssh-portable/blob/master/myproposal.h

I'll look at these. Thanks, for the link. :)

[..]

> > 3. Why no ECDSA for OpenSSH?
> > I have read Theory part and 
> > 3.5. A note on Elliptic Curve Cryptography,
> > but I'm not convinced :)
> > A few more sentences about SSH and ECDSA would be nice,
> > just like about DSS. 
> 
> e.g.:
> *) http://people.csail.mit.edu/rivest/pubs/RHAL92.pdf
> *) http://blog.cr.yp.to/20140323-ecdsa.html
> 
> If you want something small and elliptic curve based use curve25519.
> OpenSSH supports it.

Yes, that is great. I'm convinced now. :) I would love to see this
on the document with info, that it's since 6.5.


Dariusz

-- 
"If money is your hope for independence you will never have it. 
 The only real security that a man will have in this world is a 
 reserve of knowledge, experience, and ability."
                                                -- Henry Ford 




More information about the Ach mailing list