Jedes Unternehmen braucht SSH (Secure Shell)-Schlüssel, um privilegierte Benutzer zu authentifizieren und einen zuverlässigen Zugriff auf kritische Systeme zu gewährleisten – Anwendungsserver, Router, Firewalls, virtuelle Maschinen, Cloud-Instanzen und viele andere Geräte und Systeme. SSH-Schlüssel werden zur Ausführung von Aufgaben zur Systemverwaltung durch privilegierte Benutzer verwendet, aber auch für eine sichere Maschine-zu-Maschine-Kommunikation zur Automatisierung kritischer Geschäftsabläufe. Sobald die SSH-Schlüssel für die Client-Authentifizierung eingerichtet sind, ermöglichen sie laufende, automatische Verbindungen von einem System zum anderen, ohne dass ein Passwort eingegeben werden muss.
SSH ist ein Netzwerkprotokoll, das eine sichere, verschlüsselte Verbindung zwischen zwei Parteien herstellt. Es authentifiziert die beteiligten Parteien und ermöglicht ihnen mit einer Reihe verschiedener Techniken zur Datenmanipulation den Austausch von Befehlen und Ausgaben. SSH nutzt symmetrische Verschlüsselungsverfahren wie AES, Blowfish, 3DES, CAST128 und Arcfour, um die gesamte Verbindung zu verschlüsseln. Beim anfänglichen Schlüsselaustausch wird asymmetrische Verschlüsselung eingesetzt, um die symmetrische Verschlüsselung einzurichten und eine schlüsselbasierte Authentifizierung zu ermöglichen, und mit Hashverfahren werden hashbasierte Message Authentication Codes (HMAC) erzeugt, die die Integrität einer empfangenen Nachricht gewährleisten.
Wie Justin Elingwood von DigitalOcean erklärt, verschlüsselt SSH den Datenaustausch zwischen den beiden Parteien nach einem Client-Server-Modell. Der Server lauscht auf einem bestimmten Port auf Verbindungen, während der Client für die Einleitung des TCP (Transmission Control Protocol)-Handshakes mit dem Server verantwortlich ist. Nach dieser ersten Verbindungsaufnahme können Server und Client die Verschlüsselung der Sitzung auf der Grundlage der Protokolle aushandeln, die sie unterstützen. Zur Aushandlung des Sitzungsschlüssels verwenden beide Parteien eine Version des Diffie-Hellman-Algorithmus, um mit einem vereinbarten Seed-Wert und einem Verschlüsselungsgenerator (z.B. AES) sowie einem öffentlichen Schlüssel einen privaten Schlüssel zu erzeugen. Der private Schlüssel, der öffentliche Schlüssel der anderen Partei und der Seed bilden die Grundlage für den gemeinsamen geheimen Schlüssel – ein symmetrisches Geheimnis, mit dem dann die gesamte nachfolgende Kommunikation verschlüsselt wird.
Nachdem beide Parteien zur Erzeugung des gemeinsamen geheimen Schlüssels beigetragen haben, müssen sie sich authentisieren. Die gebräuchlichsten Authentisierungsmittel sind asymmetrische SSH-Schlüsselpaare. Der Server verwendet den öffentlichen Schlüssel, um eine Nachricht zu verschlüsseln und an den Client zu senden. Wenn der Client den richtigen privaten Schlüssel besitzt, kann er die Nachricht entschlüsseln und zur Verifizierung an den Server zurückschicken.
Derzeit existiert das SSH-Protokoll in zwei Versionen. Die erste Version verwendet private RSA-Schlüssel, um Zeichenfolgen zu entschlüsseln, die mit dem entsprechenden öffentlichen Schlüssel verschlüsselt wurden. Die Protokoll-Version SSH-1 bietet jedoch nur eingeschränkte Unterstützung für Message Authentication Codes, Kompressionsalgorithmen sowie Algorithmen, die für den Schlüsselaustausch verwendet werden können. Die Version 2 des Protokolls erfordert dagegen, dass der Client eine Nachricht signiert und die Signatur (nicht die Nachricht) mit dem verwendeten öffentlichen Schlüssel übermittelt. Der Server erzeugt dann die Nachricht neu und verifiziert den Server. SSH-2 ist auch kein monolithisches Protokoll. Laut Sararth Pillai von /Root besteht die neueste Version aus einer Reihe von Protokollen, die eine verbesserte Zertifizierung öffentlicher Schlüssel, bessere Verschlüsselungsstandards und sogar Unterstützung für Public-Key-Zertifikate bieten.
In beiden Versionen erfüllen SSH-Schlüssel eine entscheidende Funktion zum Schutz der Informationen der beteiligten Parteien. Es liegt daher im Interesse eines Unternehmens, seine SSH-Schlüssel zu verwalten. Dazu gehört es, die Schlüssel abzusichern, denen vertraut werden sollte, und diejenigen zu blocken, denen nicht vertraut werden sollte.
Lorem ipsum dolor sit amet, consectetur elit.
Thank you for subscription
Scroll to the bottom to accept
VENAFI CLOUD SERVICE
*** IMPORTANT ***
PLEASE READ CAREFULLY BEFORE CONTINUING WITH REGISTRATION AND/OR ACTIVATION OF THE VENAFI CLOUD SERVICE (“SERVICE”).
This is a legal agreement between the end user (“You”) and Venafi, Inc. ("Venafi" or “our”). BY ACCEPTING THIS AGREEMENT, EITHER BY CLICKING A BOX INDICATING YOUR ACCEPTANCE AND/OR ACTIVATING AND USING THE VENAFI CLOUD SERVICE FOR WHICH YOU HAVE REGISTERED, YOU AGREE TO THE TERMS OF THIS AGREEMENT. IF YOU ARE ENTERING INTO THIS AGREEMENT ON BEHALF OF A COMPANY OR OTHER LEGAL ENTITY, YOU REPRESENT THAT YOU HAVE THE AUTHORITY TO BIND SUCH ENTITY AND ITS AFFILIATES TO THESE TERMS AND CONDITIONS, IN WHICH CASE THE TERMS "YOU" OR "YOUR" SHALL REFER TO SUCH ENTITY AND ITS AFFILIATES. IF YOU DO NOT HAVE SUCH AUTHORITY, OR IF YOU DO NOT AGREE WITH THESE TERMS AND CONDITIONS, YOU MUST NOT ACCEPT THIS AGREEMENT AND MAY NOT USE THE SERVICE.
You shall not access the Service if You are Our competitor or if you are acting as a representative or agent of a competitor, except with Our prior written consent. In addition, You shall not access the Service for purposes of monitoring its availability, performance or functionality, or for any other benchmarking or competitive purposes, and you shall not perform security vulnerability assessments or penetration tests without the express written consent of Venafi.
This Agreement was last updated on April 12, 2017. It is effective between You and Venafi as of the date of Your accepting this Agreement.
The Venafi Cloud Service includes two separate services that are operated by Venafi as software as a service, each of which is separately licensed pursuant to the terms and conditions of this Agreement and each of which is considered a Service under this Agreement: the Venafi Cloud Risk Assessment Service or the Venafi Cloud for DevOps Service. Your right to use either Service is dependent on the Service for which You have registered with Venafi to use.
This License is effective until terminated as set forth herein or the License Term expires and is not otherwise renewed by the parties. Venafi may terminate this Agreement and/or the License at any time with or without written notice to You if You fail to comply with any term or condition of this Agreement or if Venafi ceases to make the Service available to end users. You may terminate this Agreement at any time on written notice to Venafi. Upon any termination or expiration of this Agreement or the License, You agree to cease all use of the Service if the License is not otherwise renewed or reinstated. Upon termination, Venafi may also enforce any rights provided by law. The provisions of this Agreement that protect the proprietary rights of Venafi will continue in force after termination.
This Agreement shall be governed by, and any arbitration hereunder shall apply, the laws of the State of Utah, excluding (a) its conflicts of laws principles; (b) the United Nations Convention on Contracts for the International Sale of Goods; (c) the 1974 Convention on the Limitation Period in the International Sale of Goods; and (d) the Protocol amending the 1974 Convention, done at Vienna April 11, 1980.
In the meantime, please explore more of our solutions
In the meantime, please explore more of our solutions
This site uses cookies to offer you a better experience. If you do not want us to use cookies, please update your browser settings accordingly. Find out more on how we use cookies.