Kategorie:SSH/Kryptografie: Unterschied zwischen den Versionen

Beschreibung

Symmetrische Verschlüsselung

Wer als Laie an Verschlüsselung denkt, der denkt meist an die "symmetrische Verschlüsselung".

• Hierbei gibt es genau einen Schlüssel, mit dem ein Datensatz verschlüsselt wird.

Nur wer diesen Schlüssel kennt (oder durch Probieren herausfindet) kann die Verschlüsselung umkehren und den Klartext wieder extrahieren.

Bekannte und bewährte Algorithmen wie TripleDES, AES und Blowfish machen das Erraten des Schlüssels natürlich nicht gerade leicht, genauer gesagt, nach dem heutigen Stand der Technik nahezu unmöglich.

Das einzige Problem bei der Benutzung von symmetrischer Verschlüsselung ist, den Schlüssel sicher zum Kommunikationspartner zu befördern.

Asymmetrische Verschlüsselung

Um dieses Problem der symmetrischen Verschlüsselung zu umgehen, gelang es Forschern schon vor einiger Zeit, das gemeinsame Geheimnis, das für eine erfolgreiche Ver- und Entschlüsselung nötig ist, so hinter komplizierten Algorithmen zu verbergen, dass man es unter bestimmten Bedingungen öffentlich verteilen konnte.

Bei diesem Verfahren, asymmetrische Verschlüsselung genannt, wird nicht ein Schlüssel erzeugt, sondern ein Schlüsselpaar, das mathematisch voneinander abhängt, aber nicht ohne sehr viel Aufwand voneinander abgeleitet werden kann.

Jeweils zwei zueinander passende Schlüssel wirken auf geradezu magische Weise genau entgegengesetzt: Was mit dem einen Schlüssel verschlüsselt wird, kann nur durch den anderen Schlüssel wieder entschlüsselt werden.

Dies ermöglicht es, einen der beiden Schlüssel öffentlich zur Verfügung zu stellen, um Sendungen zu verschlüsseln, die man aber einzig und allein mit dem anderen Schlüssel, den man niemals weitergibt, entschlüsseln kann.

Im Gegenzug kann man ein Datenpaket auch mit dem eigenen privaten Schlüssel chiffrieren.

• Wenn dieser Chiffretext sich dann mit dem öffentlichen Schlüssel wieder in Klartext zurückverwandeln lässt, weiß jeder, dass die Nachricht nur vom Besitzer des privaten Schlüssels kommen kann.

Diese Anwendungsmöglichkeit nennt man digitale Signatur.

Da der Umgang mit asymmetrischen Verschlüsselungsalgorithmen wie RSA oder DSA signifikant mehr Rechenleistung erfordert als mit symmetrischen, ist es gängige Praxis, am Beginn der Kommunikation mit Hilfe des öffentlichen Schlüssels einen neu generierten, symmetrischen Session-Schlüssel auszutauschen und für den Rest der Kommunikation auf symmetrische Verschlüsselung umzusteigen.

OpenSSH server

Configuration

Different versions of OpenSSH support different options which are not always compatible.

• This guide shows settings for the most commonly deployed OpenSSH versions at Mozilla - however, using the latest version of OpenSSH is recommended.

Modern (OpenSSH 6.7+)

File: /etc/ssh/sshd_config

 # Supported HostKey algorithms by order of preference.
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key

KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256

Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

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

# Password based logins are disabled - only public key based logins are allowed.

AuthenticationMethods publickey

# 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

# Log sftp level file access (read/write/etc.) that would not be easily logged otherwise.

Subsystem sftp /usr/lib/ssh/sftp-server -f AUTHPRIV -l INFO

# 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

# Use kernel sandbox mechanisms where possible in unprivileged processes
# Systrace on OpenBSD, Seccomp on Linux, seatbelt on MacOSX/Darwin, rlimit elsewhere.

UsePrivilegeSeparation sandbox

File: /etc/ssh/moduli

All Diffie-Hellman moduli in use should be at least 3072-bit-long (they are used for diffie-hellman-group-exchange-sha256) as per our Security/Guidelines/Key_Management recommendations.

• See also man moduli.

To deactivate short moduli in two commands: awk '$5 >= 3071' /etc/ssh/moduli > /etc/ssh/moduli.tmp && mv /etc/ssh/moduli.tmp /etc/ssh/moduli

Intermediate (OpenSSH 5.3)

This is mainly for use by RHEL6, CentOS6, etc.

• which run older versions of OpenSSH.

File: /etc/ssh/sshd_config

# 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

# 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

# Log sftp level file access (read/write/etc.) that would not be easily logged otherwise.

Subsystem sftp /usr/lib/ssh/sftp-server -f AUTHPRIV -l INFO

# 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

File: /etc/ssh/moduli

All Diffie-Hellman moduli in use should be at least 2048-bit-long.

• From the structure of moduli files, this means the fifth field of all lines in this file should be greater than or equal to 2047.

To deactivate weak moduli in two commands: awk '$5 >= 2047' /etc/ssh/moduli > /etc/ssh/moduli.tmp && mv /etc/ssh/moduli.tmp /etc/ssh/moduli

Multi-Factor Authentication (OpenSSH 6.3+)

Recent versions of OpenSSH support MFA (Multi-Factor Authentication).

• Using MFA is recommended where possible.

It requires additional setup, such as using the OATH Toolkit or DuoSecurity.

ATTENTION

In order to allow using one time passwords (OTPs) and any other text input, Keyboard-interactive is enabled in OpenSSH. This MAY allow for password authentication to work. It is therefore very important to check your PAM configuration so that PAM disallow password authentication for OpenSSH.

OpenSSH 6.3+ (default)

File: /etc/ssh/sshd_config

# IMPORTANT: you will have to ensure OpenSSH cannot authenticate with passwords with PAM in /etc/pam.d/sshd
# "PasswordAuthentication no" is not sufficient!
PubkeyAuthentication yes
PasswordAuthentication no
AuthenticationMethods publickey,keyboard-interactive:pam
KbdInteractiveAuthentication yes
UsePAM yes
# Ensure /bin/login is not used so that it cannot bypass PAM settings for sshd.
UseLogin no

OpenSSH 5.3+ w/ RedHat/CentOS patch (old)

File: /etc/ssh/sshd_config

# Allow keyboard-interactive.
# IMPORTANT: you will have to ensure OpenSSH cannot authenticate with passwords with PAM in /etc/pam.d/sshd
# "PasswordAuthentication no" is not sufficient!
RequiredAuthentications2 publickey,keyboard-interactive:skey
PasswordAuthentication no
ChallengeResponseAuthentication yes
UsePAM yes
# Ensure /bin/login is not used so that it cannot bypass PAM settings for sshd.
UseLogin no

PAM configuration for use with the OATH Toolkit or DuoSecurity as second authentication factor. 

File: /etc/pam.d/sshd

#%PAM-1.0
auth       required     pam_sepermit.so

# WARNING: make sure any password authentication module is disabled.
# Example: pam_unix.so, or "password-auth", "system-auth", etc.
#auth       include      password-auth

# Options to enable when using OATH toolkit
#auth       requisite     pam_oath.so usersfile=/etc/users.oath digits=6 window=20

# Options to enable when using DuoSecurity
#auth    sufficient      /lib64/security/pam_duo.so

account    required     pam_nologin.so

Ciphers and algorithms choice

• When CHACHA20 (OpenSSH 6.5+) is not available, AES-GCM (OpenSSH 6.1+) and any other algorithm using EtM (Encrypt then MAC) disclose the packet length - giving some information to the attacker.
• Only recent OpenSSH servers and client support CHACHA20.

• NIST curves (ecdh-sha2-nistp512,ecdh-sha2-nistp384,ecdh-sha2-nistp256) are listed for compatibility, but the use of curve25519 is generally preferred.

• SSH protocol 2 supports DH and ECDH key-exchange as well as forward secrecy.
• Regarding group sizes, please refer to Security/Guidelines/Key_Management.

The various algorithms supported by a particular OpenSSH version can be listed with the following commands:

$ ssh -Q cipher
$ ssh -Q cipher-auth
$ ssh -Q mac
$ ssh -Q kex
$ ssh -Q key