• This forum has a zero tolerance policy regarding spam. If you register here to publish advertising, your user account will be deleted without further questions.

Sicheres SSH

Und wer seinen Server nicht von einem OpenSSH-6.5+-Client aus administriert, oder wessen Server auch mit anderen Servern per SSH kommunizieren muss, der sollte dem Blogpost lieber nicht nacheifern.
Insbesondere Nutzer von PuTTY oder WinSCP werden mit den dortigen Empfehlungen kräftig auf die Schnauze fallen. Einige MacOS, iOS und Android Nutzer ebenfalls.


Meine Empfehlung schaut dagegen so aus:

/etc/ssh/sshd_config
Code:
#       $OpenBSD: sshd_config,v 1.93 2014/01/10 05:59:19 djm Exp $
#       $FreeBSD: releng/10.1/crypto/openssh/sshd_config 264692 2014-04-20 12:46:18Z des $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options override the
# default value.

# Note that some of FreeBSD's defaults differ from OpenBSD's, and
# FreeBSD has a few additional options.

Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

# The default requires explicit activation of protocol 1
Protocol 2

# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
#HostKey /etc/ssh/ssh_host_ed25519_key

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 1024

# Ciphers and keying
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes256-cbc,aes256-ctr
Macs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512,hmac-sha2-256
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256,ecdh-sha2-nistp521,ecdh-sha2-nistp384,diffie-hellman-group-exchange-sha1
RekeyLimit 500M 1h

# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

LoginGraceTime 1m
PermitRootLogin yes
StrictModes yes
MaxAuthTries 3
MaxSessions 10

RSAAuthentication no
PubkeyAuthentication yes

# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
#AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2

#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes

# Change to yes to enable built-in password authentication.
PasswordAuthentication no
PermitEmptyPasswords no

# Change to no to disable PAM authentication
ChallengeResponseAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

# Set this to 'no' to disable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM no

AllowAgentForwarding no
AllowTcpForwarding no
GatewayPorts no
X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
PermitTTY yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
UseLogin no
UsePrivilegeSeparation sandbox
PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
UseDNS yes
#PidFile /var/run/sshd.pid
MaxStartups 10:30:100
PermitTunnel no
ChrootDirectory %h
#VersionAddendum FreeBSD-20140420

# no default banner path
#Banner none

# override default of no subsystems
#Subsystem      sftp    /usr/libexec/sftp-server

# Disable HPN tuning improvements.
#HPNDisabled no

# Buffer size for HPN to non-HPN connections.
#HPNBufferSize 2048

# TCP receive socket buffer polling for HPN.  Disable on non autotuning kernels.
#TcpRcvBufPoll yes

# Allow the use of the NONE cipher.
#NoneEnabled no

# Example of overriding settings on a per-user basis
#Match User anoncvs
#       X11Forwarding no
#       AllowTcpForwarding no
#       PermitTTY no
#       ForceCommand cvs server

Subsystem sftp internal-sftp -u 0027

AllowGroups wheel admin sftponly users

Match Group admin
        PasswordAuthentication yes

Match Group sftponly
        ForceCommand internal-sftp

Match User root
        ChrootDirectory none


/etc/ssh/ssh_config
Code:
#       $OpenBSD: ssh_config,v 1.28 2013/09/16 11:35:43 sthen Exp $
#       $FreeBSD: releng/10.1/crypto/openssh/ssh_config 264692 2014-04-20 12:46:18Z des $

# This is the ssh client system-wide configuration file.  See
# ssh_config(5) for more information.  This file provides defaults for
# users, and the values can be changed in per-user configuration files
# or on the command line.

# Configuration data is parsed as follows:
#  1. command line options
#  2. user-specific file
#  3. system-wide file
# Any configuration value is only changed the first time it is set.
# Thus, host-specific definitions should be at the beginning of the
# configuration file, and defaults at the end.

# Site-wide defaults for some commonly used options.  For a comprehensive
# list of available options, their meanings and defaults, please see the
# ssh_config(5) man page.

# Host *
#   ForwardAgent no
#   ForwardX11 no
#   RhostsRSAAuthentication no
#   RSAAuthentication yes
#   PasswordAuthentication yes
#   HostbasedAuthentication no
#   GSSAPIAuthentication no
#   GSSAPIDelegateCredentials no
#   BatchMode no
#   CheckHostIP no
#   AddressFamily any
#   ConnectTimeout 0
#   StrictHostKeyChecking ask
#   IdentityFile ~/.ssh/identity
#   IdentityFile ~/.ssh/id_rsa
#   IdentityFile ~/.ssh/id_dsa
#   Port 22
#   Protocol 2,1
#   Cipher 3des
#   Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc
#   MACs hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160
#   EscapeChar ~
#   Tunnel no
#   TunnelDevice any:any
#   PermitLocalCommand no
#   VisualHostKey no
#   ProxyCommand ssh -q -W %h:%p gateway.example.com
#   RekeyLimit 1G 1h
#   VerifyHostKeyDNS yes
#   VersionAddendum FreeBSD-20140420

Host *
        Protocol 2
        RekeyLimit 500M 1h
        Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes256-ctr,aes256-cbc
        Macs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512,hmac-sha2-256
        KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256,ecdh-sha2-nistp521,ecdh-sha2-nistp384,diffie-hellman-group-exchange-sha1
        HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp521,ecdsa-sha2-nistp384,ecdsa-sha2-nistp256
        VisualHostKey yes


SSH-Keygen
Code:
ssh-keygen -t ed25519 -O clear -O permit-pty
cat .ssh/id_ed25519.pub >> .ssh/authorized_keys
ssh-keygen -t ecdsa -b 384 -O clear -O permit-pty
cat .ssh/id_ecdsa.pub >> .ssh/authorized_keys
ssh-keygen -t rsa -b 4096 -O clear -O permit-pty
cat .ssh/id_rsa.pub >> .ssh/authorized_keys
 
Meine Empfehlung schaut dagegen so aus:

/etc/ssh/sshd_config
Code:
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256,ecdh-sha2-nistp521,ecdh-sha2-nistp384,diffie-hellman-group-exchange-sha1

Die Nist-Kurven sind doch gerade die, die man nicht mehr haben will, weil sie wahrscheinlich mit NSA-Backdoor bestückt sind?
 
Falsch, es gibt bislang keinerlei Anzeichen dafür, dass die NIST-Kurven manipuliert sind.
Bitte nicht die Kurven mit dem Dual EC DRBG verwechseln.
 
Nochmal: Der Dual EC DRBG hat nichts mit den NIST-Kurven zu tun.

Die NIST-Kurven sind nach wie vor kryptographisch vertrauenswürdig und unbedenklich.
 
Es ist eine bemerkenswerte Aussage. Kryptographie-Guru Bruce Schneier stellt damit einen wichtigen Kryptographiestandard infrage: die Verschlüsselung mit den elliptischen Kurven, die 1999 von der US-Behörde Nist (National Institute of Standards and Technology) standardisiert wurden. Anders als der Zufallsgenerator Dual_EC_DRBG, um den es in den vergangenen Tagen ebenfalls zahlreiche Spekulationen gab, werden die Nist-Kurven tatsächlich in vielen realen Anwendungen eingesetzt.

Irgendwie fände ich es zielführender und weniger redundant, wenn du kurz in die verlinkten Artikel reinlesen würdest. Da steht, dass es nicht nur um den Zufallsgenerator, sondern auch um die Kurven geht.
 
Auch Schneier hat bisher keinen Anhaltspunkt dafür geliefert, dass die NIST-P-Kurven nicht vertrauenswürdig oder gar unsicher sind. Er äussert lediglich seine persönliche Meinung, nach der er diesen Kurven nicht vertrauen möchte, da er sie noch nicht ausreichend selbst untersucht hat. Ansonsten gibt es von ihm lediglich "i don't know" oder Sarkasmus zu dem Thema -- sehr hilfreich...

In welchem Dokument steht denn, dass Dual_EC_DRBG auf den NIST-P-Kurven basiert?


BTW: Nur weil irgendwo von NIST und/oder elliptischen Kurven die Rede ist, ist nicht automatisch von NIST-P die Rede.

BTW: Wer meint NIST-Standards wegen Dual_EC_DRBG generell misstrauen zu müssen, der muss konsequenterweise dann auch allen ANSI und ISO Standards misstrauen, denn diese haben Dual_EC_DRBG ebenfalls standardisiert.


In der Kryptographie zählen Fakten und keine Vermutungen oder Verschwörungstheorien, auch nicht die von Schneier.
 
In der Kryptographie zählen Fakten und keine Vermutungen oder Verschwörungstheorien, auch nicht die von Schneier.

Erinnert mich irgendwie an Harald Range, der bisher auch keine Fakten für die Behauptung finden konnte, dass uns die NASA überwacht :p

Fakt ist, dass die NSA versucht NIST-Standards aufzuweichen. Fakt ist auch, dass bisher unbekannte Aspekte von SSH gebrochen sind. Wir haben die subjektive Einschätzung von Krypto-Forschern, dass die NIST-Kurven irgendwie stinken und wir daher dringend neue Kurven a la Curve25519 standardisieren sollten. Ob man nun auf den Beweis wartet, dass die NIST-Kurven ein Backdoor haben oder sicherheitshalber schon jetzt auf vertrauenswürdigere Methoden setzt, muss wohl jeder selbst entscheiden...
 
Last edited by a moderator:
Erinnert mich irgendwie an Harald Range, der bisher auch keine Fakten für die Behauptung finden konnte, dass uns die NASA überwacht :p

Ich glaube, die NASA überläßt das Überwachen lieber der NSA ;)
Die NIST-Kurven würde ich nicht als kyprographisch vertrauenswürdig und unbedenktlich ansehen, sondern nur als NICHT nachgewiesen unsicher. Es gibt keinen Nachweis, dass sie unsicher sind, aber nach den Enthüllungen der vergangenen Monate gehe ich davon aus, dass da noch mehr aufgedeckt wird.
Letztendlich muß doch jeder für sich selbst wissen, wie viele Abstriiche er bereti ist zu machen, um die Sicherheit zu erhöhen.
Und wenn wir schon beim Thema NSA sind: Vielleicht zieht man sich die Aufmerksamkeit der NSA gerade wegen besonders starker Verschlüsselung auf sind - so nach dem Motto: Wer so stark verschlüsselt, hat bestimmt war zu verbergen.
 
dass die NIST-Kurven irgendwie stinken und wir daher dringend neue Kurven a la Curve25519 standardisieren sollten.

Wer wird Curve25519 standardisieren? Ach ja, NIST...
Damit ist nach Eurer Definition ein standardisiertes Curve25519 nicht vertrauenswürdig und somit ein No-Go.
Irgendwie komisch oder?
 
Es gibt keinen Nachweis, dass sie unsicher sind, aber nach den Enthüllungen der vergangenen Monate gehe ich davon aus, dass da noch mehr aufgedeckt wird.
Man sollte nicht davon ausgehen dass die NSA ausschliesslich auf Spionage und Kontrolle aus ist. Die unerklärten Werte können genau so gut eine Absicherung gegen der NSA bekannten aber nicht öffentliche Angriffe dienen. Ein gutes Beispiel hierfür ist DES welcher in den 70er Jahren gegen einen Angriff geschützt wurde welcher erst 1990 bekannt wurde.

Monate gehe ich davon aus, dass da noch mehr aufgedeckt wird.
5 Jahre nach Entwurf des Standards RSA wurde "RSA Security" gegründet welche 2004 durch die 10Mio Bestechung durch NSA zur Verwendung von DUAL_EC_DRBG gebracht wurden. Man kann also davon ausgehen dass alle Erfindungen der Gründer mit bislang unbekannten Backdoors ausgestattet sind (dein Argument, nichts meins) und somit RSA nicht vertrauenswürdig ist.
Der Schelm Thorsten wusste das natürlich schon lange und hat das SSF deswegen nie auf HTTPS umgestellt!
 
Das die Nist-Kurven unsicher sind, ist noch nicht bewiesen. Da sind wir schon mal einer Meinung. Sich jetzt darauf zu verlassen, dass sie sicher sind, halte ich aber für einen fatalen Fehler. Wenn ich vermute, dass an meinem Auto die Bremsen kaputt sind, fahre ich nicht wie ein Bekloppter mit 160km/h den Berg runter um das zu testen. Der Weg zur Werkstatt um das kontrollieren zu lassen, wäre vernünftiger.

Ach, ich freue mich schon auf den Tag, an dem jemand uns zeigt, dass die Kurven unsicher sind. Die Leute, die dann schon das neue Verfahren einsetzen, können sich schön entspannen und die anderen müssen halt nachbessern.
 
Das die Nist-Kurven unsicher sind, ist noch nicht bewiesen
Die ganze Sicherheit von SSL/TLS stammt genau daraus dass die zugrunde liegende Sicherheit eben hoffentlich NICHT beweisbar und somit implementierbar ist.
Nach allem was wir wissen könnte die NSA schon seit Jahrzenten eine Implementierung zur Berechnung von RSA-Faktoren haben, genau so gut kann es aber mathematisch unmöglich sein genau das zu tun.

Ach, ich freue mich schon auf den Tag, an dem jemand uns zeigt, dass die Kurven unsicher sind.
Zeigen als in beweisen wird das wohl nie jemand können außer es würde ein entsprechendes Dokument veröffentlicht. Es kann allenfalls Vermutungen oder Schwachstellen-Nachweise mit neuen Angriffsmethoden geben. Wer kann aber schon wirklich sagen ob die Schwachstelle dann geplant oder ungewollt ist?
EC-Kryptografie ist sehr neu, wenig erforscht und äußerst komplex. Leute wie du oder ich können da schlicht nicht mitreden sondern nur auf die -hoffentlich vertrauenswürdige- Ergebnisse anderer Quellen warten.
 
Back
Top