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

Wed Jul 16 10:33:33 CEST 2014

Hi,

just a short remark again on the scope of the paper:

> 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.

As written in the introduction (chapter 1), it is for sysadmins.
For server-client software, like ssh, it is a force-multiplier that just
raises the constraints even for weakly configures clients.

It is the same with httpd server vs browser configurations: we just
provide the server part since we are talking 1:N here.

I also recommend the archives of this list since we discussed that
already some times before :)

Nevertheless, feel free to submit a pull request that adds curve25519
crypto! :)

Best,
Axel
On 16.07.2014 09:08, Dariusz Puchalak wrote:
> 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
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
URL: <http://lists.cert.at/pipermail/ach/attachments/20140716/4919b2cb/attachment.sig>