Re: svn commit: r49211 - head/en_US.ISO8859-1/articles/committers-guide

Matthew Seaman <[email protected]>
Newsgroups gmane.os.freebsd.devel.cvs.doc
Message-ID <[email protected]>
On 2016/08/04 16:07, Warren Block wrote:
> On Thu, 4 Aug 2016, Kubilay Kocak wrote:
> 
>> On 4/08/2016 1:43 AM, Benedict Reuschling wrote:
>>> Author: bcr
>>> Date: Wed Aug  3 15:43:10 2016
>>> New Revision: 49211
>>> URL: https://svnweb.freebsd.org/changeset/doc/49211
>>>
>>> Log:
>>>   Remove mention of specific key types to discourage the generation
>>>   of old and potentially insecure keys.
>>>
>>>   Discussed with:        David Wolfskill
>>>
>>> Modified:
>>>   head/en_US.ISO8859-1/articles/committers-guide/article.xml
>>>
>>> Modified: head/en_US.ISO8859-1/articles/committers-guide/article.xml
>>> ==============================================================================
>>>
>>> --- head/en_US.ISO8859-1/articles/committers-guide/article.xml    Wed
>>> Aug  3 13:59:21 2016    (r49210)
>>> +++ head/en_US.ISO8859-1/articles/committers-guide/article.xml    Wed
>>> Aug  3 15:43:10 2016    (r49211)
>>> @@ -3105,7 +3105,7 @@ Relnotes:           yes</programlisting>
>>>      <procedure>
>>>        <step>
>>>      <para>If you do not wish to type your password in every time
>>> -      you use &man.ssh.1;, and you use RSA or DSA keys to
>>> +      you use &man.ssh.1;, and you use keys to
>>>        authenticate, &man.ssh-agent.1; is there for your
>>>        convenience.  If you want to use &man.ssh-agent.1;, make
>>>        sure that you run it before running other applications.  X
>>
>> Without making a bikeshed out of it, could we provide some basic
>> recommendations here? Examples (note: *just* examples)
>>
>> rsa with new key format, preferred bits, explicit passphrase
>>
>> -o -t rsa -b <whateverwewant> -N <passprhase>
>>
>> ed25519 with new key format, explicit passphrase
>>
>> -t ed25519 -o -N <passphrase> (new format)
>>
>> These might help ensure people don't accidentally (or through lack of
>> knowledge) create keys without passphrases, and provide a bump up on the
>> (openssh) defaults.
>>
>> I'd be happy to write something short and sweet up in the wiki for
>> review first if needed, as well as get input from secteam and other
>> people as well.
> 
> Agreed.  Without recommendations, inexperienced users are just going to
> accept the defaults.  Which is fine, if the defaults are good.

One thing I'd definitely like to see added is to advise people that if
they want to use a RSA key, they should set the bit-length to 2048 at
minimum and preferably use 4096.

Not sure about recommended lengths for ECDSA -- personally I like
ED25519 where the whole question of key length is a non-issue.

There is some prior-art we might refer to:

https://wiki.mozilla.org/Security/Guidelines/OpenSSH
https://stribika.github.io/2015/01/04/secure-secure-shell.html

which mostly talk about hardening SSH servers, but there are some good
passages about client-side configuration.

	Cheers,

	Matthew
signature.asc (application/pgp-signature, 972 B)
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQJ8BAEBCgBmBQJXo2UpXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxOUYxNTRFQ0JGMTEyRTUwNTQ0RTNGMzAw
MDUxM0YxMEUwQTlFNEU3AAoJEABRPxDgqeTnixgP/iOPqvto3p6r8kA3WUnzz0gw
yKAjJiRJMVEFZo6fyfyxmRNopwWNffLJny/s7S7dl1yPNM0U7ddRMAh++tnDNT8o
X+wEUMIn9v+r92oLuVtUQFKAzT4L239v8G6B4mAl9nCg2nlSeKGaMkPwol+v4Bhh
AXYnM+LJkLKL/MMbnB1kAnDMkC66FfOpkaaeQ0Y5JCXXCHEFtl0L+dKzHj3zqoyG
Vm+2hGNMXhD3Rlyqv5+DktSMywsCfhiZOh9OM3oHEOej3wRc5jcYxrNRmKy9OVXH
V2l1gPHEujvhEfoP9VnWtzAPQ/5LBgr8s5m7ybrI+/wAbFqV8Ys23arwG5+dXMKE
3Tal1jUgwqDmXQVz8/ZfWmjAQhozWTNDt0eeV4Ca1W42rLTyZHbiZ7mZ7GEEOif3
KcegLleO6pFhZTYEUeCqVa4UjVPQnA18mxAM8f6dbMCuwcue8xmROgseCiYDHAMI
SDVixu71B3W4+CRvHgU0HIH0SIPy8JobjEqR+mCyZ+dDLV9wgFJ0SwnFg2+4ocTy
cJ8vm5M/1G5pEvr0DYo666DfufET6RIyXchoNqT4un+VFRUKWh+/FCvkqCMVEiFm
TBnGgLb+PrO59Us//Q18hS9xPzctL6Jf4qr8QNe+M9hB3Yop53mYbrxoJ4sFar/n
gXYuJU3kfhz1p+M1CUCm
=lxLl
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.