Kategorie:SSH/Kryptografie: Unterschied zwischen den Versionen

Aus Foxwiki
Keine Bearbeitungszusammenfassung
Der Seiteninhalt wurde durch einen anderen Text ersetzt: „Kategorie:Kryptografie/Best Practice Kategorie:SSH
Markierung: Ersetzt
 
(96 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
== Beschreibung ==
[[Kategorie:Kryptografie/Best Practice]]
=== Symmetrische Verschlüsselung ===
[[Kategorie:SSH]]
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: <tt>/etc/ssh/sshd_config</tt>
 
  # 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: <tt>/etc/ssh/moduli</tt>
 
All Diffie-Hellman moduli in use should be at least 3072-bit-long (they are used for <tt>diffie-hellman-group-exchange-sha256</tt>) as per our [https://wiki.mozilla.org/Security/Guidelines/Key_Management Security/Guidelines/Key_Management] recommendations.
* See also <tt>man moduli</tt>.
 
To deactivate short moduli in two commands: <tt>awk '$5 >= 3071' /etc/ssh/moduli > /etc/ssh/moduli.tmp && mv /etc/ssh/moduli.tmp /etc/ssh/moduli</tt>
 
==== Intermediate (OpenSSH 5.3) ====
This is mainly for use by RHEL6, CentOS6, etc.
* which run older versions of OpenSSH.
 
File: <tt>/etc/ssh/sshd_config</tt>
 
# 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: <tt>/etc/ssh/moduli</tt>
 
All Diffie-Hellman moduli in use should be at least 2048-bit-long.
* From the structure of <tt>moduli</tt> 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: <tt>awk '$5 >= 2047' /etc/ssh/moduli > /etc/ssh/moduli.tmp && mv /etc/ssh/moduli.tmp /etc/ssh/moduli</tt>
 
==== 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 [http://www.nongnu.org/oath-toolkit/ OATH Toolkit] or [https://www.duosecurity.com/ DuoSecurity].
 
{|| class="wikitable sortable"
|-
|| <span >'''ATTENTION</span> '''
|-
|| 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: <tt>/etc/ssh/sshd_config</tt>
 
# 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: <tt>/etc/ssh/sshd_config</tt>
 
# 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 [https://www.nongnu.org/oath-toolkit/ OATH Toolkit] or [https://www.duosecurity.com/ DuoSecurity] as second authentication factor.
 
File: <tt>/etc/pam.d/sshd</tt>
 
#%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) [http://blog.djm.net.au/2013/11/chacha20-and-poly1305-in-openssh.html disclose the packet length] - giving some information to the attacker.
* Only recent OpenSSH servers and client support CHACHA20.
 
* NIST curves (<tt>ecdh-sha2-nistp512,ecdh-sha2-nistp384,ecdh-sha2-nistp256</tt>) are listed for compatibility, but the use of <tt>curve25519</tt> is [https://safecurves.cr.yp.to/ generally preferred].
 
* SSH protocol 2 supports [https://en.wikipedia.org/wiki/Diffie–Hellman_key_exchange DH] and [https://en.wikipedia.org/wiki/Elliptic_curve_Diffie–Hellman ECDH] key-exchange as well as [https://en.wikipedia.org/wiki/Forward_secrecy forward secrecy].
* Regarding group sizes, please refer to [https://wiki.mozilla.org/Security/Guidelines/Key_Management 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
[[Kategorie:Ssh]]
[[Kategorie:Verschlüsselung]]

Aktuelle Version vom 4. Mai 2024, 13:36 Uhr

Seiten in der Kategorie „SSH/Kryptografie“

Diese Kategorie enthält nur die folgende Seite.