[Ach] Settings for OpenSSH - missing client side configuration.
Aaron Zauner
azet at azet.org
Wed Jul 16 01:26:50 CEST 2014
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.
having said this - you can easily adapt the OpenSSH server settings for
your clients.
> I think it's worth including this one too.
> So we can enforce good crypto on the client side too.
> And it can be a good education, because I have heard many
> complains about OpenSSH that were not true
> i.e. you cannot choose AES mode
Actually the default in OpenSSH has been AES128-CTR for a while now.
> (in putty only - but almost no one knew that they can
> do it on openssh).
> People take putty shortcommings as OpenSSH problems. :(
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
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
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
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
>
> It's the default that can be change on per host basis by doing thing like:
> Host old_and_buggy
> HostName example.com
> User scorpius
> Port 80
> Ciphers aes128-cbc
> MACs hmac-sha1
>
> 2. HostKeyAlgorithms - I'm not sure about what's the
> difference beetwen ssh-rsa-cert-v01 at openssh.com and
> ssh-rsa-cert-v00 at openssh.com .
> I need to dig more into the specification and source code.
It's a OpenSSH internal versioning of the way the produce and read RSA
certificates as far as I know. I might be wrong though - but I can't
find anything contrary in the source code.
>
> But I still think it's esssential to disable DSA on server
> and client too.
>
> 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.
I agree that we should include this reasoning into the paper.
Aaron
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.cert.at/pipermail/ach/attachments/20140716/67d2c730/attachment.sig>
More information about the Ach
mailing list