CRD-Portal · CRD-Portal - Benutzerhandbuch für Servicemitarbeiter (CRD-User) Handbuch_CRDUser.docm Seite 1 1 Einleitung und Abgrenzung Das vorliegende Dokument beschreibt die …

CRD-Portal

Benutzerhandbuch für Servicemitarbeiter (CRD-User)

Version: 3.4.9

Stand: 06.11.2018

Status: Bereitgestellt

Copyright © 2018 by T-Com,

Alle Rechte, auch die des auszugsweisen Nachdrucks, der fotomechanischen Wiedergabe (einschließlich

Mikrokopie) sowie der Auswertung durch Datenbanken oder ähnliche Einrichtungen, vorbehalten.

Handbuch_CRDUser.docm Seite ii

Impressum

Herausgeber

Production, Computing Services & Solutions (CSS) GCU MPHS, Security Consulting & Engineering Holzhauser Straße 4-8 13509 Berlin

Version Stand Status

3.4.9 06.11.2018 Bereitgestellt

Ansprechpartner Telefon / Fax E-Mail

Kurzinfo

Dieses Dokument beschreibt, wie externe Servicemitarbeiter über das CRD-Portal auf Netzelemente zugreifen können.

CRD-Portal - Benutzerhandbuch für Servicemitarbeiter (CRD-User)

Handbuch_CRDUser.docm Seite iii

Inhaltsverzeichnis

1 Einleitung und Abgrenzung 1

2 Überblick 2

2.1 Aufgabe des CRD-Portals ................................................................................. 2

2.2 Nutzungsprinzip ................................................................................................ 2

2.3 Verbindungsaufbau ........................................................................................... 3

2.4 Nutzungsvoraussetzungen ................................................................................ 4

2.5 Lizenz ............................................................................................................... 4

3 Nutzung der CRD-Console 5

3.1 Bereitstellung der Zugangsinformationen .......................................................... 5

3.2 Installation / Einstellungen vor dem ersten Start ................................................ 6

3.3 Konvertieren vorhandener Sessions ................................................................. 7

3.3.1 Ab Console-Version 3.0 ........................................................................ 7

3.3.2 Ab Console-Version 3.4.6 ..................................................................... 8

3.4 Überblick ........................................................................................................... 8

3.5 Verwaltung von Sessions ................................................................................ 10

3.6 Importieren von Sessions ................................................................................ 11

3.6.1 Hauptmenü ......................................................................................... 11

3.6.2 Ticket importieren ................................................................................ 12

3.6.3 Drag & Drop ........................................................................................ 13

3.7 Protokolle pro Netzelement ............................................................................. 13

3.8 Schlüssel-Handling ......................................................................................... 13

3.8.1 Erzeugen eines RSA-Schlüssels ......................................................... 13

3.8.2 Anzeigen / Löschen eines RSA-Schlüssels ......................................... 16

3.8.3 Ändern der Passphrase eines RSA-Schlüssels ................................... 16

3.9 Einstellungen .................................................................................................. 16

3.9.1 Erste Ausführung der Anwendung ....................................................... 17

3.9.2 Sprache............................................................................................... 20

3.9.3 Protokollierungsstufe ........................................................................... 20

3.9.4 Proxy ................................................................................................... 21

3.9.5 Standardpfad ändern........................................................................... 21

3.9.6 Terminal .............................................................................................. 22

3.10 Aufbau einer Verbindung ................................................................................ 25

3.10.1 Portal-Konfiguration ............................................................................ 25

3.10.2 Verbindung zu einem Netzelement ...................................................... 25

3.11 Aufruf der CRD-Console mit Kommandozeilen-Parametern ............................ 43


Handbuch_CRDUser.docm Seite iv

4 Fehlerbehandlung 44

5 Technische Ansprechpartner 53

6 Glossar / Abkürzungsverzeichnis 54


Handbuch_CRDUser.docm Seite v

Abbildungsverzeichnis

Abbildung 2-1: Funktionsweise des Verbindungsaufbaus .................................................. 3

Abbildung 3-1: Ändern in Deutsch ..................................................................................... 6

Abbildung 3-2: Konvertierungsabfrage .............................................................................. 7

Abbildung 3-3: "sessions"-Ordner vor der Konvertierung ................................................ 7

Abbildung 3-4: "sessions"-Ordner nach der Konvertierung ............................................. 8

Abbildung 3-5: Konvertierungsabfrage .............................................................................. 8

Abbildung 3-6: CRD-Console ............................................................................................ 9

Abbildung 3-7: Menü „CRD-Console“ .............................................................................. 11

Abbildung 3-8: Ticket importieren .................................................................................... 12

Abbildung 3-9: Drag & Drop von Session-Dateien ........................................................... 13

Abbildung 3-10: Menü Schlüsselerzeugung ..................................................................... 14

Abbildung 3-11: Schlüsselerzeugung .............................................................................. 14

Abbildung 3-12: Public Key ............................................................................................. 15

Abbildung 3-13: Keys ansehen und löschen .................................................................... 16

Abbildung 3-14: Einstellungs-Menü ................................................................................. 17

Abbildung 3-15: Assistent Auswahl Sprache ................................................................... 17

Abbildung 3-16 Assistent Abfrage vorhanden RSA-Schlüsselpaar .................................. 18

Abbildung 3-17 Assistent Abfrage Speicherort private RSA-Schlüssel ............................ 19

Abbildung 3-18 Assistent Generierung RSA-Schlüsselpaar ............................................. 20

Abbildung 3-19: Proxy-Einstellungsdialog........................................................................ 21

Abbildung 3-20: Standardpfad-Einstellungsdialog ........................................................... 21

Abbildung 3-21: Dialog Farbe ändern .............................................................................. 22

Abbildung 3-22: Dialog Farbauswahl ............................................................................... 23

Abbildung 3-23: Dialog Anzahl Zeilen für Scrollback ....................................................... 24

Abbildung 3-24: Registerkarte "CRD-Portal" .................................................................... 25

Abbildung 3-25: Registerkarte "Netzelement" .................................................................. 26

Abbildung 3-26: Remote Host Authentication .................................................................. 26

Abbildung 3-27: Passphrase-Abfrage bei SSH/Telnet ..................................................... 27

Abbildung 3-28: SSH-Terminal-Emulator ......................................................................... 28

Abbildung 3-29: Markieren und Kopieren/Einfügen .......................................................... 29

Abbildung 3-30: Kontext-Menü VNC-Viewer .................................................................... 30

Abbildung 3-31: Reiter „VNC-Einstellungen“ für RDP ...................................................... 31

Abbildung 3-32: Passphrase-Abfrage bei RDP/NX/X2GO ............................................... 31

Abbildung 3-33: RDP-Sitzung .......................................................................................... 33

Abbildung 3-34: Reiter „VNC-Einstellungen“ für NX ......................................................... 34

Abbildung 3-35: NX-Anmeldung ...................................................................................... 35

Abbildung 3-36: NX-Sitzung mit Gnome-Desktop ............................................................ 36


Handbuch_CRDUser.docm Seite vi

Abbildung 3-37: Bestehende NX-Verbindungen .............................................................. 37

Abbildung 3-38: X2GO-Verbindung mit Login-Dialog ....................................................... 38

Abbildung 3-39: SCP Protokollauswahl ........................................................................... 39

Abbildung 3-40: SCP von lokal nach remote ................................................................... 39

Abbildung 3-41: SCP-Verbindungsübersicht .................................................................... 41

Abbildung 3-42: SCP von remote nach lokal ................................................................... 42


Handbuch_CRDUser.docm Seite 1

1 Einleitung und Abgrenzung

Das vorliegende Dokument beschreibt die durchzuführenden Tätigkeiten externer

Servicemitarbeiter (CRD-User), wenn diese sich zur Durchführung von Diagnose- und

Wartungsarbeiten über das CRD-Portal mit internen Netzelementen der Deutschen

Telekom AG verbinden müssen.

Kapitelübersicht:

Kapitel 2 Überblick zur Funktionsweise des CRD-Portals Kapitel 3 Beschreibung der Nutzung der CRD-Console, insbesondere des Aufbaus von Verbindungen Kapitel 4 Übersicht zu Fehlerbehandlungen Kapitel 5 Angaben zu technischen Ansprechpartnern



2 Überblick

2.1 Aufgabe des CRD-Portals

Aufgrund verschiedener Anforderungen ist die Deutsche Telekom AG als

Netzdienstleister für den Betrieb ihrer Netze und IT-Systeme verantwortlich. Sofern die

administrativen Tätigkeiten nicht von eigenen Mitarbeitern ausgeführt werden können,

sind die Aktivitäten von externen Administratoren und Servicedienstleistern zum

Netzwerkmanagement, zur Diagnose und zur Wartung zu protokollieren und zu

überwachen.

Um den Anforderungen zum Risikomanagement effizient genügen zu können, muss der

Betreiber solcher IT-Systeme in der Regel geeignete Monitoring-Systeme vor die zu

schützende Infrastruktur installieren, um Diagnose- und Wartungstätigkeiten von

Administratoren, Netzwerkmanagern und Fremdunternehmen überwachen, auswerten

und aufzeichnen zu können.

Das CRD-Portal ermöglicht eine Protokollierung und Überwachung der für Wartungs- und

Diagnosezwecke erforderlichen Verbindungen zu Netzelementen der Deutschen Telekom

AG.

2.2 Nutzungsprinzip

Damit ein Servicemitarbeiter (CRD-User) eine Verbindung zu einem Netzelement über

das CRD-Portal aufbauen kann, muss vom Betreiber zuvor ein CRD-Session-Ticket

ausgestellt worden sein. In diesem Ticket wird festgelegt, wer wann mit welchem Protokoll

auf Netzelemente zugreifen darf. Nach Übermittlung der für den Verbindungsaufbau

erforderlichen Informationen an den Servicemitarbeiter kann dieser Verbindungen zu

einem oder mehreren Netzelementen aufbauen.

Beim Aufbau der ersten Verbindung wird das CRD-Session-Ticket geprüft und die CRD-

Session aktiviert. Eine CRD-Session ist ein Wartungszeitfenster, in welchem der CRD-

User zu den im CRD-Session-Ticket definierten Netzelementen über die dort ebenfalls

definierten Protokolle beliebig oft Verbindungen herstellen und beenden kann. Das

Wartungszeitfenster beginnt und endet zu den im Ticket angegebenen Zeitpunkten (der

Endezeitpunkt wird aufgrund der bei der Erstellung des Tickets eingegebenen Dauer

automatisch berechnet).

Innerhalb einer CRD-Session kann der CRD-User gemäß seiner im CRD-Session-Ticket

festgelegten Berechtigungen mehrere Verbindungen zu einem oder mehreren

Netzelementen etablieren, betreiben und wieder beenden. Die Anzahl der insgesamt

gleichzeitig möglichen Verbindungen zu einem oder mehreren Netzelementen ist dabei



durch einen im CRD-Session-Ticket definierten Parameter begrenzt. Die CRD-Session

wird nach Erreichen des Endes des Zeitfensters automatisch oder während der

Gültigkeitsdauer durch expliziten Eingriff eines Mitarbeiters des Portalbetreibers beendet,

wobei auch alle innerhalb der CRD-Session offenen Verbindungen beendet werden.

2.3 Verbindungsaufbau

In Abbildung 2-1 ist die grundsätzliche Funktionsweise des Verbindungsaufbaus vom

Terminal eines externen Servicemitarbeiters (CRD-User) über das CRD-Portal zu einem

Netzelement dargestellt.

Abbildung 2-1: Funktionsweise des Verbindungsaufbaus

Vom Rechner (extTerminal) des CRD-Users wird zuerst eine SSH-Verbindung zum

CRD-Portal aufgebaut. Gegenstelle hierfür ist ein modifizierter OpenSSH-Server. Durch

die Angabe von CRD-spezifischen Parametern (Protokoll, Ticket-ID, Netzelement) als

SSH-Kommandos kann der CRD-User die gewünschte Verbindung zum Netzelement

beantragen. Unterstützte Protokolle sind zurzeit SSH (zum Steuern eines UNIX-Systems

per Kommandozeile), SCP (zum Kopieren von Dateien von oder zu einem UNIX-System),

Telnet (u.a. zum Steuern von Routern oder Switches per Kommandozeile), RDP (zum

Steuern von Windows-Systemen per grafischer Oberfläche) und NX oder X2Go (zum

Steuern von UNIX-Systemen per grafischer Oberfläche).

Die Auswertung der übermittelten Parameter im OpenSSH-Server sowie die Prüfung im

Session-Management auf dem CRD-Portal entscheiden über das Starten weiterer Server-

Prozesse, z.B. zum Ermöglichen einer grafischen Verbindung oder aber über das



Ablehnen der Verbindung. Über den etablierten SSH-Tunnel können sich schließlich die

Client-Programme (z.B. VNC-Viewer) mit dem CRD-Portal verbinden. Von dort aus

wiederum wird die Verbindung zum Netzelement aufgebaut.

Für sämtliche Verbindungen kann das Programm CRD-Console benutzt werden, welches

eine komfortable Eingabe der Verbindungsparameter erlaubt und die jeweilige Verbindung

(grafisch oder über Kommandozeile) in entsprechenden Fenstern darstellt. Als Java-

Anwendung kann die CRD-Console plattformunabhängig betrieben werden.

Hinweis 1: Der Aufbau einer Verbindung ist bis maximal 10 Minuten vor Ende der

CRD-Session möglich.

2.4 Nutzungsvoraussetzungen

Es gelten folgende technische Voraussetzungen für den Zugriff externer

Servicemitarbeiter auf Netzelemente über das CRD-Portal mittels CRD-Console:

• Java Runtime Environment Version 1.7.

Die Anwendung CRD-Console ist Java-basiert und kann somit auf unterschiedlichen

Betriebssystemen ausgeführt werden. Verifiziert wurde die korrekte Funktion der CRD-

Console für das Betriebssystem Microsoft Windows XP, Windows 7 und CentOS.

2.5 Lizenz

In die Anwendung CRD-Console wurden folgende OpenSource-Komponenten integriert:

• Jsch (JCraft, T-Systems): OpenSSH-Java-Implementierung

• Log4j (Apache): Logging-Bibliothek von Apache

• SecureVncViewer (Tightvnc, T-Systems): VNC-Client mit Verschlüsselung

• GSI-SSHTerm (SSHTools): SSH-Terminal-Emulator

• Xerces (Apache): Java-XML-Handling

Die CRD-Console ist mit der GNU General Public License (v2) freigegeben.



3 Nutzung der CRD-Console

3.1 Bereitstellung der Zugangsinformationen

Damit ein externer Servicemitarbeiter einer Supportfirma eine Verbindung zu einem

Netzelement etablieren kann, muss vom Betreiber ein CRD-Session-Ticket ausgestellt

und dem CRD-User die für den Zugang relevanten Informationen aus dem CRD-Session-

Ticket übermittelt werden.

Folgende Informationen über die CRD-Session muss der CRD-User erhalten:

• Beginn und Ende der CRD-Session.

• Maximale Anzahl gleichzeitig möglicher Verbindungen.

• Name eines einzelnen oder mehrerer CRD-User, die berechtigt sind, eine CRD-

Session zu aktivieren. Dieser Name ist auf dem CRD-Portal mit dem öffentlichen

Schlüssel des jeweiligen CRD-Users verknüpft. Innerhalb einer CRD-Session kann

ein CRD-User gleichzeitig mehrere Verbindungen zu einem oder verschiedenen

Netzelementen aufbauen.

• Ticket-ID: 16-stellige Zeichenfolge (Hexadezimalzahl).

• Protokoll: RDP, Telnet, SSH, SCP, X2Go oder NX.

• Target: IP-Adresse eines Netzelementes oder mehrerer Netzelemente.

• Login-Credentials: Anmeldeinformationen für das Netzelement, sofern im CRD-

Session-Ticket kein automatischer Login konfiguriert wurde.

• CRD-Portal-Adresse: öffentliche IP-Adresse bzw. DNS-Name des CRD-Portals.

• Firmenname: mit diesem Namen erfolgt der Aufbau der SSH-Verbindung zum

CRD-Portal.

• Externer SSH-Port des CRD-Portals: Es wird immer der Standard-SSH-Port 3022

verwendet.

Hinweis 2: Kann der CRD-User aufgrund interner Vorgaben aus seinem Firmennetz

nicht auf den Port 3022 zugreifen, so ist nach Abstimmung mit dem

Betreiber des CRD-Portals ein anderer Port zu verwenden.

Auf Basis dieser Daten kann der CRD-User nun eine SSH-Verbindung von seinem

Rechner zum CRD-Portal etablieren. Die Authentifizierung des CRD-Users erfolgt immer

auf der Basis seines persönlichen RSA-Schlüssels, eine Authentifizierung mittels User-

ID/Password gegenüber dem CRD-Portal ist nicht möglich.



Hinweis 3: Damit die SSH-Verbindung aufgebaut werden kann, muss der CRD-User

zuvor den öffentlichen Schlüssel seines RSA-Schlüssels dem Betreiber

des CRD-Portals übergeben haben, damit dieser auf dem CRD-Portal

administriert werden kann.

3.2 Installation / Einstellungen vor dem ersten Start

Für die Anwendung CRD-Console werden folgende Archive benötigt:

• CRDConsole-<Version>.jar

Das Programm CRDConsole-<Version>.jar benötigt ein Arbeitsverzeichnis zum Speichern

von Sessionkonfigurationen und Einstellungen. Dieses wird im Home-Verzeichnis des

angemeldeten Benutzers unter dem Namen „.CRDconsole“ automatisch angelegt. Für

den Windows -User (deutsches Windows) „erwin“ also beispielsweise:

C:\Dokumente und Einstellungen\erwin\.CRDconsole

Für den Windows 7-User (deutsches Windows) „erwin“ beispielsweise:

C:\Benutzer\erwin\.CRDconsole

Für den Linux-User „erwin“ beispielsweise:

~erwin/.CRDconsole

In diesem Verzeichnis werden Session-Dateien und Einstellungen gespeichert sowie die

Log-Datei und die known_hosts-Datei angelegt.

Die CRD-Console wird mit der Datei CRDConsole-<Version>.jar ausgeführt.

CRDConsole-<Version>.jar als Standalone-Anwendung kann sich in jedem

beliebigen Verzeichnis befinden und beliebig kopiert werden und wird per Doppelklick

gestartet. Alternativ kann zum Start auch der Befehl „java –jar CRDConsole-

<Version>.jar“ verwendet werden.

Standardmäßig wird die CRD-Console in Englisch gestartet. Über das Menü „Settings”

“Language“ kann die Sprache geändert werden.

Abbildung 3-1: Ändern in Deutsch

Das vorliegende Handbuch kann über das Hilfemenü geöffnet werden. Dazu ist das

Handbuch als PDF mit dem Namen „Console.pdf“ in das Arbeitsverzeichnis

„.CRDconsole“ zu kopieren.



3.3 Konvertieren vorhandener Sessions

3.3.1 Ab Console-Version 3.0

Dieses Kapitel beschreibt die Konvertierung vorhandener Session-Dateien von CRD-

Console-Versionen älter als 3.0. Falls die CRD-Console noch nie benutzt, eine

Konvertierung bereits durchgeführt oder bisher keine Session-Daten abgespeichert

wurden, kann dieses Kapitel übersprungen werden.

Beim ersten Starten der CRD-Console werden Session-Dateien älterer CRD-Console-

Versionen erkannt und eine Konvertierung in das neue Format angeboten. Folgende

Abfrage erscheint:

Abbildung 3-2: Konvertierungsabfrage

Beim Bestätigen mit „Ja“ werden die Session-Dateien konvertiert und sind danach in der

Session-Auswahlliste verfügbar. Die Konvertierung hat keinen Einfluss auf die Inhalte der

gespeicherten Session-Daten und sollte unbedingt durchgeführt werden, da sonst nicht

mit den vorhandenen Session-Daten gearbeitet werden kann. Aus Sicherheitsgründen

werden die alten Session-Dateien nicht gelöscht sondern in den Ordner „old“

verschoben. Folgende zwei Abbildungen verdeutlichen die Konvertierung der Session-

Dateien im „sessions“-Ordner:

Abbildung 3-3: "sessions"-Ordner vor der Konvertierung



Abbildung 3-4: "sessions"-Ordner nach der Konvertierung

Beim Ablehnen der Abfrage mit „Nein“ werden die alten Session-Dateien nicht konvertiert.

Die CRD-Console startet, aber es werden keine gespeicherten Sessions zur Auswahl

stehen. Die Abfrage wird bei jedem Start der CRD-Console erneut erscheinen, bis die

vorhandenen Session-Dateien konvertiert oder manuell aus dem „sessions“-Ordner

entfernt wurden.

3.3.2 Ab Console-Version 3.4.6

Dieses Kapitel beschreibt die Konvertierung vorhandener Session-Dateien von CRD-

Console-Versionen älter als 3.4.6. Falls die CRD-Console noch nie benutzt, eine

Konvertierung bereits durchgeführt oder bisher keine Session-Daten abgespeichert

wurden, kann dieses Kapitel übersprungen werden.

Beim Öffnen von Session-Dateien, die mit einer älteren CRD-Console (vor 3.4.6, jedoch

nicht vor 3.0) erstellt wurden, erscheint folgende Abfrage:

Abbildung 3-5: Konvertierungsabfrage

Beim Bestätigen mit „Ja“ wird die jeweilige Session-Datei konvertiert und geladen. Die

Konvertierung hat keinen Einfluss auf die Inhalte der gespeicherten Session-Daten und

sollte unbedingt durchgeführt werden, da sonst nicht mit den vorhandenen Session-Daten

gearbeitet werden kann. Aus Sicherheitsgründen wird die alte Session-Datei nicht

gelöscht sondern in den Ordner „sessions_backup“ verschoben.

Beim Ablehnen der Abfrage mit „Nein“ wird die alte Session-Datei nicht konvertiert und

nicht geladen.

3.4 Überblick

Die folgende Abbildung erklärt die Start-Oberfläche der CRD-Console.



Abbildung 3-6: CRD-Console

- Importieren von Sessiondateien - Beenden

Verbindungdaten zum CRD-Portal

Verbindungdaten zum Netzelement

Leeren der aktuellen Registerkarte

- Sprache - Loglevel - Alle Eingabefelder leeren - Standardpfad - Proxy-Einstellungen -Terminal-Einstellungen

Speichern der eingegebenen Verbindungsdaten unter dem eingegebenen Namen

Übernehmen der Verbindungsdaten aus der ausgewählten Session in die aktuellen Eingabefelder

Löschen der ausgewählten Session aus der Liste der gespeicherten Sessions

- Release- und Lizenz-Informationen - Handbuch anzeigen

Name der aktuellen Session

Liste der gespeicherten Sessions

Dateibrowser zur Schlüsselauswahl

- Schlüsselverwaltung - SCP-Download/Upload-Liste - Aktive Verbindungen

Verbindung starten

Anzeige Erreichbarkeit des Portals

Import von Ticket-Daten aus der Zwischenablage



3.5 Verwaltung von Sessions

Oft verwendete Verbindungs-Einstellungen können gespeichert werden. Dazu im Textfeld

„Name der Session“ einen Namen vergeben und auf „Speichern“ klicken. Der Name

erscheint dann in der Liste der gespeicherten Sessions. Per Doppelklick oder über den

Button „Übernehmen“ werden die gespeicherten Daten in die entsprechenden Textfelder

und Auswahlboxen in den Reitern eingetragen.

Das Speichern von Verbindungseinstellungen kann z.B. genutzt werden, um Templates

zu erstellen, in denen z.B. die Verbindungsdaten zum CRD-Portal gespeichert sind. Bei

Verwendung eines solchen Templates muss dann zum Beispiel nur noch der Reiter

„Netzelement“ bearbeitet werden. Es kann auch genutzt werden, um häufig verwendete

Verbindungseinstellungen komplett abzuspeichern, so dass nach dem Übernehmen der

Session-Daten die Verbindung sofort geöffnet werden kann.

Über den Button „Löschen“ kann die selektierte Verbindung in der Liste der gespeicherten

Sessions wieder entfernt werden. Gespeicherte Verbindungs-Einstellungen können

geändert werden, indem die Session zuerst geladen wird („Übernehmen“ oder

Doppelklick) und die Änderungen anschließend wieder unter demselben Session-Namen

abgespeichert werden.

Session-Daten werden im eingestellten Standardpfad (siehe Kapitel 3.9.5) gespeichert.

Beim ersten Start der CRD-Console ist als Standardpfad der Ordner „sessions“ im

Arbeitsverzeichnis der CRD-Console eingestellt. Beim Speichern der Session-Daten wird

der Name der Session als Dateiname (mit der Endung „.xml“) verwendet.

Bitte beachten Sie dazu auch das Kapitel 3.3 Konvertieren vorhandener Sessions.



3.6 Importieren von Sessions

3.6.1 Hauptmenü

Die CRD-Console ab Version 3.1 bietet die Möglichkeit, Sessions zu importieren, die als

Datei vorliegen oder per Email versandt wurden. Diese Optionen befinden sich im

Hauptmenü „CRD-Console“.

Abbildung 3-7: Menü „CRD-Console“

Der Menüpunkt „Verbindungsdaten aus Datei laden“ öffnet einen Dateidialog, über den

eine xml-Datei ausgewählt werden kann. Wenn die Datei eine gültige CRD-Console-

Session-Datei ist, werden die Textfelder und Auswahlboxen mit dem Inhalt der Datei

befüllt. Session-Name ist zunächst der Dateipfad. Damit ist es möglich, Ticket-Daten

direkt aus der bereitgestellten XML-Datei in die CRD-Console einzulesen.

Auf diesem Wege können Session-Dateien aus dem CRD-Console-Arbeitsverzeichnis

ausgetauscht werden.

Nach dem Laden der Session-Datei sind die eingelesenen Daten noch nicht im eigenen

Arbeitsverzeichnis abgespeichert. Durch Vergabe eines gültigen Session-Namens können

die importierten Daten gespeichert werden, sodass die Session unter dem neuen Namen

in der Liste der gespeicherten Session auftaucht.

Bitte beachten Sie dazu auch das Kapitel 3.3 Konvertieren vorhandener Sessions.



3.6.2 Ticket importieren

Der Button „Ticket importieren“ importiert Session-Daten aus der Zwischenablage. Bei

diesen Daten kann es sich um den Pfad zu einer Session-Datei handeln oder um einen

kodierten Text, in dem die Ticket-Daten Base64-kodiert vorliegen. Sie finden diesen Text

für gewöhnlich in der Email-Benachrichtigung über ein neues Ticket. Befindet sich nichts

in der Zwischenablage, öffnet sich ein Datei-Dialog zur Auswahl einer Session-Datei

analog zu Kapitel 3.6.1 Hauptmenü. Die Liste der vorhandenen Session-Dateien ist mit

einem Context-Menü „Einfügen“ hinterlegt. Dieser Menü-Punkt hat die gleiche Funktion

wie der Button „Ticket importieren“.

Kann der Inhalt der Zwischenablage nicht eingelesen werden wird eine entsprechende

Fehlermeldung angezeigt.

Abbildung 3-8: Ticket importieren



3.6.3 Drag & Drop

Sie können die Session-Datei auch aus einem Datei-Browser oder einem E-Mail-Client

(z.B. Outlook) per Drag & Drop in die Console importieren. Ziehen Sie dazu die zu

importierende Session-Datei in die Liste der vorhandenen Sessions. Wenn sie die

Maustaste loslassen, wird die Datei analog zu 3.6.1 Hauptmenü importiert.

Abbildung 3-9: Drag & Drop von Session-Dateien

3.7 Protokolle pro Netzelement

Zur Vereinfachung der Bedienung werden ab der Version 2.4.16 des CRD-Portals

Session-Dateien zusätzlich mit der Information erstellt, welche Protokolle für welches

Netzelement freigegeben sind. Diese Session-Dateien können erst ab Version 3.4.6 der

Console eingelesen werden. Die Liste der auswählbaren Protokolle wird dann

entsprechend den Informationen aus der Session-Datei für jedes Netzelement

eingeschränkt.

Werden manuelle Änderungen an der IP-Adresse des Portals, der IP-Adresse eines

Netzelements oder der Ticketnummer vorgenommen, wird die Liste der auswählbaren

Protokolle zurückgesetzt, so dass wieder alle verfügbaren Protokolle auswählbar sind.

Das CRD-Portal lehnt Verbindungsanfragen für Protokolle, die nicht für das jeweilige

Netzelement freigegeben sind grundsätzlich ab.

3.8 Schlüssel-Handling

3.8.1 Erzeugen eines RSA-Schlüssels

Für den Zugang zum CRD-Portal muss der CRD-User einen RSA-Schlüssel generieren,

da die Authentifizierung gegenüber dem CRD-Portal grundsätzlich auf der Basis des in

OpenSSH integrierten Challenge-Response-Verfahrens mittels kryptografischer Schlüssel

erfolgt. Der zum RSA-Schlüssel gehörende öffentliche Schlüssel (Public Key) muss vom



CRD-User dem CRD-Portal-Administrator übermittelt werden, der private Schlüssel

(Private Key) verbleibt immer beim CRD-User.

Über das Menü „Extras“ „RSA-Key“ „RSA-Key generieren“ lassen sich mit der CRD-

Console entsprechende Schlüsselpaare erzeugen.

Abbildung 3-10: Menü Schlüsselerzeugung

Folgender Dialog erscheint:

Abbildung 3-11: Schlüsselerzeugung

Unter „Key-Name“ ist der Pfad (inklusive Dateiname) auszuwählen, unter dem die Datei

mit dem privaten Schlüssel erzeugt werden soll. Der Button „…“ öffnet den „Speichern

unter“-Dialog.

Hinweis 4: Der private Schlüssel ist zu schützen und vor Einsicht anderer zu

bewahren. Erstellen Sie den privaten Schlüssel in einem Ordner, auf den

nur Sie Zugriff haben und kopieren Sie den privaten Schlüssel niemals in

öffentlich lesbare Bereiche!

Als Kommentar sollte eine eindeutige Beschreibung des Keys hinterlegt werden, damit

nach dem Import des Schlüssels in das CRD-Portal der öffentliche Schlüssel eindeutig



der Firma und dem externen Service-Mitarbeiter (CRD-User) dieser Firma zugeordnet

werden kann.

Der Schlüssel ist mit einem Passwort zu schützen! Die CRD-Console warnt vor

unsicheren Passwörtern. Das Passwort muss minimal aus 8 Zeichen bestehen und

Zeichen aus mindestens 2 der folgenden Gruppen enthalten:

• große Buchstaben

• kleine Buchstaben

• Ziffern

• Sonderzeichen

Nach der Generierung erscheint folgender Dialog:

Abbildung 3-12: Public Key

Das Schlüsselpaar wurde erfolgreich erstellt. Neben der angegebenen privaten

Schlüsseldatei wurde auch eine Datei desselben Namens mit der Endung *.pub erstellt,

die den öffentlichen Schlüssel enthält (der Dateiinhalt ist derselbe wie im angezeigten

Textfeld). Die Public-Key-Datei sowie der Key-Fingerprint aus dem Textfeld sind über

einen sicheren Kommunikationsweg an den Administrator des CRD-Portals zu

übermitteln. Es muss immer sichergestellt werden, dass der korrekte öffentliche Schlüssel

des CRD-Users in das CRD-Portal importiert wird. Zur Verifikation des öffentlichen

Schlüssels wird der Fingerprint vor dem Import in das CRD-Portal vom Portaladministrator

überprüft.

Um sicherzustellen, dass der korrekte öffentliche Schlüssel in das CRD-Portal importiert

wird, ist vom CRD-User bzw. einer autorisierten Person der externen Servicefirma der

Fingerprint des öffentlichen Schlüssels über einen separaten Kommunikationsweg zum



Portaladministrator zu übermitteln (z.B. Fax, Brief, verschlüsselte Email, per Telefon).

Dazu kann der Fingerprint markiert und in eine separate Datei kopiert werden.

3.8.2 Anzeigen / Löschen eines RSA-Schlüssels

Über das Menü „Extras“ „RSA-Key“ „RSA-Key ansehen bzw. löschen“ können

erzeugte private Keys angesehen (der Fingerprint sowie der Public Key werden dann neu

berechnet) sowie gelöscht werden.

Abbildung 3-13: Keys ansehen und löschen

Hinweis 5: Wenn Sie feststellen, dass Ihr privater Schlüssel kompromittiert wurde, so

teilen Sie dies dem CRD-Administator sofort mit! Löschen Sie

anschließend das Schlüsselpaar und wiederholen Sie die

Schlüsselerzeugung.

3.8.3 Ändern der Passphrase eines RSA-Schlüssels

Über das Menü „Extras“ „RSA-Key“ „RSA-Passphrase ändern“ kann die Passphrase

von erzeugten privaten Keys geändert werden.

Hinweis 6: Aus Sicherheitsgründen sollten Sie die Passphrase von Ihrem privaten

Schlüssel regelmäßig ändern.

3.9 Einstellungen

Über das Menü „Einstellungen“ können verschiedene allgemeine Einstellungen

vorgenommen werden.



Abbildung 3-14: Einstellungs-Menü

Die Einstellungen werden in ‚conf/settings.xml‘ im Arbeitsverzeichnis der CRD-

Console gespeichert, sodass die Einstellung beim nächsten Start der CRD-Console

wieder geladen werden.

3.9.1 Erste Ausführung der Anwendung

Wenn die CRD-Console das erste Mal gestartet wird, wird ein Assistent angezeigt, welche

den Benutzer durch die allgemeine Einstellungen Sprache und private RSA-Schlüssel

führt. Als erste wird die Seite Spracheinstellung angezeigt, welche mit der lokalen

Systemsprache vorbelegt ist. Es kann zwischen Deutsch und Englisch gewechselt

werden. Für Systeme wo Deutsch nicht die Standardsystemsprache ist, wird Englisch als

Auswahl vorbelegt.

Abbildung 3-15: Assistent Auswahl Sprache



Auf die zweite Seite wird die Frage gestellt ob bereits ein RSA-Schlüsselpaar welche

durch die CRD-Console benutzt werden kann vorhanden ist. Hier kann zwischen bereits

vorhanden (Ja) und Generierung eines neuen RSA-Schlüsselpaars (Nein) gewählt

werden.

Abbildung 3-16 Assistent Abfrage vorhanden RSA-Schlüsselpaar

Wenn bereits ein RSA-Schlüsselpaar vorhanden ist, wird auf Seite 3 den Speicherort vom

privaten RSA-Schlüssel abgefragt, welche über den „…“-Button ausgewählt wird.



Abbildung 3-17 Assistent Abfrage Speicherort private RSA-Schlüssel

Wenn auf Seite 2 die Generierung eines RSA-Schlüsselpaars gewählt wird, wird die

Maske aus Abbildung 3-18 Assistent Generierung RSA-Schlüsselpaar angezeigt. Hier

kann für ein Schlüsselpaar die Schlüssellänge, Schlüsseldateiname und Passphrase

eingeben werden. Generieren generiert das Schlüsselpaar unter dem eingegebenen

Schlüsseldateiname.



Abbildung 3-18 Assistent Generierung RSA-Schlüsselpaar

Beim Speichern werden die eingegebenen Daten als allgemeine Console-Einstellungen

gespeichert, der Assistent beendet, und die CRD-Console gestartet.

3.9.2 Sprache

Es kann zwischen Deutsch und Englisch umgeschaltet werden.

3.9.3 Protokollierungsstufe

Fehler, Warnungen, Info-Meldungen und Debugging-Meldungen erfolgen in die Logdatei

CRDConsole.log im Arbeitsverzeichnis. Um ein unkontrolliertes Anwachsen der Datei

zu verhindern, wird diese bei jedem Start der CRD-Console neu angelegt.

Wenn die CRD-Console mittels „java –jar“ von Kommandozeile gestartet wird,

erfolgen die Logmeldungen zusätzlich auf die Standard-Ausgabe.

Im Einstellungs-Menü kann aus Protokollierungsstufen zwischen ‚ALL‘ und ‚FATAL‘

gewählt werden. Dies bestimmt den Grad und Detaillierung der Protokollierung in die

Logdatei. Bei ‚ALL‘ werden alle Logausgaben geschrieben. Dieser Modus kann bei der

Fehlerfindung hilfreich sein. Da unter anderen sehr viele technische Informationen geloggt

werden, ist diese Protokollierungsstufe im Normalbetrieb nicht notwendig. Bei ‚FATAL‘

werden nur fatale Fehler gemeldet. Alle Stufen dazwischen schalten Logmeldungen der

unterschiedlichen Kategorien an.



Detailgrad und Menge der Logmeldungen nehmen von ‚ALL‘ zu ‚FATAL‘ ab.

3.9.4 Proxy

Die CRD-Console bietet die Möglichkeit, Verbindungen über einen SOCKS-Proxy

aufzubauen. Der Menüpunkt „Proxy…“ öffnet den Proxy-Einstellungsdialog.

Abbildung 3-19: Proxy-Einstellungsdialog

Es sind Host (DNS-Name oder IP-Adresse) und Port (Standard für SOCKS ist 1080)

sowie SOCKS-Version anzugeben. Bei SOCKS-Version 5 sind zusätzlich Username und

Passwort einzugeben, mit denen die Authentifizierung am Proxy-Server erfolgen soll.

Beim Bestätigen mit „OK“, werden alle künftigen Verbindungsanfragen an den SOCKS-

Proxy gesendet. Falls ein Host und ein Port angegeben wurden und „SOCKS-Proxy

verwenden“ aktiviert ist, wird bei „OK“ zusätzlich geprüft, ob eine Socket-Verbindung zu

dem Port aufgebaut werden kann. Falls nicht, erscheint eine Warnung.

Ein Löschen des Hosts führt zum Löschen der Proxy-Einstellungen.

3.9.5 Standardpfad ändern

Über ein Dialogfenster kann Standardpfad zum Zugriff auf gespeicherte Vorlagen sowie

Schlüsseldateien eingestellt und geändert werden.

Abbildung 3-20: Standardpfad-Einstellungsdialog

Der Button „…“ öffnet den entsprechenden Auswahl-Dialog. Mit „OK“ wird die Einstellung

gespeichert, „Abbrechen“ bzw. „X“ schließen das Dialogfenster ohne die getroffene

Auswahl zu speichern.



3.9.6 Terminal

Über diesen Menüpunkt werden zwei Dialoge zum Anpassen folgender Einstellungen für

das Terminal angezeigt.

• „Farbe ändern“

• „Anzahl Zeilen für Scrollback“ .

3.9.6.1 Farbe ändern

Über diesen Dialog kann die Hintergrund- und Schrifftfarbe für das Terminal eingestellt

werden.

Abbildung 3-21: Dialog Farbe ändern

Standardwerte für die Schrifftfarbe bzw. Vordergrundfarbe sind weiß und für die

Hintergrundfarbe schwarz. Die Textfelder zeigen die auswählte Farbe in der Vorschau an.

Der Button rechts neben dem Textfeld öffnet den Dialog „Farbauswahl“ zur Anpassung

des Farbwertes.



Abbildung 3-22: Dialog Farbauswahl

Mit dem OK-Button im Dialog „Farbe ändern“ werden die geänderten Werte in der lokalen

Konfigurationsdatei gespeichert und der Dialog wird geschlossen.

Mit dem Abbrechen-Button wird der Dialog geschlossen ohne die Farbwerte zu ändern

oder zu speichern.

Achtung:Wählt man Vorder- und Hintergrundfarbe den gleichen Farbwert aus, und startet

eine Terminalverbindung so werden die Standardfarben schwarz bzw. weiß am Terminal

wieder wirksam.

3.9.6.2 Anzahl Zeilen für Scrollback

Mit diesem Dialog lässt sich die Anzahl der im Terminal dargestellten Zeilen für die

Funktion Scrollback verändern. Minimalwert ist 1, Maximalwert 99.999. Der Minimalwert

der dargestellten Zeilen im Terminal muss mindestens der Zeilenanzahl bedingt durch die

Fensterhöhe entsprechen. Ist die gewählte Anzahl an Zeilen geringer als der sich durch

die Fensterhöhe ergebenen Mindestanzahl an darstellbaren Zeilen, so wird der Wert auf

die Anzahl an darstellbaren Zeilen korrigiert. Ist z.B. das Terminalfenster groß genug für

zehn Zeilen, so werden mit einem geänderten Wert auf 1 immer noch zehn Zeilen im

Terminal dargestellt.



Abbildung 3-23: Dialog Anzahl Zeilen für Scrollback

Standardwert für Anzahl Zeilen für Scrollback ist 1000. Mit dem OK-Button wird der

geänderte Wert in der lokalen Konfigurationsdatei gespeichert und der Dialog

geschlossen. Mit dem Abbrechen-Button wird der Dialog geschlossen ohne zu speichern.



3.10 Aufbau einer Verbindung

3.10.1 Portal-Konfiguration

In der Registerkarte „CRD-Portal“ sind IP-Adresse des CRD-Portals, SSH-Port, der

eigene Firmenname, sowie der private RSA-Key einzutragen. Soweit nicht anders

vereinbart, ist der Standard-SSH-Port für CRD-Verbindungen 3022.

Mit CRD-Portal Erreichbarkeit wird mittels der Ampelfarben die Erreichbarkeit des Portal

dargestellt.

rot -- Portal ist nicht erreichbar.

gelb -- Verbindung zum Portal wird geprüft

grün – Verbindung zum Portal ist hergestellt

Im Folgenden ist ein Beispiel für das Ausfüllen der Felder dargestellt:

Abbildung 3-24: Registerkarte "CRD-Portal"

3.10.2 Verbindung zu einem Netzelement

Bitte beachten Sie das Kapitel 3.7 Protokolle pro Netzelement.

3.10.2.1 Aufbau einer SSH-Verbindung

In der Registerkarte „Netzelement“ ist das Zielsystem der Deutschen Telekom AG

anzugeben, zu dem eine Verbindung zu Diagnose- oder Wartungszwecken hergestellt

werden soll, sowie die CRD-Ticket-ID und das gewünscht Verbindungsprotokoll.

Zur Angabe des Zielsystems kann die IP-Adresse oder ein logischer Name (CRD-interne

Bezeichnung) verwendet werden.



Die Ticket-ID besteht aus 16 hexadezimalen Zeichen. Vermeiden Sie Tippfehler und

zusätzliche Zeichen (z.B. Leerzeichen am Ende).

Im Folgenden ist ein Beispiel für das Ausfüllen der Felder dargestellt:

Abbildung 3-25: Registerkarte "Netzelement"

Nachdem alle Daten eingetragen sind, können diese abgespeichert werden, um

mehrmalige Eingabe der Daten zu vermeiden. Dazu unter „Name der Session:“ einen

selbst gewählten Namen für die Verbindungsdaten eingeben und auf „Speichern“ klicken.

Die Session wird dann in die Liste der gespeicherten Sessions übernommen. Die

Verbindungsdaten können dann beim nächsten Mal per Mausklick ausgewählt werden.

Zum Starten der SSH-Verbindung auf „Verbindung öffnen“ klicken. Wenn die Verbindung

zum CRD-Portal zum ersten Mal hergestellt wird, kommt eine Sicherheitsabfrage zur

Authentifizierung.

Abbildung 3-26: Remote Host Authentication

Wird diese Abfrage mit „Always“ bestätigt, wird der Fingerprint des CRD-Portals in die

Datei CRD_known_hosts aufgenommen, welche sich im Arbeitsverzeichnis der CRD-

Console befindet bzw. dort erstellt wird. Die Abfrage erscheint dann nicht wieder.

Beim Bestätigen mit „Yes“ wird die Verbindung auch aufgebaut. Die Abfrage wird beim

nächsten Mal jedoch wieder erscheinen.

Beim Ablehnen mit „No“ wird der Verbindungsaufbau abgebrochen.



Mehr Informationen zur known_host-Datei im Glossar.

Anschließend erscheint die Passwort-Abfrage für den angegebenen privaten Schlüssel.

Abbildung 3-27: Passphrase-Abfrage bei SSH/Telnet

Bei positiver Prüfung der Parameter und erfolgreichem Verbindungsaufbau wird ein

Terminal-Emulator-Fenster geöffnet, in dem die SSH-Sitzung dargestellt wird. Die

Verbindung zum Netzelement der Deutschen Telekom AG durch das CRD-Portal ist nun

hergestellt. Der Terminal-Emulator (GSI-SSHTerm) ist in die CRD-Console integriert und

wird als Java-Programm in einem eigenen Prozess in einer separaten JVM ausgeführt.

Das CRD-Portal unterstützt verschiedene Methoden der Anmeldung am Netzelement:

• UserID / Passwort:

Hier muss der CRD-User die Anmeldedaten eingeben, die Ihm vom Betreiber

mitgeteilt wurden.

• Automatische Anmeldung:

Hier erfolgt die Anmeldung am Netzelement automatisch durch das CRD-Portal.

Der CRD-User ist bereits angemeldet, nachdem die Verbindung geöffnet wurde.



Die folgende Abbildung gibt eine Übersicht zum SSH-Terminal-Emulator:

Abbildung 3-28: SSH-Terminal-Emulator

Verbindungsprotokoll (SSH/Telnet)

Ticket-ID für diese Session

Ziel-Netzelement der Deutschen Telekom, zu dem die Verbindung aufgebaut ist

CRD-Portal-Verbindungsdaten

Eigener Firmenname

Verbindungsstatus

SSH-Ein-/Ausgaben



Der SSH-Terminal-Emulator erlaubt das Markieren von Textabschnitten mit der linken

Maustaste und Copy&Paste über das Kontextmenü (rechte Maustaste):

Abbildung 3-29: Markieren und Kopieren/Einfügen

Mit „Clear“ lassen sich alle bisherigen Ausgaben im Terminal-Emulator löschen. „Refresh“

aktualisiert die Anzeige.

Das Fenster kann beliebig skaliert werden. Der Inhalt (Manpages, vi-Editor etc.) sollten

sich entsprechend anpassen.

Hinweis 7: Alle Ein- und Ausgaben der SSH-Verbindung werden durch das CRD-

Portal aufgezeichnet. Verantwortliche Administratoren können aktive

Verbindungen live monitoren.

Zum Beenden der Verbindung ist „exit“ einzugeben und das zu Fenster schließen.

Prinzipiell können mehrere SSH-Verbindungen (auch zum selben Netzelement)

gleichzeitig geöffnet sein. Dazu ist in der CRD-Console mit den gewünschten

Verbindungsdaten einfach ein weiteres Mal auf „Verbindung öffnen“ zu klicken. Diese

Möglichkeit kann jedoch durch das Session-Ticket im CRD-Portal eingeschränkt werden.

Falls die SSH-Verbindung nicht aufgebaut werden kann und eine Fehlermeldung

erscheint, bitte im Kapitel „Fehlerbehandlung“ nachschlagen.

3.10.2.2 Aufbau einer Telnet-Verbindung

Der Aufbau einer Telnet-Verbindung erfolgt analog zum Aufbau einer SSH-Verbindung

(siehe Kapitel 3.10.2.1). Im Reiter „Netzelement“ ist als Protokoll „telnet“ auszuwählen.

Die Telnet-Verbindung erfolgt mit demselben Terminal-Emulator wie die SSH-Verbindung.

Falls die Telnet-Verbindung nicht aufgebaut werden kann und eine Fehlermeldung




3.10.2.3 Aufbau graphischer Verbindungen

Für die Remote Desktop Verbindungen zu Netzelementen mit graphischen

Benutzeroberflächen nutzt die Console die "Virtual Network Computing", kurz VNC -

Lösung.

Speziell wird die VNC-Software TurboVNC eingesetzt. Über TurboVNC werden

Verbindungen zu Netzelementen mit den Protokollen RDP,NX und x2go hergestellt.

TurboVNC ist eine Implementierung von VNC, die darauf abgestimmt ist, Verbindungen

mit hoher Performance für 3D- und Video-Workloads bereitzustellen. Die Dokumentation

des TurboVNC ist nicht Bestandteil dieses Handbuches. An dieser Stelle werden nur die

Abweichungen vom Standartverhalten des VNC-Viewers erwähnt. Der VNC-Viewer stellt

mit der Taste F8 ein Kontext-Menü zu Verfügung.

Abbildung 3-30: Kontext-Menü VNC-Viewer

3.10.2.4 Aufbau einer RDP-Verbindung

Der Aufbau einer RDP-Verbindung erfolgt analog zum Aufbau einer SSH-Verbindung

(siehe Kapitel3.10.2.1). Im Reiter „Netzelement“ ist als Protokoll „rdp“ auszuwählen.

Bei Auswahl von „rdp“ als Protokoll erscheint ein neuer Reiter „VNC-Einstellungen“.



Abbildung 3-31: Reiter „VNC-Einstellungen“ für RDP

Hier kann die gewünschte Auflösung für die grafische Verbindung ausgewählt werden.

Damit kann die Größe des Fensters an die Größe des Monitors angepasst werden.

Standard ist 1280x1024. Mit dem Button „Eingaben leeren“ wird die Standard-Auflösung

wieder ausgewählt. Die Wahl der Auflösung unterliegt keiner Prüfung durch das CRD-

Portal.

Falls der private RSA-/DSA-Key mit einer Passphrase geschützt ist, so ist diese beim

Öffnen der Verbindung einzugeben:

Abbildung 3-32: Passphrase-Abfrage bei RDP/NX/X2GO

Das Senden der Passphrase erfolgt mit der Enter-Taste. Abbruch durch Schließen des

Fensters oder Drücken der ESC Taste.

Bei positiver Prüfung der Parameter und erfolgreichem Verbindungsaufbau wird in dem

Secure-VNC-Viewer nun die RDP-Sitzung dargestellt. Die Verbindung zum Netzelement

der Deutschen Telekom AG durch das CRD-Portal ist bereits hergestellt. Der Secure-

VNC-Viewer wird als externes Java-Programm in einem eigenen Prozess in einer

separaten JVM ausgeführt.

Das CRD-Portal unterstützt verschiedene Methoden der Anmeldung am Netzelement:

• UserID / Passwort:

Hier muss der CRD-User die Anmeldedaten eingeben, die Ihm vom Betreiber

mitgeteilt wurden (folgende Abbildung bezieht sich auf diesen Fall).



• Automatische Anmeldung:

Hier erfolgt die Anmeldung am Windows-Netzelement automatisch durch das

CRD-Portal. Der CRD-User ist bereits am angemeldet, nachdem die Verbindung

geöffnet wurde.



Folgende Abbildung gibt einen Überblick:

Abbildung 3-33: RDP-Sitzung

Der VNC-Viewer stellt den Windows-Desktop des Ziel-Netzelements der Deutschen

Telekom AG dar.

Hinweis 8: Die RDP-Sitzung wird durch das CRD-Portal aufgezeichnet.

Hinweis 9: Beim Vollbildmodus werden alle anderen Fenster und auch die Windows-

Taskleiste auf dem Monitor überdeckt. Der Fensterrahmen und die

Buttons des VNC-Viewers verschwinden. Mit Strg+Alt+Shift+F oder

Kontextmenü (F8) Fullscreen kann zwischen Vollbildmodus und

Fenstermodus gewechselt werden. Durch Drücken der Windows-Taste

auf der Tastatur, gelangt man auf den eigenen Windows-Desktop zurück,

wo der VNC-Viewer bei Bedarf beendet werden kann. Durch Abmelden

vom Ziel-Netzelement wird der VNC-Viewer (und damit das Vollbild)

automatisch geschlossen.

Ein Beenden der RDP-Verbindung sollte unbedingt durch das Abmelden vom Windows im

VNC-Viewer erfolgen. Der VNC-Viewer beendet sich dann von selbst.

Verbindung hart beenden

Ticket-ID Firmenname

Protokoll, Auflösung, Hostname bzw. IP VNC-Servers (=CRD-Portal)

In den Vollbildmodus wechseln

Strg+Alt+Entf an den entfernten Desktop senden

Windows-Desktop des Netzelements

Anzeige aktualisieren

Windows-Taste an den entfernten Desktop senden

Strg + Alt an den entfernten Desktop senden



Durch das Schließen des Fensters oder durch das Klicken auf „Disconnect“ wird die CRD-

Verbindung zwar auch korrekt beendet aber die Windows-Sitzung auf dem Netzelement

der Deutschen Telekom AG bleibt noch aktiv. Das bedeutet, dass alle Programme und

Prozesse noch laufen (Windows-Sitzung wird gesperrt). Beim Entsperren der Windows-

Sitzung durch erneutes Anmelden mit demselben Windows-Nutzer stehen die geöffneten

Programme und Prozesse wieder zur Verfügung. Ein gesperrter Windows-Desktop kann

jedoch auch bedeuten, dass andere Windows-Nutzer gehindert werden, sich anzumelden

(hängt vom Windows ab)!

Prinzipiell können mehrere RDP-Verbindung gleichzeitig geöffnet sein, sofern das CRD-

Ticket das erlaubt. Für Standard-Windows-Systeme gilt jedoch, dass immer nur eine

RDP-Sitzung zu einem bestimmten Netzelement aktiv sein kann. In dem Moment, wenn

erneut eine Anmeldung mit denselben Windows-Login-Daten erfolgt, wird die aktive

Windows-Sitzung übernommen und der bisher angemeldete VNC-Viewer verliert die

Verbindung und wird beendet.

Falls die RDP-Verbindung nicht aufgebaut werden kann und eine Fehlermeldung


3.10.2.5 Aufbau einer NX-Verbindung

Der NX-Verbindungsaufbau erfolgt analog zu Aufbau einer RDP-Verbindung (siehe

Kapitel 3.10.2.4). Im Reiter „Netzelement“ ist als Protokoll „nx“ auszuwählen.

Im Reiter „VNC-Einstellungen“ kann zusätzlich zur Auflösungseinstellung die Wahl der

Desktop-Benutzeroberfläche vorgenommen werden. Es kann zwischen "Gnome" und

"KDE" gewählt werden. Der Standardwert ist "Gnome".

Abbildung 3-34: Reiter „VNC-Einstellungen“ für NX

Die NX-Verbindung erfolgt mit demselben VNC-Viewer wie die RDP-Verbindung.

Folgende Abbildung zeigt die Anmeldemaske für NX-Verbindungen. Wenn dieses Fenster

erscheint, ist die Verbindung zum Netzelement bereits aufgebaut.



Abbildung 3-35: NX-Anmeldung

Auch hier gibt es die beiden Möglichkeiten, dass sich der CRD-User selbst mit den Daten

anmelden muss, die ihm bekannt sind (Abbildung 3-35 bezieht sich auf diesen Fall) oder

dass die Anmeldung automatisch durch das CRD-Portal erfolgt. Nach erfolgreicher

Anmeldung, erscheint bei NX die grafische Desktop-Umgebung des UNIX-Netzelements

(zum Beispiel Gnome oder KDE). Dies ist in folgender Abbildung zu sehen.



Abbildung 3-36: NX-Sitzung mit Gnome-Desktop

Für den Fall, dass bereits NX-Verbindungen zu diesem Netzelement bestehen, wird nach

erfolgreicher Authentifizierung zunächst eine Liste der laufenden Verbindungen angezeigt.

Die folgende Abbildung zeigt die NX-Verbindung zu einem System, zu dem bereits eine

andere NX-Verbindung besteht.



Abbildung 3-37: Bestehende NX-Verbindungen

Die Tabelle zeigt alle bestehenden NX-Verbindungen mit Session-Name (NX-interne ID),

Type (zum Beispiel Gnome oder KDE), Auflösung, Status und weiteren Angaben.

Folgende Aktionen sind möglich:

• Refresh: Liste aktualisieren.

• Resume: Gewählte NX-Verbindung übernehmen. Der ursprüngliche CRD-User

verliert damit seine Verbindung. Programme und Fenster bleiben bestehen.

• Terminate: Gewählte NX-Verbindung terminieren. Der ursprüngliche CRD-User

verliert damit seine Verbindung. Programme und Fenster gehen verloren.

• New: Neue NX-Verbindung öffnen. Bestehende Verbindungen bleiben

unverändert. Abhängig von der NX-Server-Version kann die Zahl maximaler

Verbindungen limitiert sein.

• Cancel: Eigene Verbindung abbrechen. Bestehende Verbindungen bleiben

unverändert.

3.10.2.6 Aufbau einer X2GO-Verbindung

Der X2GO-Verbindungsaufbau erfolgt analog zum Aufbau einer NX-Verbindung (siehe

Kapitel 3.9.4). Im Reiter „Netzelemente“ ist das Protokoll „x2go“ auszuwählen.

Bestehende Verbindungen



Im Reiter „VNC-Einstellungen“ kann zusätzlich zur Auflösungseinstellung die Wahl der

Desktop-Benutzeroberfläche vorgenommen werden. Es kann zwischen „Mate“, "Gnome"

und "KDE" gewählt werden. Der Standardwert ist "Mate".

Falls der private RSA-/DSA-Key mit einer Passphrase geschützt ist, so ist diese beim

Öffnen der Verbindung einzugeben: Siehe Kapitel 3.9.3.

Folgende Abbildung zeigt die Anmeldemaske für X2GO-Verbindungen. Wenn dieses

Fenster erscheint, ist die Verbindung zum Netzelement bereits aufgebaut.

Abbildung 3-38: X2GO-Verbindung mit Login-Dialog



3.10.2.7 Aufbau einer SCP-Verbindung zum Hochladen von Dateien

SCP kann genutzt werden, um lokale Dateien zu UNIX-basierten Netzelementen zu

kopieren (hochladen).

Der Aufbau einer SCP-Verbindung erfolgt analog zum Aufbau einer SSH-Verbindung

(siehe Kapitel 3.10.1). Als Protokoll ist „scp (lokal => remote)“ auszuwählen. Durch diese

Auswahl wird ein neuer Reiter für die SCP-spezifischen Verbindungsdaten sichtbar:

Abbildung 3-39: SCP Protokollauswahl

In dem neuen Reiter „SCP-Einstellungen“ sind Quelle und Ziel für den Dateitransfer

anzugeben.

Für das Kopieren lokaler Dateien zum Netzelement sieht der Reiter wie folgt aus:

Abbildung 3-40: SCP von lokal nach remote

Über den Button „…“ ist die lokale Datei auszuwählen.



Hinweis 10: Es können keine Verzeichnisse kopiert werden. Verzeichnisse können

jedoch mit Archivprogrammen zu Dateien gepackt werden.

Hinweis 11: Es kann nur eine Datei ausgewählt werden. Mehrere Dateien sind

separat zu kopieren oder mittels Archivprogrammen zu einer Datei zu

packen.

Hinweis 12: Das Kopieren von Dateien, die zur Kopierzeit verändert werden (z.B.

Logdateien), wird ausgeführt, endet aber in einem Fehler, da sich die

Dateigröße während des Kopierens ändert. Kopiert wird nur die Größe

der Datei zum Startzeitpunkt des Kopierens.

Im darunter liegenden Textfeld ist das Zielverzeichnis auf dem Netzelement anzugeben,

in das die Datei hochgeladen werden soll. Folgendes ist dabei zu beachten:

• Es muss ein bereits bestehendes Verzeichnis in UNIX-Notation angegeben

werden. Ein noch nicht existierendes Verzeichnis kann nicht angelegt werden.

• Es darf kein Dateiname am Ende angegeben werden. Ein gleichzeitiges Kopieren

und Umbenennen der Datei ist nicht möglich.

• Das Basis-Verzeichnis ist das Home-Verzeichnis des Firmen-Users, dem der

private Key zugeordnet ist. Pfadangaben können relativ zu diesem Verzeichnis

angegeben werden.

• Slashes statt Backslashes verwenden.

• Keinen Slash am Ende verwenden (z.B. nicht: „ordner1/ordner2/“).

• Maximale Pfadlänge für das Zielverzeichnis: 200 Zeichen.

• Für Pfade, die außerhalb des Home-Verzeichnisses des Firmen-Users liegen (z.B.

„/etc“) bestehen evtl. keine Schreibrechte.

• Bereits bestehende Dateien mit demselben Namen werden ohne nochmalige

Rückfrage überschrieben!

Korrespondierend zur originalen SCP-Syntax („scp localfile

target:destination“) ist der Teil destination in das zweite Textfeld einzutragen.

Um z.B. eine Datei in das Home-Verzeichnis des Firmen-Users zu kopieren, ist folgendes

Zielverzeichnis anzugeben:

. (alternativ kann auch der absolute Pfad verwendet werden: „/home/erwin“)

Um z.B. eine Datei in einen Ordner im Home-Verzeichnis zu kopieren, ist folgendes

Zielverzeichnis anzugeben:

./ordner (alternativ funktioniert auch nur „ordner“ oder „/home/erwin/ordner“)



Wenn die Datei noch umbenannt oder nachträglich in ein anderes Verzeichnis

verschoben werden soll, eignet sich das gleichzeitige Öffnen einer SSH-Verbindung

(siehe Kapitel 3.10.1) parallel zur SCP-Verbindung.

Durch Klicken auf „Verbindung öffnen“ wird der Kopiervorgang gestartet. Dazu öffnet sich

das Fenster „SCP-Verbindungen“. Es enthält die Übersicht aktiver und abgeschlossener

Kopiervorgänge. Falls der private RSA-Key mit einer Passphrase geschützt ist, so ist

diese vor Start des Kopiervorganges einzugeben (analog zu RDP/NX, siehe Abbildung

3-32).

Abbildung 3-41: SCP-Verbindungsübersicht

Hinweis 13: Alle Kopiervorgänge werden durch das CRD-Portal geloggt.

Falls die SCP-Verbindung nicht aufgebaut werden kann und eine Fehlermeldung


Dateigröße Kopier-Richtung (hier: lokal nach remote)

Verbindungsstatus Startzeitpunkt des Kopierens

Kopieren abbrechen (nur für aktive Kopiervorgänge)

Dateiname auf dem lokalen Rechner

Ansicht leeren (hat keinen Einfluss auf bereits kopierte Dateien oder aktive Kopiervorgänge)



3.10.2.8 Aufbau einer SCP-Verbindung zum Herunterladen von Dateien

SCP kann genutzt werden, um entfernte Dateien von UNIX-basierten Netzelementen zu

kopieren (herunterladen).

Der Verbindungsaufbau erfolgt analog zu Kapitel 3.10.2.7. Als Protokoll ist im Reiter

„Netzelement“ „scp (remote => lokal)“ auszuwählen. Der Reiter „SCP-Einstellungen“ sieht

wie folgt aus:

Abbildung 3-42: SCP von remote nach lokal

In das obere Textfeld ist der Pfad zur Quell-Datei auf dem Netzelement der Deutschen

Telekom AG anzugeben, die heruntergeladen werden soll. Folgendes ist dabei zu

beachten:

• Es muss eine existierende Datei in UNIX-Notation angegeben werden.

• Es darf kein Verzeichnis angegeben werden. Zum Kopieren mehrerer Dateien

oder ganzer Ordner sind diese vorher über ein Archivprogramm zu packen

(Zugang mittels CRD-SSH-Verbindung) oder jede Datei ist separat zu kopieren.

• Das Basis-Verzeichnis ist das Home-Verzeichnis des Firmen-Users, dem der

private Key zugeordnet ist. Pfadangaben können relativ zu diesem Verzeichnis

angegeben werden.

• Slashes statt Backslashes verwenden.

• Maximale Pfadlänge für den Dateinamen (remote): 200 Zeichen.

• Für Pfade, die außerhalb des Home-Verzeichnisses des Firmen-Users liegen (z.B.

„/etc“) bestehen evtl. keine Leserechte.

• Bereits bestehende Dateien mit demselben Namen auf dem lokalen Rechner

werden nicht ohne Rückfrage überschrieben.



Gemäß der originalen SCP-Syntax („scp target:remotefile destination“) ist der

Teil remotefile in das erste Textfeld einzutragen.

Um z.B. die „.bash_history“-Datei des Firmen-Users zu kopieren, ist folgender

Dateiname anzugeben:

./.bash_history (alternativ geht auch nur „.bash_history“)

Um z.B. die „authorized_keys“-Datei aus dem „.ssh“-Ordner des Firmen-Users zu

kopieren, ist folgender Dateiname anzugeben:

./.ssh/authorized_keys (alternativ geht auch nur „.ssh/authorized_keys“)

Falls die SCP-Verbindung nicht aufgebaut werden kann und eine Fehlermeldung


3.11 Aufruf der CRD-Console mit Kommandozeilen-

Parametern

Beim Aufruf der CRD-Console von der Kommandozeile mittels „java –jar

CRDConsole-<Version>.jar“ können Parameter übergeben werden. Eine Übersicht

liefert --help. (Aufruf: java –jar CRDConsole-<Version>.jar –-help).

Der Parameter –-notab deaktiviert das Design mit Tabs (Registerreitern) und aktiviert

das herkömmliche Design der Eingabefelder untereinander.

Der Parameter –-session kann verwendet werden, um mit dem Start der CRD-Console

automatisch eine Verbindung zu öffnen. Übergeben werden muss der Name der Session.

Voraussetzung ist, dass die Session zuvor unter diesem Namen abgespeichert wurde.

Alle Sessions, die in der Liste der gespeicherten Sessions auftauchen (siehe Abbildung

3-6), können also zum Autostart verwendet werden. Abbildung 3-6 zeigt zum Beispiel eine

Session mit dem Namen „ssh-session-jumpserver“. Um diese Session beim Start der

CRD-Console automatisch zu öffnen, muss der Aufruf „java –jar CRDConsole-

<Version>.jar –-session ssh-session-jumpserver“ sein.

Die Parameter –-notab und –-session sind auch zusammen verwendbar.



4 Fehlerbehandlung

Folgende Tabelle enthält mögliche Fehler, die mit der CRD-Console auftreten können und die hierfür empfohlenen „Maßnahmen“:

Fehler Behebung

Die CRD-Console startet nicht Führen Sie den Kommandozeilen-Befehl „java –jar

CRDConsole-<Version>.jar“ aus und analysieren

Sie die Fehlermeldung.

Stellen Sie sicher, dass Java korrekt installiert ist und in

aktueller Version (1.7) vorliegt.

Prüfen Sie die eingegebene IP-Adresse und den Port im

Reiter „CRD-Portal“. Prüfen Sie Ihre

Netzwerkkonnektivität. Versuchen Sie einen ping zu

dieser IP-Adresse.

Wenn der ping erfolgreich ist und der Fehler weiterhin

auftritt, schlägt die SSH-Anmeldung am CRD-Portal

mittels Challenge-Response fehl. Prüfen Sie, ob Sie den

korrekten privaten Schlüssel ausgewählt haben.

Kontaktieren Sie ggf. den CRD-Administrator.



Die Verbindung wurde vom CRD-Portal abgelehnt.

Das Ende-Datum des Tickets wurde überschritten.

Das Ticket wurde durch einen Ticket-Administrator am

Portal vorzeitig beendet.

Das Ticket ist noch nicht aktiv.



Das Protokoll ist im Ticket nicht erlaubt oder wird vom

Zielsystem nicht unterstützt, oder das Zielsystem ist nicht

erreichbar.

Das Zielsystem ist im Ticket nicht enthalten. Prüfen Sie

die eingegebenen Daten im Reiter „Netzelement“.

Das Protokoll ist nicht im Ticket enthalten. Prüfen Sie die

Einstellungen auf dem Reiter „Netzelement“.

Das Zielsystem ist nicht erreichbar oder das Protokoll ist

falsch. Prüfen Sie auf dem Reiter „Netzelement“ die

Angaben IP-Adresse und Protokoll.



Die Anzahl der am Netzelement gleichzeitig erlaubten

Verbindungen wurde überschritten.

Der im Reiter CRD-Portal eingetragene Firmenname ist

nicht im Ticket enthalten. Prüfen Sie die Eingaben.

Der benutzte User ist nicht im Ticket enthalten.



Der in der globalen Konfiguration gespeicherte Datei-Pfad

für die private RSA-Key-Datei ist falsch oder die Datei

existiert nicht. Wählen Sie einen Speicherort für Ihre

private RSA-Key-Datei!

Überprüfen Sie im Reiter „CRD-Gateway“ im Feld privater

RSA-Schlüssel die Eingabe oder überprüfen Sie den

RAS-Key.



Die SSH-Anmeldung am CRD-Portal ist erfolgreich aber

die angeforderte RDP-Verbindung wird abgelehnt.

Prüfen Sie die eingegebenen Daten im Reiter

„Netzelement“. Beachten Sie: Der CRD-Administrator legt

fest, wer, in welchem Zeitraum, zu welchen

Netzelementen und mit welchen Protokollen Zugriff hat.

Tickets können jederzeit deaktiviert werden. Kontaktieren

Sie ggf. den CRD-Administrator.

Die gespeicherten Sessions werden nicht angezeigt. Stellen Sie sicher, dass die CRD-Console Zugriff auf das

Arbeitsverzeichnis hat. Lesen Sie Kapitel 3.2 und 3.3.

Kopieren Sie die Session-Dateien manuell in den

„sessions“-Ordner und starten Sie die CRD-Console

neu.

Stellen Sie sicher, dass der „conf“-Ordner im

Arbeitsverzeichnis („.CRDconsole“) die Datei

„sessions.xsd“ enthält. Die Datei sollte automatisch

kopiert werden und befindet sich innerhalb des Archivs

CRDConsole-<Version>.jar.

Starten Sie die CRD-Console neu.

Die ausgewählte Session-Datei aus der Liste der

gespeicherten Sessions kann nicht gelesen werden.

Löschen Sie die Session und geben Sie die

Verbindungsdaten manuell ein. Versuchen Sie die

eingegebenen Daten neu abzuspeichern und einzulesen.



Versuchen Sie die Datei erneut zu kopieren. Prüfen Sie

die Netzwerkkonnektivität.

Prüfen Sie, ob stattdessen eine SSH-Verbindung zu

diesem Netzelement möglich ist (sofern gestattet).

Prüfen Sie insbesondere den UNIX-Pfad für das

Netzelement. Beachten Sie dazu die Hinweise von

Kapitel 3.10.2.7 bzw. 3.10.2.8.

Beachten Sie: Der CRD-Administrator legt fest, wer, in

welchem Zeitraum und zu welchen Netzelementen

kopieren darf. Aktive Kopiervorgänge können durch den

CRD-Administrator jederzeit abgebrochen werden.


Überprüfen Sie die verwendeten Verbindungsdaten. Die

Verbindung ist eventuell blockiert. Beenden Sie aktive

RDP-Verbindungen zu diesem Netzelement. Starten Sie

die Verbindung erneut.

Falls die CRD-Console mit dem Befehl „java –jar“

gestartet wurde, ist sicherzustellen, dass die CRD-

Console sich nicht in anderen Verzeichnissen befindet.

Ändern Sie den Befehl „java –jar

ordner/CRDConsole-<Version>.jar“ zu „cd

ordner; java –jar CRDConsole-<Version>.jar“

Besteht der Fehler weiterhin, kontaktieren Sie ggf. den

CRD-Administrator.



Prüfen Sie die eingegebene IP-Adresse und Port im

Reiter „CRD-Portal“. Prüfen Sie Ihre

Netzwerkkonnektivität. Versuchen Sie einen ping zu

dieser IP-Adresse.

Wenn der ping erfolgreich ist und der Fehler weiterhin

auftritt, schlägt die SSH-Anmeldung am CRD-Portal

mittels Challenge-Response fehl. Prüfen Sie, ob Sie den

korrekten privaten Schlüssel ausgewählt haben.


Die SSH-Anmeldung am CRD-Portal ist erfolgreich aber

die angeforderte Verbindung wird abgelehnt.

Prüfen Sie eingegebene Daten im Reiter „Netzelement“.

Beachten Sie: Der CRD-Administrator legt fest, wer, in

welchem Zeitraum und zu welchen Netzelementen Zugriff

hat. Tickets können jederzeit deaktiviert werden.

Kontaktieren Sie den CRD-Administrator.

Der Terminal-Emulator (GSI-SSHTerm) startet nicht richtig und reagiert nicht

mehr.

Schließen Sie das Fenster und starten Sie die

Verbindung erneut. Falls sich das Fenster nicht schließen

lässt, öffnen Sie die Übersicht aktiver Verbindungen

(„Extras“ „Aktive Verbindungen anzeigen“) und

brechen Sie die hängende Verbindung ab.

Alternativ kann der java-Prozess auch über den

Taskmanager bzw. mittels „kill“ beendet werden.



Beenden Sie zuerst alle CRD-Verbindungen. Aktive

Verbindungen können über „Extras“ „Aktive

Verbindungen anzeigen“ angezeigt werden. Dort können

diese auch terminiert werden.

Alternativ können java-Prozesse auch über den

Taskmanager bzw. mittels „kill“ beendet werden.

Hinweis 14: Über das Menü „Einstellungen“ „Protokollierungsstufe“ kann die Protokollierungsstufe erhöht werden. Setzen Sie die

Protokollierungsstufe auf „ALL“ um die meisten Ausgaben zu erhalten. Die Logdatei CRDconsole.log befindet sich im

Arbeitsverzeichnis („.CRDconsole“) der CRDConsole. Diese wird bei jedem Start neu angelegt. Analysieren Sie die

Ausgaben in der Logdatei um Fehler einzugrenzen.



5 Technische Ansprechpartner

Zur Klärung technischer Fragen sowie im Falle von Störungen wenden Sie sich bitte an

folgende Hotline:

Tel.: 0421/5155 8103

STTS SM Stichwort: CRD-Portal, 3rd-Party Hotline.



6 Glossar / Abkürzungsverzeichnis

Begriff Erläuterung

Arbeitsverzeichnis Verzeichnis, in dem die CRD-Console Einstellungen, Sessions, die known_hosts-Datei und die Logdatei speichert.

Das Verzeichnis heißt .CRDconsole und befindet sich im Home-

Verzeichnis des Users.

Beispiel Windows-XP: C:\Dokumente und Einstellungen\erwin\.CRDconsole

Beispiel Windows 7: C:\Benutzer\erwin\.CRDconsole

Beispiel Linux: ~erwin/.CRDconsole

CRD Controlled Remote Diagnosis (Kontrollierte Fernwartung). Firewall-ähnliche Server-Client-Architektur zum Verwalten, Autorisieren, Monitoren und Loggen von Fernwartungszugriffen.

CRD-Session Wartungsfenster: Zeitraum, in dem ein externer CRD-User auf ein Netzelement zugreifen kann.

CRD-Session-Ticket Auch: Session-Ticket. Zugriffsberechtigung für einen externen CRD-User auf ein Netzelement.

CRD-User Mitarbeiter einer externen Firma, der Diagnose- und Wartungsarbeiten auf Netzelementen durchführt (Bsp. Useraccount „Mustermann-1“)

DNS-Name Domain Name System. Name für eine IP-Adresse.

extTerminal Rechner des CRD-Users.

Firmen-Account Der auf dem CRD-Portal eingerichtete UNIX-Account des externen Servicedienstleisters (Bsp. Firmenaccount „Mustermann“)

JVM Java Virtual Machine. Virtuelle Java-Umgebung (eigener Betriebssystem-Prozess) zur Ausführung eines Java-Programms.

known_hosts-Datei Diese Datei enthält alle SSH-Server, zu denen bereits Verbindungen erfolgt sind („bekannte Server“). Identifiaktionsmerkmal ist ein SSH-Hostkey, den der Server dem Client präsentiert. Bei noch unbekannten Servern kann der Nutzer entscheiden dem Server dauerhaft zu vertrauen ( Hostkey wird zur known_hosts hinzugefügt).

Wenn der Hostkey bei bekannten Servern plötzlich abweicht, kann dies ein Hinweis auf eine Man-In-The-Middle-Attacke sein!

Die known_hosts-Datei der CRD-Console befindet sich im Arbeitsverzeichnis und heißt CRD_known_hosts.

Netzelement Rechner der Deutschen Telekom AG, zu dem eine CRD-Verbindung zu Wartungs- oder Diagnosezwecken aufgebaut werden soll. Dieses System muss nicht zwangsweise das eigentliche Zielsystem sein, sondern kann z.B. ein vorgelagerter Jump-Server sein. Aus Sicht des CRD-Portals ist dies jedoch der relevante Zielrechner.

NX Grafische Client-Server-Anwendung zum Steuern von UNIX-Systemen (mit Gnome-/KDE-Desktop). Entwickelt von NoMachine. Basiert auf SSH.



OpenSSH BSD-lizensierte Open-Source-Implementierung von SSH.

RDP Remote Desktop Protocol. Windows-spezifisches Protokoll zum Darstellen und Steuern eines entfernten Windows-Rechners.

SCP Secure Copy. Netzwerk-Protokoll zum Kopieren von Dateien über einen SSH-Tunnel.

SOCKS Internet-Protokoll, das Client-Server-Anwendungen erlaubt, protokollunabhängig und transparent die Dienste eines Proxyservers zu nutzen.

Abkürzung von „SOCKetS“

SSH Secure Shell. Kommandozeilenbasiertes Protokoll zum Steuern eines entfernten UNIX-Systems über eine verschlüsselte Verbindung.

SSH-Tunnel Verschlüsselter Datenstrom zwischen SSH-Client und SSH-Server, über den ein beliebiger anderer Datenstrom (z.B. unverschlüsselt) gesendet werden kann.

Telnet TCP-basiertes, unverschlüsseltes Netzwerk-Protokoll. Unter anderem zum Steuern von Routern/Switches.

Ticket-ID Systemgenerierte 16-stellige Hexadezimalzahl zur eindeutigen Kennzeichnung eines CRD-Session-Tickets.

TightVNC VNC-System, welches hohe Kompression des VNC-Datenstroms ermöglicht.

VNC Virtual Network Computing. Server-Client-System zum Anzeigen des Bildschirminhalts eines entfernten Rechners und Senden von Tastatur- und Mauseingaben. UNIX-Alternative zu RDP.

Documents

CRD-Portal · CRD-Portal - Benutzerhandbuch für Servicemitarbeiter (CRD-User) Handbuch_CRDUser.docm Seite 1 1 Einleitung und Abgrenzung Das vorliegende Dokument beschreibt die …