Security/Guidelines/OpenSSH: Difference between revisions

reordering
(reordering)
Line 10: Line 10:
|-  
|-  
|  <span style="color:orange;">'''DRAFT'''</span> ||
|  <span style="color:orange;">'''DRAFT'''</span> ||
* Version 1.5: kang/ulfr: ordering
* Version 1.4: kang/michal: Multiple small fixes and additions. Reorganized config doc for readability.
* Version 1.4: kang/michal: Multiple small fixes and additions. Reorganized config doc for readability.
* Version 1.3: kang/alm: Added information on ssh-agent/ssh-add flags for agent forwarding.
* Version 1.3: kang/alm: Added information on ssh-agent/ssh-add flags for agent forwarding.
Line 32: Line 33:
|}
|}


= Data classification =
= OpenSSH '''server''' =
== Key material ==
== Configuration ==
Key material identifies the cryptographic secrets that compose a key. All key material must be treated as restricted data, meaning that only individual with specific training and need-to-know should have access to key material. Key material must be encrypted on transmission. Key material can be stored in clear text, but with proper access control.
 
This includes OpenSSH server keys (<code>/etc/ssh/ssh_host_*key</code>) and client keys (<code>~/.ssh/id_{rsa,dsa,ecdsa,ed25519}</code> and <code>~/.ssh/identity</code>).
 
<code>/etc/ssh/moduli</code> also contains prime numbers and generators for use in the Diffie-Hellman key exchange and must be handled like key material.
 
= OpenSSH server configuration =
Different versions of OpenSSH support different options which are not always compatible.
Different versions of OpenSSH support different options which are not always compatible.
This guide show settings for the most commonly deployed OpenSSH versions at Mozilla - however, using the latest version of OpenSSH is recommended.
This guide show settings for the most commonly deployed OpenSSH versions at Mozilla - however, using the latest version of OpenSSH is recommended.


=== Notes on ciphers and algorithms choice ===
=== '''Modern''' (OpenSSH 6.7+) ===
* When CHACHA20 (OpenSSH 6.5+) is not available, AES-GCM (OpenSSH 6.1+) may be used as it's faster than AES-CTR. It is not selected by default due to the way it's [http://blog.djm.net.au/2013/11/chacha20-and-poly1305-in-openssh.html implemented in OpenSSH] - it allows an attacker to see the packet length. Instead an optional configuration item (commented-out by default) is provided if you nevertheless want to benefit from the speed advantage (mainly for heavy SCP usage) and CHACHA20 is not available.
 
* NIST curves (<code>ecdh-sha2-nistp512,ecdh-sha2-nistp384,ecdh-sha2-nistp256</code>) are listed for compatibility, but the use of <code>curve25519</code> is [http://safecurves.cr.yp.to/ generally preferred].
 
* SSH protocol 2 supports [https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange DH] and [https://en.wikipedia.org/wiki/Elliptic_curve_Diffie%E2%80%93Hellman ECDH] key-exchange as well as [https://en.wikipedia.org/wiki/Forward_secrecy forward secrecy].
 
The various algorithms supported by a particular OpenSSH version can be listed with the following commands:
 
<source code="bash">
$ ssh -Q cipher
$ ssh -Q cipher-auth
$ ssh -Q mac
$ ssh -Q kex
$ ssh -Q key
</source>
 
== OpenSSH 6.7+ (Most recent) ==
File: <code>/etc/ssh/sshd_config</code>
File: <code>/etc/ssh/sshd_config</code>


Line 73: Line 50:


Ciphers chacha20-poly1305@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
Ciphers chacha20-poly1305@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
# If SCP performance is required and clients do not support CHACHA30, consider using AES-GCM instead. This is a security trade-off.
# If SCP performance is required and clients do not support CHACHA20, consider using AES-GCM instead. This is a security trade-off.
#Ciphers aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
#Ciphers aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr


Line 100: Line 77:
</source>
</source>


== OpenSSH 6.3+ with MFA ==
=== '''Old''' (OpenSSH 5.3) ===
This is mainly for use by RHEL6, CentOS6, etc. which run older versions of OpenSSH.
 
File: <code>/etc/ssh/sshd_config</code>
 
<source>
# Supported HostKey algorithms by order of preference.
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
 
KexAlgorithms diffie-hellman-group-exchange-sha256
MACs hmac-sha2-512,hmac-sha2-256
Ciphers aes256-ctr,aes192-ctr,aes128-ctr
 
# KeyRegenerationInternal is halved from the default as a precaution (optional). 1800 seconds is 30 minutes.
KeyRegenerationInterval 1800
 
# Password based logins are disabled - only public key based logins are allowed.
RequiredAuthentications2 publickey
 
# RequiredAuthentications2 not work on official OpenSSH 5.3 portable.
# In this is your case, use this instead:
#PubkeyAuthentication yes
#PasswordAuthentication no
 
# LogLevel VERBOSE logs user's key fingerprint on login. Needed to have a clear audit track of which key was using to log in.
LogLevel VERBOSE
 
# Root login is not allowed for auditing reasons. This is because it's difficult to track which process belongs to which root user:
#
# On Linux, user sessions are tracking using a kernel-side session id, however, this session id is not recorded by OpenSSH.
# Additionally, only tools such as systemd and auditd record the process session id.
# On other OSes, the user session id is not necessarily recorded at all kernel-side.
# Using regular users in combination with /bin/su or /usr/bin/sudo ensure a clear audit track.
PermitRootLogin No
</source>
 
=== '''Multi-Factor Authentication''' (OpenSSH 6.3+) ===
Recent versions of OpenSSH support MFA (Multi-Factor Authentication). Using MFA is recommended where possible.
Recent versions of OpenSSH support MFA (Multi-Factor Authentication). Using MFA is recommended where possible.
It requires additional setup, such as using the [http://www.nongnu.org/oath-toolkit/ OATH Toolkit] or [https://www.duosecurity.com DuoSecurity].


{| class="wikitable"
{| class="wikitable"
Line 142: Line 158:
</source>
</source>


== OpenSSH 5.3 (RHEL6, CentOS6, etc.) ==
== Ciphers and algorithms choice ==
File: <code>/etc/ssh/sshd_config</code>
* When CHACHA20 (OpenSSH 6.5+) is not available, AES-GCM (OpenSSH 6.1+) may be used as it's faster than AES-CTR. It is not selected by default due to the way it's [http://blog.djm.net.au/2013/11/chacha20-and-poly1305-in-openssh.html implemented in OpenSSH] - it allows an attacker to see the packet length. Instead an optional configuration item (commented-out by default) is provided if you nevertheless want to benefit from the speed advantage (mainly for heavy SCP usage) and CHACHA20 is not available.


<source>
* NIST curves (<code>ecdh-sha2-nistp512,ecdh-sha2-nistp384,ecdh-sha2-nistp256</code>) are listed for compatibility, but the use of <code>curve25519</code> is [http://safecurves.cr.yp.to/ generally preferred].
# Supported HostKey algorithms by order of preference.
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key


KexAlgorithms diffie-hellman-group-exchange-sha256
* SSH protocol 2 supports [https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange DH] and [https://en.wikipedia.org/wiki/Elliptic_curve_Diffie%E2%80%93Hellman ECDH] key-exchange as well as [https://en.wikipedia.org/wiki/Forward_secrecy forward secrecy].
MACs hmac-sha2-512,hmac-sha2-256
Ciphers aes256-ctr,aes192-ctr,aes128-ctr


# KeyRegenerationInternal is halved from the default as a precaution (optional). 1800 seconds is 30 minutes.
The various algorithms supported by a particular OpenSSH version can be listed with the following commands:
KeyRegenerationInterval 1800


# Password based logins are disabled - only public key based logins are allowed.
<source code="bash">
RequiredAuthentications2 publickey
$ ssh -Q cipher
$ ssh -Q cipher-auth
$ ssh -Q mac
$ ssh -Q kex
$ ssh -Q key
</source>


# RequiredAuthentications2 not work on official OpenSSH 5.3 portable.
= OpenSSH '''client''' =
# In this is your case, use this instead:
== Configuration ==
#PubkeyAuthentication yes
If you have a file containing known_hosts using RSA or ECDSA host key algorithm and the server now supports ed25519 for example, you will get a warning that the host key has changed and will be unable to connect. This means you will have to verify the new host key.
#PasswordAuthentication no


# LogLevel VERBOSE logs user's key fingerprint on login. Needed to have a clear audit track of which key was using to log in.
The following configurations expect a recent OpenSSH client, as updating OpenSSH on the client side is generally not an issue.
LogLevel VERBOSE


# Root login is not allowed for auditing reasons. This is because it's difficult to track which process belongs to which root user:
=== '''Modern''' ===
#
This configuration is less compatible and you may not be able to connect to some servers which use insecure, deprecated algorithms.
# On Linux, user sessions are tracking using a kernel-side session id, however, this session id is not recorded by OpenSSH.
Nevertheless, modern servers will work just fine.
# Additionally, only tools such as systemd and auditd record the process session id.
# On other OSes, the user session id is not necessarily recorded at all kernel-side.
# Using regular users in combination with /bin/su or /usr/bin/sudo ensure a clear audit track.
PermitRootLogin No
</source>
 
= OpenSSH client configuration =
=== Base configuration ===
If you have a file containing known_hosts using RSA or ECDSA host key algorithm, while the server now supports ed25519 for example, you will get a warning that the host key has changed and will be unable to connect. This means you will have to verify the new host key.


File: <code>~/.ssh/config</code>
File: <code>~/.ssh/config</code>
Line 187: Line 191:
# Host keys the client accepts - order here is honored by OpenSSH
# Host keys the client accepts - order here is honored by OpenSSH
HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-ed25519,ssh-rsa,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521,ecdsa-sha2-nistp384,ecdsa-sha2-nistp256
HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-ed25519,ssh-rsa,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521,ecdsa-sha2-nistp384,ecdsa-sha2-nistp256
KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp256,ecdh-sha2-nistp384,diffie-hellman-group-exchange-sha256
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com
Ciphers chacha20-poly1305@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
# If you use SCP a lot, you might also consider using AES-GCM for servers not supporting CHACHA20. There is a security trade-off.
#Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
</source>
</source>


=== Hardened configuration ===
=== '''Intermediate''' configuration ===
This configuration is less compatible and you may not be able to connect to some servers which use insecure, deprecated algorithms.
This configuration can connect to older OpenSSH servers which run old or intermediate configurations.
Nevertheless, most servers should work just fine.


File: <code>~/.ssh/config</code>
File: <code>~/.ssh/config</code>
Line 199: Line 209:
# Host keys the client accepts - order here is honored by OpenSSH
# Host keys the client accepts - order here is honored by OpenSSH
HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-ed25519,ssh-rsa,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521,ecdsa-sha2-nistp384,ecdsa-sha2-nistp256
HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-ed25519,ssh-rsa,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521,ecdsa-sha2-nistp384,ecdsa-sha2-nistp256
KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp256,ecdh-sha2-nistp384,diffie-hellman-group-exchange-sha256
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com
Ciphers chacha20-poly1305@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
# If you use SCP a lot, you might also consider using AES-GCM for servers not supporting CHACHA20. There is a security trade-off.
#Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
</source>
</source>


= OpenSSH client keys handling =
== Client keys handling ==
== Generation ==
=== Key generation ===
Large key sizes are used as SSH keys are not renewed very often (see also [[Security/Key_Management]]).
Large key sizes are used as SSH keys are not renewed very often (see also [[Security/Key_Management]]).


Line 221: Line 224:
</source>
</source>


=== Protection of user keys ===
==== Protection of user keys ====
* Protected by strong passphrase.
* Protected by strong passphrase.
* Never copied to another system than your own workstation/personal physical disks/tokens.
* Never copied to another system than your own workstation/personal physical disks/tokens.
* Use SSH forwarding or SSH tunneling if you need to jump between hosts. '''DO NOT''' maintain unnecessary agent forwarding when unused.
* Use SSH forwarding or SSH tunneling if you need to jump between hosts. '''DO NOT''' maintain unnecessary agent forwarding when unused.


==== SSH agent forwarding ====
==== Protection of machine keys ====
When SSH keys are necessary for automation between systems, it is reasonable to use passphrase-less keys.
* The recommended settings are identical to the user keys.
* The keys must be accessible only by the admin user (root) and/or the system user requiring access.
Usage of machine keys should be registered in an inventory (a wiki page, ldap, an inventory database), to allow for rapid auditing of key usage across an infrastructure.
 
=== SSH agent forwarding ===
{| class="wikitable"
{| class="wikitable"
|-
|-
Line 299: Line 308:
This will automatically forward the SSH connection over ssh.mozilla.com when you connect to a mozilla.com SSH server.
This will automatically forward the SSH connection over ssh.mozilla.com when you connect to a mozilla.com SSH server.


=== Protection of machine keys ===
= Appendixes =
When SSH keys are necessary for automation between systems, it is reasonable to use passphrase-less keys.
== Key material handling ==
* The recommended settings are identical to the user keys.
Key material identifies the cryptographic secrets that compose a key. All key material must be treated as <span style="color: orange">RESTRICTED</span> data, meaning that:
* The keys must be accessible only by the admin user (root) and/or the system user requiring access.
* Only individual with specific training and need-to-know should have access to key material.
Usage of machine keys should be registered in an inventory (a wiki page, ldap, an inventory database), to allow for rapid auditing of key usage across an infrastructure.
* Key material must be encrypted on transmission.
* Key material can be stored in clear text, but only with proper access control (limited access).
 
This includes:
* OpenSSH server keys (<code>/etc/ssh/ssh_host_*key</code>)
* Client keys (<code>~/.ssh/id_{rsa,dsa,ecdsa,ed25519}</code> and <code>~/.ssh/identity</code>).
* <code>/etc/ssh/moduli</code> also contains prime numbers and generators for use in the Diffie-Hellman key exchange and must be handled like key material.


= Reference documents =  
== Reference documents ==


* [https://wiki.mozilla.org/Security/Key_Management Key Management]
* [https://wiki.mozilla.org/Security/Key_Management Key Management]
Confirmed users
502

edits