Foxwiki - Benutzerbeiträge [de]

Netzwerkverkabelung

2020-10-05T16:17:52Z

Meikschwalm:

== Netzwerk-Kabel ==

Mit Netzwerkkabel werden die Stationen bzw. Teilnehmer eines Netzwerks physikalisch miteinander verbunden. 
Es gibt verschiedene Netzwerkkabel. Sie unterscheiden sich im Material und im Aufbau. 
Während es Kupferkabel entweder als Twisted-Pair-Kabel oder Koaxialkabel gibt, bestehen Lichtwellenleiter aus dem Grundstoff Glas oder Kunststoff.

=== Passive Anschlusskomponenten einer Netzwerk-Verkabelung ===

* Anschlussdosen (Anschlusseinheiten)
* Rangierverteiler (Patch-Panels)
* Rangierkabel (Patch-Kabel)

=== Patchfeld und Patchkabel ===

Patchkabel sind die bevorzugten Kabel, um Patchfelder und Anschlussdosen mit den Netzwerkstationen und aktiven Netzwerk-Komponenten zu verbinden. 
Patchfelder sind Vorrichtungen, an denen die Netzwerkleitungen ankommen. 

=== Glasfaser oder Twisted-Pair-Kabel? ===

'''Twisted-Pair-Kabel'''
* maximale Datenrate
1GBit/s Cat. 5e, 6 (bis 100 Meter) 
10GBit/s Cat. 6A (bis 55 Meter) 
10GBit/s Cat. 7 (bis 100 Meter) 
40GBit/s Cat. 8 (bis 30 Meter) 
* leichter handhabbar als Glasfaser
* für die meisten Geräte und Anwendungen vollkommen ausreichend
* Netzwerk-Geräte lassen sich mit Strom versorgen (Power over Ethernet (PoE))
* Verkabelung von Routern, Switchen, Servern sowie verschiedene Endgeräte 

'''Welche Kategorie bzw. Klasse sollte man wählen?'''

Der typische Anwendungsfall für Twisted-Pair-Kabel sieht die Arbeitsplatzverkabelung in Büros und in Wohnhäusern vor. 
Bei einer rationalen Betrachtung liegt die Schlussfolgerung nahe, dass hier keine strukturierte Verkabelung notwendig ist, 
die über die Kategorie 6A oder die Klasse EA hinausgeht. Selbst wenn die Verkabelung zukünftigen Anforderungen genügen soll, 
sind Kabel der Kategorien 5 und 6 vollkommen ausreichend. Es gibt selten einen Grund alte CAT5- oder CAT6-Verkabelungen auszutauschen. 
Selbst in einem Rechenzentrum sind TP-Verkabelungen der Kategorie 8 äußerst fraglich. Leitungslängen von maximal 30 m können bei größeren Rechenzentren einfach nicht ausreichen.

'''CAT5-Kabel''' 
sind wahrscheinlich die am häufigsten verlegten Netzwerkkabel und somit in den meisten älteren strukturierten Netzwerk-Verkabelungen anzutreffen. 
In der Regel werden sie für die parallele Nutzung von Netzwerk und Telefonie eingesetzt. 
CAT5-Kabel sind für Ethernet, Fast-, Gigabit-Ethernet und in Ausnahmefällen auch für 10-Gigabit-Ethernet geeignet.
Für Gigabit-Ethernet musste die Spezifikation überarbeiten werden. Die Kabel wurden mit Category 5e (e = enhanced) bezeichnet. 
CAT5e ist genauer spezifiziert und kommt vor allem in Europa zum Einsatz. 
Umsichtig verlegte CAT5-Leitungen profitieren davon, dass sie nach der Messung meistens die Anforderungen für CAT5e erfüllen.
Seit der Normung im Jahr 2003 gilt für CAT5e nur noch die Bezeichnung CAT5. Die davor verlegten CAT5-Kabel unterstützen Gigabit-Ethernet nicht immer.
Twisted-Pair-Kabel der Category 6 / Kategorie 6 (Class E)

'''CAT6-Kabel''' 
sind in den neueren strukturierten Netzwerk-Verkabelungen anzutreffen. 
Für die Verlegung von CAT6-Kabel gibt es meistens keinen wirklichen Grund. Im Bereich Ethernet mit 1 GBit/s reicht CAT5 (CAT5e) oft aus. 
Eine bessere Qualität als CAT6 ist eigentlich nicht notwendig. 
Deshalb dauerte es lange, bis CAT6-Kabel für strukturierte Verkabelungen eingesetzt wurden. Irgendwann wurden häufiger CAT6-Kabel als CAT5-Kabel verlegt. 
Sie waren einfach besser lieferbar. 
Außerdem bemerkte so mancher Elektroinstallateur, dass man mit einem "reingeklatschten" CAT6-Kabel bessere Messwerte erreichen kann, als bei einem umsichtig verlegten CAT5-Kabel. 
Vor allem, wenn das eine oder andere Kabel länger wurde, als es eigentlich sein durfte. Nacharbeiten und Diskussionen mit dem Kunden konnten vermieden werden.
Im Vergleich zu CAT5-Kabel enthalten CAT6-Kabel dickere Adern und mehr Folien- und Geflecht-Schirmung. 
Vor allem beim Abisolieren und Auflegen an Dosen und Patchfeldern entsteht wegen der Schirmung ein größerer Aufwand, der für geübte Installateure vernachlässigbar ist.
Eine Erweiterung von CAT6 ist CAT6A bzw. CAT6A.

'''CAT6A''' 
Mit 10-Gigabit-Ethernet (10GBASE-T) wurden Twisted-Pair-Kabel mit dem Standard CAT6A (A = augmented) spezifiziert, der für Frequenzen bis zu 500 MHz ausgelegt ist. 
CAT6A-Kabel enthielten anfangs Trennstege, um die Adernpaare räumlich voneinander zu trennen. 
Auf diese Weise soll das Übersprechen reduziert werden. 
Allerdings gehen damit ein größerer Kabeldurchmesser und ein größerer Biegeradius einher, wodurch sich die Kabel schwerer verlegen lassen.
Bei 10GBASE-T erreicht man mit diesen Kabeln eine maximale Entfernung von 55 Metern. 
Zusätzlich benötigt man Patchpanels, die den Abstand zwischen den einzelnen Anschlüssen erhöhen, geschirmte RJ45-Stecker, Spezialwerkzeug für die Konfektionierung, geschlossene Kabeltrassen und die Trennung unterschiedlicher Kabelarten, um gegenseitige Beeinflussungen zu vermeiden. 
 
'''Twisted-Pair-Kabel der Category 7 / Kategorie 7 (Class F)''' 
Spätestens bei 10-Gigabit-Ethernet sind Kabel der Kategorie 7 notwendig (oder CAT6A). 
Da diese Technik als zukunftsweisend gilt und die Kabel nicht sehr viel teurer sind als CAT6-Kabel, werden viele Neuinstallationen mit CAT7-Kabel ausgerüstet. 
Die Kategorie 7A ist sogar bis 1000 MHz spezifiziert und wurde für Anwendungen ausgearbeitet, die über 10 GBit/s hinausgehen. 
Im Unterschied zu den Kabeln der Kategorie 5 und 6 sind alle vier Adernpaare eines CAT7-Kabels einzeln geschirmt. 
Das bedeutet, es kommen generell Folien- und Geflecht-geschirmte Kabel zum Einsatz. 
Ungeschirmte UTP-Kabel sind in der Kategorie 7 möglich, aber in der Praxis eher selten anzutreffen. 
Es werden hauptsächlich S/FTP-Kabel verwendet.
Hinzu kommen neue Steckverbinder. 
Der Grund, die Abstände zwischen den RJ45-Steckern ist zu gering. Eine Verkabelung mit RJ45-Patchkabeln und -dosen und CAT7-Kabel ist also keine "echte" CAT7-Verkabelung, sondern höchstens CAT6A. 
 

In der Vergangenheit haben viele Elektroinstallateure die nötige Sorgfalt beim Verlegen von CAT6- und CAT7-Kabel vermissen lassen. 
Darauf angesprochen wurde meist nur milde gelächelt und abgewunken. 
Natürlich, auf einem schlecht behandelten CAT7-Kabel ist Fast-Ethernet mit 100 MBit/s auch kein Problem. 
Doch wer lässt CAT7-Kabel verlegen, um es nur für Fast-Ethernet zu nutzen? 
Was ist, wenn jemand 10GBase-T auf CAT7 nutzen will? Abwegig ist das nicht. 
Zwar werden mit 10GBase-T kaum Arbeitsplatzrechner ans Netzwerk angebunden. 
Doch lässt sich mit 10GBase-T eine schnelle Netzwerk-Infrastruktur aufbauen, die ohne teure Glasfaserkabel auskommt.
Der Elektroinstallateur muss dringend davon Abstand nehmen CAT6- und CAT7-Kabel auf die Schnelle "reinzuklatschen". 
Das zeugt von geringer Fachkenntnis und ist Pfusch.

Der wesentliche Unterschied zwischen CAT7- und CAT7A-Kabel ist der einsetzbare Frequenzbereich von 600 bzw. 1.000 MHz.

'''Wichtiger Hinweis:''' Leider werden für qualitativ hochwertige Netzwerkverkabelungen mit CAT7-Leitung 
oftmals CAT6-Netzwerkdosen und -Patchpanels verbaut, was die gesamte Verkabelung auf CAT6 degradiert. 
Alle CAT7-Patchkabel, -Patchfelder und Anschlussdosen mit RJ45-Steckverbindern entsprechen nicht der CAT7-Spezifikation. 
Das bedeutet, eine Netzwerkinstallation mit CAT7-Kabel und RJ45-Steckverbindungen ist höchstens eine CAT6A-Netzwerkinstallation. 
Um Netzwerkkomponenten gemäß CAT7 herzustellen, wurden eigens neue Steckverbindungen konzipiert, die im Wesentlichen den Abstand zwischen den Adernpaaren vergrößern. 

'''Twisted-Pair-Kabel der Category 8 / Kategorie 8''' 

Eigentlich müsste mit der Kategorie 7 Schluss sein. 
Der nächste Schritt wäre Glasfaserkabel auch im Tertiärbereich, auf den letzten hundert Metern zum Arbeitsplatz. 
Doch Kupferkabel haben gegenüber Lichtwellenleitern (LWL) signifikante Vorteile. 
So fallen die Gesamtkosten einer Verkabelung geringer aus, die Handhabung ist wesentlich leichter und zudem gesellt sich die PoE-Fähigkeit (Power over Ethernet) von Twisted-Pair-Kabeln hinzu. 

Eine Reichweite von 100 Meter kann nicht in jedem Fall erreicht werden. 
Deshalb begnügt man sich mit 30 Meter bei 2.000 MHz Bandbreite um damit 40 GBit/s (oder auch mehr) zu erreichen. 
Der eigentliche Grund der Leitungslängenbegrenzung liegt darin, den Energiebedarf der 40GBase-T-Chipsätze in Grenzen zu halten. 

'''Bei Kategorie 8 muss man zwischen mehreren Kategorien unterschieden:'''

* Cat. 8 (nach ANSI/TIA): Bandbreite bis 2 GHz, rückwärtskompatibel bzw. aufbauend auf Cat. 6A (F/UTP) mit RJ45-Steckverbinder
* Cat. 8.1 (nach ISO/IEC RJ45): Bandbreite bis 2 GHz, rückwärtskompatibel bzw. aufbauend auf Cat. 6A (F/UTP) mit RJ45-Steckverbinder
* Cat. 8.2 (nach ISO/IEC non RJ45): Bandbreite bis 2 GHz, rückwärtskompatibel bzw. aufbauend auf Cat. 7A (S/FTP) mit Tera-, GG45- oder ARJ45-Steckverbinder

Ergänzung: Nur die Komponenten mit Cat. 8.2 bieten die volle Abwärtskompatibilität zu Cat. 7/7A und darunter. Komponenten mit Cat. 8.1 arbeiten nur mit Cat. 6/6A und darunter zusammen. Aber nicht mit Komponenten mit Cat. 7/7A.
Wichtig ist auch, dass man bei Cat. 8.2 GG45-Steckverbindungen verwendet, weil in die GG45-Buchse auch Patchkabel mit RJ45-Steckverbinder passen.
Steckverbinder für TP-Kabel

Die Steckverbindung bzw. der Steckverbinder für Twisted-Pair-Kabel ist eine Stecker-Buchse-Kombination. Die Buchse befindet sich typischerweise an festgelegten Komponenten der Verkabelung. Also Verteilfelder, Anschlussdosen und Endgeräten. Der Stecker befindet sich an den Endungen von beweglichen Kabeln, wie Patchkabel.
Typischerweise werden RJ45-Steckverbinder für Twisted-Pair-Kabel verwendet.

'''Glasfaser'''
* Alternative für eine zukunftssichere und leistungsstarke Verkabelung
* Netzwerk-Geräte lassen nicht mit Strom versorgen

Selbst in Rechenzentren reicht die Geschwindigkeit auf Twisted-Pair als die preisgünstigere Technik für die Verkabelung von Routern, 
Switchen und Servern in den Schaltschränken aus. 
Ganz anders sieht es natürlich im Bereich von High Performance Computing und bei den Netzbetreibern aus. 
Hier setzt man generell mehr Glasfaser ein, weil die Anforderungen an die Übertragungsleistung hier viel schneller steigen und technisch bedingt auch nur von Glasfaser bedient werden kann.

== Installation von Netzwerkkabeln ==

* Zentrale Elemente einer Verkabelung, sind geschirmte Leitungen und Buchsen, sowie Spezialwerkzeug für die Installation.
* Netzwerkkabel sind grundsätzlich mit äußerster Sorgfalt zu behandeln und nur in trockenen Räumen zu lagern und zu installieren.
* Quetschen, zu starker Druck und Zug sind zu vermeiden, weil es die Qualität und physikalische Eigenschaft der Netzwerkkabel verringern kann.
* Kanten auf der Verlegestrecke müssen geglättet werden. Biegeradius des Herstellers sind einhalten, damit die Eigenschaften des Netzwerkkabels nicht beeinflusst werden.
* Die Netzwerkkabel sollten direkt von der Kabeltrommel oder Kabelrolle abgerollt oder gezogen und nicht abgewickelt (Veränderung des Kabelaufbaus) werden.
* Netzwerkkabel sind getrennt von Stromkabeln in einem Kabelkanal zu verlegen. Zum Beispiel durch einen Trennsteg.
* Beim Auflegen sind die verdrillten Adern von Twisted-Pair-Kabel nicht zu weit zu öffnen und auch nicht mehr nach zu verdrillen, sonst bekommt die Kabelstrecke schlechte Werte bei der NEXT-Messung.
* Das geschirmte Leitungsnetz und alle metallischen Komponenten sind in den Potentialausgleich des Gebäudes einzubeziehen.

==Quellen==
# https://www.elektronik-kompendium.de

[[Category:Netzwerke]]

Netzwerkverkabelung

2020-10-05T16:17:15Z

Meikschwalm: /* Externe Links */

== Netzwerk-Kabel ==

Mit Netzwerkkabel werden die Stationen bzw. Teilnehmer eines Netzwerks physikalisch miteinander verbunden. 
Es gibt verschiedene Netzwerkkabel. Sie unterscheiden sich im Material und im Aufbau. 
Während es Kupferkabel entweder als Twisted-Pair-Kabel oder Koaxialkabel gibt, bestehen Lichtwellenleiter aus dem Grundstoff Glas oder Kunststoff.

=== Passive Anschlusskomponenten einer Netzwerk-Verkabelung ===

* Anschlussdosen (Anschlusseinheiten)
* Rangierverteiler (Patch-Panels)
* Rangierkabel (Patch-Kabel)

=== Patchfeld und Patchkabel ===

Patchkabel sind die bevorzugten Kabel, um Patchfelder und Anschlussdosen mit den Netzwerkstationen und aktiven Netzwerk-Komponenten zu verbinden. 
Patchfelder sind Vorrichtungen, an denen die Netzwerkleitungen ankommen. 

=== Glasfaser oder Twisted-Pair-Kabel? ===

'''Twisted-Pair-Kabel'''
* maximale Datenrate
1GBit/s Cat. 5e, 6 (bis 100 Meter) 
10GBit/s Cat. 6A (bis 55 Meter) 
10GBit/s Cat. 7 (bis 100 Meter) 
40GBit/s Cat. 8 (bis 30 Meter) 
* leichter handhabbar als Glasfaser
* für die meisten Geräte und Anwendungen vollkommen ausreichend
* Netzwerk-Geräte lassen sich mit Strom versorgen (Power over Ethernet (PoE))
* Verkabelung von Routern, Switchen, Servern sowie verschiedene Endgeräte 

'''Welche Kategorie bzw. Klasse sollte man wählen?'''

Der typische Anwendungsfall für Twisted-Pair-Kabel sieht die Arbeitsplatzverkabelung in Büros und in Wohnhäusern vor. 
Bei einer rationalen Betrachtung liegt die Schlussfolgerung nahe, dass hier keine strukturierte Verkabelung notwendig ist, 
die über die Kategorie 6A oder die Klasse EA hinausgeht. Selbst wenn die Verkabelung zukünftigen Anforderungen genügen soll, 
sind Kabel der Kategorien 5 und 6 vollkommen ausreichend. Es gibt selten einen Grund alte CAT5- oder CAT6-Verkabelungen auszutauschen. 
Selbst in einem Rechenzentrum sind TP-Verkabelungen der Kategorie 8 äußerst fraglich. Leitungslängen von maximal 30 m können bei größeren Rechenzentren einfach nicht ausreichen.

'''CAT5-Kabel''' 
sind wahrscheinlich die am häufigsten verlegten Netzwerkkabel und somit in den meisten älteren strukturierten Netzwerk-Verkabelungen anzutreffen. 
In der Regel werden sie für die parallele Nutzung von Netzwerk und Telefonie eingesetzt. 
CAT5-Kabel sind für Ethernet, Fast-, Gigabit-Ethernet und in Ausnahmefällen auch für 10-Gigabit-Ethernet geeignet.
Für Gigabit-Ethernet musste die Spezifikation überarbeiten werden. Die Kabel wurden mit Category 5e (e = enhanced) bezeichnet. 
CAT5e ist genauer spezifiziert und kommt vor allem in Europa zum Einsatz. 
Umsichtig verlegte CAT5-Leitungen profitieren davon, dass sie nach der Messung meistens die Anforderungen für CAT5e erfüllen.
Seit der Normung im Jahr 2003 gilt für CAT5e nur noch die Bezeichnung CAT5. Die davor verlegten CAT5-Kabel unterstützen Gigabit-Ethernet nicht immer.
Twisted-Pair-Kabel der Category 6 / Kategorie 6 (Class E)

'''CAT6-Kabel''' 
sind in den neueren strukturierten Netzwerk-Verkabelungen anzutreffen. 
Für die Verlegung von CAT6-Kabel gibt es meistens keinen wirklichen Grund. Im Bereich Ethernet mit 1 GBit/s reicht CAT5 (CAT5e) oft aus. 
Eine bessere Qualität als CAT6 ist eigentlich nicht notwendig. 
Deshalb dauerte es lange, bis CAT6-Kabel für strukturierte Verkabelungen eingesetzt wurden. Irgendwann wurden häufiger CAT6-Kabel als CAT5-Kabel verlegt. 
Sie waren einfach besser lieferbar. 
Außerdem bemerkte so mancher Elektroinstallateur, dass man mit einem "reingeklatschten" CAT6-Kabel bessere Messwerte erreichen kann, als bei einem umsichtig verlegten CAT5-Kabel. 
Vor allem, wenn das eine oder andere Kabel länger wurde, als es eigentlich sein durfte. Nacharbeiten und Diskussionen mit dem Kunden konnten vermieden werden.
Im Vergleich zu CAT5-Kabel enthalten CAT6-Kabel dickere Adern und mehr Folien- und Geflecht-Schirmung. 
Vor allem beim Abisolieren und Auflegen an Dosen und Patchfeldern entsteht wegen der Schirmung ein größerer Aufwand, der für geübte Installateure vernachlässigbar ist.
Eine Erweiterung von CAT6 ist CAT6A bzw. CAT6A.

'''CAT6A''' 
Mit 10-Gigabit-Ethernet (10GBASE-T) wurden Twisted-Pair-Kabel mit dem Standard CAT6A (A = augmented) spezifiziert, der für Frequenzen bis zu 500 MHz ausgelegt ist. 
CAT6A-Kabel enthielten anfangs Trennstege, um die Adernpaare räumlich voneinander zu trennen. 
Auf diese Weise soll das Übersprechen reduziert werden. 
Allerdings gehen damit ein größerer Kabeldurchmesser und ein größerer Biegeradius einher, wodurch sich die Kabel schwerer verlegen lassen.
Bei 10GBASE-T erreicht man mit diesen Kabeln eine maximale Entfernung von 55 Metern. 
Zusätzlich benötigt man Patchpanels, die den Abstand zwischen den einzelnen Anschlüssen erhöhen, geschirmte RJ45-Stecker, Spezialwerkzeug für die Konfektionierung, geschlossene Kabeltrassen und die Trennung unterschiedlicher Kabelarten, um gegenseitige Beeinflussungen zu vermeiden. 
 
'''Twisted-Pair-Kabel der Category 7 / Kategorie 7 (Class F)''' 
Spätestens bei 10-Gigabit-Ethernet sind Kabel der Kategorie 7 notwendig (oder CAT6A). 
Da diese Technik als zukunftsweisend gilt und die Kabel nicht sehr viel teurer sind als CAT6-Kabel, werden viele Neuinstallationen mit CAT7-Kabel ausgerüstet. 
Die Kategorie 7A ist sogar bis 1000 MHz spezifiziert und wurde für Anwendungen ausgearbeitet, die über 10 GBit/s hinausgehen. 
Im Unterschied zu den Kabeln der Kategorie 5 und 6 sind alle vier Adernpaare eines CAT7-Kabels einzeln geschirmt. 
Das bedeutet, es kommen generell Folien- und Geflecht-geschirmte Kabel zum Einsatz. 
Ungeschirmte UTP-Kabel sind in der Kategorie 7 möglich, aber in der Praxis eher selten anzutreffen. 
Es werden hauptsächlich S/FTP-Kabel verwendet.
Hinzu kommen neue Steckverbinder. 
Der Grund, die Abstände zwischen den RJ45-Steckern ist zu gering. Eine Verkabelung mit RJ45-Patchkabeln und -dosen und CAT7-Kabel ist also keine "echte" CAT7-Verkabelung, sondern höchstens CAT6A. 
 

In der Vergangenheit haben viele Elektroinstallateure die nötige Sorgfalt beim Verlegen von CAT6- und CAT7-Kabel vermissen lassen. 
Darauf angesprochen wurde meist nur milde gelächelt und abgewunken. 
Natürlich, auf einem schlecht behandelten CAT7-Kabel ist Fast-Ethernet mit 100 MBit/s auch kein Problem. 
Doch wer lässt CAT7-Kabel verlegen, um es nur für Fast-Ethernet zu nutzen? 
Was ist, wenn jemand 10GBase-T auf CAT7 nutzen will? Abwegig ist das nicht. 
Zwar werden mit 10GBase-T kaum Arbeitsplatzrechner ans Netzwerk angebunden. 
Doch lässt sich mit 10GBase-T eine schnelle Netzwerk-Infrastruktur aufbauen, die ohne teure Glasfaserkabel auskommt.
Der Elektroinstallateur muss dringend davon Abstand nehmen CAT6- und CAT7-Kabel auf die Schnelle "reinzuklatschen". 
Das zeugt von geringer Fachkenntnis und ist Pfusch.

Der wesentliche Unterschied zwischen CAT7- und CAT7A-Kabel ist der einsetzbare Frequenzbereich von 600 bzw. 1.000 MHz.

'''Wichtiger Hinweis:''' Leider werden für qualitativ hochwertige Netzwerkverkabelungen mit CAT7-Leitung 
oftmals CAT6-Netzwerkdosen und -Patchpanels verbaut, was die gesamte Verkabelung auf CAT6 degradiert. 
Alle CAT7-Patchkabel, -Patchfelder und Anschlussdosen mit RJ45-Steckverbindern entsprechen nicht der CAT7-Spezifikation. 
Das bedeutet, eine Netzwerkinstallation mit CAT7-Kabel und RJ45-Steckverbindungen ist höchstens eine CAT6A-Netzwerkinstallation. 
Um Netzwerkkomponenten gemäß CAT7 herzustellen, wurden eigens neue Steckverbindungen konzipiert, die im Wesentlichen den Abstand zwischen den Adernpaaren vergrößern. 

'''Twisted-Pair-Kabel der Category 8 / Kategorie 8''' 

Eigentlich müsste mit der Kategorie 7 Schluss sein. 
Der nächste Schritt wäre Glasfaserkabel auch im Tertiärbereich, auf den letzten hundert Metern zum Arbeitsplatz. 
Doch Kupferkabel haben gegenüber Lichtwellenleitern (LWL) signifikante Vorteile. 
So fallen die Gesamtkosten einer Verkabelung geringer aus, die Handhabung ist wesentlich leichter und zudem gesellt sich die PoE-Fähigkeit (Power over Ethernet) von Twisted-Pair-Kabeln hinzu. 

Eine Reichweite von 100 Meter kann nicht in jedem Fall erreicht werden. 
Deshalb begnügt man sich mit 30 Meter bei 2.000 MHz Bandbreite um damit 40 GBit/s (oder auch mehr) zu erreichen. 
Der eigentliche Grund der Leitungslängenbegrenzung liegt darin, den Energiebedarf der 40GBase-T-Chipsätze in Grenzen zu halten. 

'''Bei Kategorie 8 muss man zwischen mehreren Kategorien unterschieden:'''

Cat. 8 (nach ANSI/TIA): Bandbreite bis 2 GHz, rückwärtskompatibel bzw. aufbauend auf Cat. 6A (F/UTP) mit RJ45-Steckverbinder
Cat. 8.1 (nach ISO/IEC RJ45): Bandbreite bis 2 GHz, rückwärtskompatibel bzw. aufbauend auf Cat. 6A (F/UTP) mit RJ45-Steckverbinder
Cat. 8.2 (nach ISO/IEC non RJ45): Bandbreite bis 2 GHz, rückwärtskompatibel bzw. aufbauend auf Cat. 7A (S/FTP) mit Tera-, GG45- oder ARJ45-Steckverbinder

Ergänzung: Nur die Komponenten mit Cat. 8.2 bieten die volle Abwärtskompatibilität zu Cat. 7/7A und darunter. Komponenten mit Cat. 8.1 arbeiten nur mit Cat. 6/6A und darunter zusammen. Aber nicht mit Komponenten mit Cat. 7/7A.
Wichtig ist auch, dass man bei Cat. 8.2 GG45-Steckverbindungen verwendet, weil in die GG45-Buchse auch Patchkabel mit RJ45-Steckverbinder passen.
Steckverbinder für TP-Kabel

Die Steckverbindung bzw. der Steckverbinder für Twisted-Pair-Kabel ist eine Stecker-Buchse-Kombination. Die Buchse befindet sich typischerweise an festgelegten Komponenten der Verkabelung. Also Verteilfelder, Anschlussdosen und Endgeräten. Der Stecker befindet sich an den Endungen von beweglichen Kabeln, wie Patchkabel.
Typischerweise werden RJ45-Steckverbinder für Twisted-Pair-Kabel verwendet.

'''Glasfaser'''
* Alternative für eine zukunftssichere und leistungsstarke Verkabelung
* Netzwerk-Geräte lassen nicht mit Strom versorgen

Selbst in Rechenzentren reicht die Geschwindigkeit auf Twisted-Pair als die preisgünstigere Technik für die Verkabelung von Routern, 
Switchen und Servern in den Schaltschränken aus. 
Ganz anders sieht es natürlich im Bereich von High Performance Computing und bei den Netzbetreibern aus. 
Hier setzt man generell mehr Glasfaser ein, weil die Anforderungen an die Übertragungsleistung hier viel schneller steigen und technisch bedingt auch nur von Glasfaser bedient werden kann.

== Installation von Netzwerkkabeln ==

* Zentrale Elemente einer Verkabelung, sind geschirmte Leitungen und Buchsen, sowie Spezialwerkzeug für die Installation.
* Netzwerkkabel sind grundsätzlich mit äußerster Sorgfalt zu behandeln und nur in trockenen Räumen zu lagern und zu installieren.
* Quetschen, zu starker Druck und Zug sind zu vermeiden, weil es die Qualität und physikalische Eigenschaft der Netzwerkkabel verringern kann.
* Kanten auf der Verlegestrecke müssen geglättet werden. Biegeradius des Herstellers sind einhalten, damit die Eigenschaften des Netzwerkkabels nicht beeinflusst werden.
* Die Netzwerkkabel sollten direkt von der Kabeltrommel oder Kabelrolle abgerollt oder gezogen und nicht abgewickelt (Veränderung des Kabelaufbaus) werden.
* Netzwerkkabel sind getrennt von Stromkabeln in einem Kabelkanal zu verlegen. Zum Beispiel durch einen Trennsteg.
* Beim Auflegen sind die verdrillten Adern von Twisted-Pair-Kabel nicht zu weit zu öffnen und auch nicht mehr nach zu verdrillen, sonst bekommt die Kabelstrecke schlechte Werte bei der NEXT-Messung.
* Das geschirmte Leitungsnetz und alle metallischen Komponenten sind in den Potentialausgleich des Gebäudes einzubeziehen.

==Quellen==
# https://www.elektronik-kompendium.de

[[Category:Netzwerke]]

Netzwerkverkabelung

2020-10-05T16:16:41Z

Meikschwalm: Die Seite wurde neu angelegt: „== Netzwerk-Kabel == Mit Netzwerkkabel werden die Stationen bzw. Teilnehmer eines Netzwerks physikalisch miteinander verbunden. Es gibt verschiedene Netz…“

== Netzwerk-Kabel ==

Mit Netzwerkkabel werden die Stationen bzw. Teilnehmer eines Netzwerks physikalisch miteinander verbunden. 
Es gibt verschiedene Netzwerkkabel. Sie unterscheiden sich im Material und im Aufbau. 
Während es Kupferkabel entweder als Twisted-Pair-Kabel oder Koaxialkabel gibt, bestehen Lichtwellenleiter aus dem Grundstoff Glas oder Kunststoff.

=== Passive Anschlusskomponenten einer Netzwerk-Verkabelung ===

* Anschlussdosen (Anschlusseinheiten)
* Rangierverteiler (Patch-Panels)
* Rangierkabel (Patch-Kabel)

=== Patchfeld und Patchkabel ===

Patchkabel sind die bevorzugten Kabel, um Patchfelder und Anschlussdosen mit den Netzwerkstationen und aktiven Netzwerk-Komponenten zu verbinden. 
Patchfelder sind Vorrichtungen, an denen die Netzwerkleitungen ankommen. 

=== Glasfaser oder Twisted-Pair-Kabel? ===

'''Twisted-Pair-Kabel'''
* maximale Datenrate
1GBit/s Cat. 5e, 6 (bis 100 Meter) 
10GBit/s Cat. 6A (bis 55 Meter) 
10GBit/s Cat. 7 (bis 100 Meter) 
40GBit/s Cat. 8 (bis 30 Meter) 
* leichter handhabbar als Glasfaser
* für die meisten Geräte und Anwendungen vollkommen ausreichend
* Netzwerk-Geräte lassen sich mit Strom versorgen (Power over Ethernet (PoE))
* Verkabelung von Routern, Switchen, Servern sowie verschiedene Endgeräte 

'''Welche Kategorie bzw. Klasse sollte man wählen?'''

Der typische Anwendungsfall für Twisted-Pair-Kabel sieht die Arbeitsplatzverkabelung in Büros und in Wohnhäusern vor. 
Bei einer rationalen Betrachtung liegt die Schlussfolgerung nahe, dass hier keine strukturierte Verkabelung notwendig ist, 
die über die Kategorie 6A oder die Klasse EA hinausgeht. Selbst wenn die Verkabelung zukünftigen Anforderungen genügen soll, 
sind Kabel der Kategorien 5 und 6 vollkommen ausreichend. Es gibt selten einen Grund alte CAT5- oder CAT6-Verkabelungen auszutauschen. 
Selbst in einem Rechenzentrum sind TP-Verkabelungen der Kategorie 8 äußerst fraglich. Leitungslängen von maximal 30 m können bei größeren Rechenzentren einfach nicht ausreichen.

'''CAT5-Kabel''' 
sind wahrscheinlich die am häufigsten verlegten Netzwerkkabel und somit in den meisten älteren strukturierten Netzwerk-Verkabelungen anzutreffen. 
In der Regel werden sie für die parallele Nutzung von Netzwerk und Telefonie eingesetzt. 
CAT5-Kabel sind für Ethernet, Fast-, Gigabit-Ethernet und in Ausnahmefällen auch für 10-Gigabit-Ethernet geeignet.
Für Gigabit-Ethernet musste die Spezifikation überarbeiten werden. Die Kabel wurden mit Category 5e (e = enhanced) bezeichnet. 
CAT5e ist genauer spezifiziert und kommt vor allem in Europa zum Einsatz. 
Umsichtig verlegte CAT5-Leitungen profitieren davon, dass sie nach der Messung meistens die Anforderungen für CAT5e erfüllen.
Seit der Normung im Jahr 2003 gilt für CAT5e nur noch die Bezeichnung CAT5. Die davor verlegten CAT5-Kabel unterstützen Gigabit-Ethernet nicht immer.
Twisted-Pair-Kabel der Category 6 / Kategorie 6 (Class E)

'''CAT6-Kabel''' 
sind in den neueren strukturierten Netzwerk-Verkabelungen anzutreffen. 
Für die Verlegung von CAT6-Kabel gibt es meistens keinen wirklichen Grund. Im Bereich Ethernet mit 1 GBit/s reicht CAT5 (CAT5e) oft aus. 
Eine bessere Qualität als CAT6 ist eigentlich nicht notwendig. 
Deshalb dauerte es lange, bis CAT6-Kabel für strukturierte Verkabelungen eingesetzt wurden. Irgendwann wurden häufiger CAT6-Kabel als CAT5-Kabel verlegt. 
Sie waren einfach besser lieferbar. 
Außerdem bemerkte so mancher Elektroinstallateur, dass man mit einem "reingeklatschten" CAT6-Kabel bessere Messwerte erreichen kann, als bei einem umsichtig verlegten CAT5-Kabel. 
Vor allem, wenn das eine oder andere Kabel länger wurde, als es eigentlich sein durfte. Nacharbeiten und Diskussionen mit dem Kunden konnten vermieden werden.
Im Vergleich zu CAT5-Kabel enthalten CAT6-Kabel dickere Adern und mehr Folien- und Geflecht-Schirmung. 
Vor allem beim Abisolieren und Auflegen an Dosen und Patchfeldern entsteht wegen der Schirmung ein größerer Aufwand, der für geübte Installateure vernachlässigbar ist.
Eine Erweiterung von CAT6 ist CAT6A bzw. CAT6A.

'''CAT6A''' 
Mit 10-Gigabit-Ethernet (10GBASE-T) wurden Twisted-Pair-Kabel mit dem Standard CAT6A (A = augmented) spezifiziert, der für Frequenzen bis zu 500 MHz ausgelegt ist. 
CAT6A-Kabel enthielten anfangs Trennstege, um die Adernpaare räumlich voneinander zu trennen. 
Auf diese Weise soll das Übersprechen reduziert werden. 
Allerdings gehen damit ein größerer Kabeldurchmesser und ein größerer Biegeradius einher, wodurch sich die Kabel schwerer verlegen lassen.
Bei 10GBASE-T erreicht man mit diesen Kabeln eine maximale Entfernung von 55 Metern. 
Zusätzlich benötigt man Patchpanels, die den Abstand zwischen den einzelnen Anschlüssen erhöhen, geschirmte RJ45-Stecker, Spezialwerkzeug für die Konfektionierung, geschlossene Kabeltrassen und die Trennung unterschiedlicher Kabelarten, um gegenseitige Beeinflussungen zu vermeiden. 
 
'''Twisted-Pair-Kabel der Category 7 / Kategorie 7 (Class F)''' 
Spätestens bei 10-Gigabit-Ethernet sind Kabel der Kategorie 7 notwendig (oder CAT6A). 
Da diese Technik als zukunftsweisend gilt und die Kabel nicht sehr viel teurer sind als CAT6-Kabel, werden viele Neuinstallationen mit CAT7-Kabel ausgerüstet. 
Die Kategorie 7A ist sogar bis 1000 MHz spezifiziert und wurde für Anwendungen ausgearbeitet, die über 10 GBit/s hinausgehen. 
Im Unterschied zu den Kabeln der Kategorie 5 und 6 sind alle vier Adernpaare eines CAT7-Kabels einzeln geschirmt. 
Das bedeutet, es kommen generell Folien- und Geflecht-geschirmte Kabel zum Einsatz. 
Ungeschirmte UTP-Kabel sind in der Kategorie 7 möglich, aber in der Praxis eher selten anzutreffen. 
Es werden hauptsächlich S/FTP-Kabel verwendet.
Hinzu kommen neue Steckverbinder. 
Der Grund, die Abstände zwischen den RJ45-Steckern ist zu gering. Eine Verkabelung mit RJ45-Patchkabeln und -dosen und CAT7-Kabel ist also keine "echte" CAT7-Verkabelung, sondern höchstens CAT6A. 
 

In der Vergangenheit haben viele Elektroinstallateure die nötige Sorgfalt beim Verlegen von CAT6- und CAT7-Kabel vermissen lassen. 
Darauf angesprochen wurde meist nur milde gelächelt und abgewunken. 
Natürlich, auf einem schlecht behandelten CAT7-Kabel ist Fast-Ethernet mit 100 MBit/s auch kein Problem. 
Doch wer lässt CAT7-Kabel verlegen, um es nur für Fast-Ethernet zu nutzen? 
Was ist, wenn jemand 10GBase-T auf CAT7 nutzen will? Abwegig ist das nicht. 
Zwar werden mit 10GBase-T kaum Arbeitsplatzrechner ans Netzwerk angebunden. 
Doch lässt sich mit 10GBase-T eine schnelle Netzwerk-Infrastruktur aufbauen, die ohne teure Glasfaserkabel auskommt.
Der Elektroinstallateur muss dringend davon Abstand nehmen CAT6- und CAT7-Kabel auf die Schnelle "reinzuklatschen". 
Das zeugt von geringer Fachkenntnis und ist Pfusch.

Der wesentliche Unterschied zwischen CAT7- und CAT7A-Kabel ist der einsetzbare Frequenzbereich von 600 bzw. 1.000 MHz.

'''Wichtiger Hinweis:''' Leider werden für qualitativ hochwertige Netzwerkverkabelungen mit CAT7-Leitung 
oftmals CAT6-Netzwerkdosen und -Patchpanels verbaut, was die gesamte Verkabelung auf CAT6 degradiert. 
Alle CAT7-Patchkabel, -Patchfelder und Anschlussdosen mit RJ45-Steckverbindern entsprechen nicht der CAT7-Spezifikation. 
Das bedeutet, eine Netzwerkinstallation mit CAT7-Kabel und RJ45-Steckverbindungen ist höchstens eine CAT6A-Netzwerkinstallation. 
Um Netzwerkkomponenten gemäß CAT7 herzustellen, wurden eigens neue Steckverbindungen konzipiert, die im Wesentlichen den Abstand zwischen den Adernpaaren vergrößern. 

'''Twisted-Pair-Kabel der Category 8 / Kategorie 8''' 

Eigentlich müsste mit der Kategorie 7 Schluss sein. 
Der nächste Schritt wäre Glasfaserkabel auch im Tertiärbereich, auf den letzten hundert Metern zum Arbeitsplatz. 
Doch Kupferkabel haben gegenüber Lichtwellenleitern (LWL) signifikante Vorteile. 
So fallen die Gesamtkosten einer Verkabelung geringer aus, die Handhabung ist wesentlich leichter und zudem gesellt sich die PoE-Fähigkeit (Power over Ethernet) von Twisted-Pair-Kabeln hinzu. 

Eine Reichweite von 100 Meter kann nicht in jedem Fall erreicht werden. 
Deshalb begnügt man sich mit 30 Meter bei 2.000 MHz Bandbreite um damit 40 GBit/s (oder auch mehr) zu erreichen. 
Der eigentliche Grund der Leitungslängenbegrenzung liegt darin, den Energiebedarf der 40GBase-T-Chipsätze in Grenzen zu halten. 

'''Bei Kategorie 8 muss man zwischen mehreren Kategorien unterschieden:'''

Cat. 8 (nach ANSI/TIA): Bandbreite bis 2 GHz, rückwärtskompatibel bzw. aufbauend auf Cat. 6A (F/UTP) mit RJ45-Steckverbinder
Cat. 8.1 (nach ISO/IEC RJ45): Bandbreite bis 2 GHz, rückwärtskompatibel bzw. aufbauend auf Cat. 6A (F/UTP) mit RJ45-Steckverbinder
Cat. 8.2 (nach ISO/IEC non RJ45): Bandbreite bis 2 GHz, rückwärtskompatibel bzw. aufbauend auf Cat. 7A (S/FTP) mit Tera-, GG45- oder ARJ45-Steckverbinder

Ergänzung: Nur die Komponenten mit Cat. 8.2 bieten die volle Abwärtskompatibilität zu Cat. 7/7A und darunter. Komponenten mit Cat. 8.1 arbeiten nur mit Cat. 6/6A und darunter zusammen. Aber nicht mit Komponenten mit Cat. 7/7A.
Wichtig ist auch, dass man bei Cat. 8.2 GG45-Steckverbindungen verwendet, weil in die GG45-Buchse auch Patchkabel mit RJ45-Steckverbinder passen.
Steckverbinder für TP-Kabel

Die Steckverbindung bzw. der Steckverbinder für Twisted-Pair-Kabel ist eine Stecker-Buchse-Kombination. Die Buchse befindet sich typischerweise an festgelegten Komponenten der Verkabelung. Also Verteilfelder, Anschlussdosen und Endgeräten. Der Stecker befindet sich an den Endungen von beweglichen Kabeln, wie Patchkabel.
Typischerweise werden RJ45-Steckverbinder für Twisted-Pair-Kabel verwendet.

'''Glasfaser'''
* Alternative für eine zukunftssichere und leistungsstarke Verkabelung
* Netzwerk-Geräte lassen nicht mit Strom versorgen

Selbst in Rechenzentren reicht die Geschwindigkeit auf Twisted-Pair als die preisgünstigere Technik für die Verkabelung von Routern, 
Switchen und Servern in den Schaltschränken aus. 
Ganz anders sieht es natürlich im Bereich von High Performance Computing und bei den Netzbetreibern aus. 
Hier setzt man generell mehr Glasfaser ein, weil die Anforderungen an die Übertragungsleistung hier viel schneller steigen und technisch bedingt auch nur von Glasfaser bedient werden kann.

== Installation von Netzwerkkabeln ==

* Zentrale Elemente einer Verkabelung, sind geschirmte Leitungen und Buchsen, sowie Spezialwerkzeug für die Installation.
* Netzwerkkabel sind grundsätzlich mit äußerster Sorgfalt zu behandeln und nur in trockenen Räumen zu lagern und zu installieren.
* Quetschen, zu starker Druck und Zug sind zu vermeiden, weil es die Qualität und physikalische Eigenschaft der Netzwerkkabel verringern kann.
* Kanten auf der Verlegestrecke müssen geglättet werden. Biegeradius des Herstellers sind einhalten, damit die Eigenschaften des Netzwerkkabels nicht beeinflusst werden.
* Die Netzwerkkabel sollten direkt von der Kabeltrommel oder Kabelrolle abgerollt oder gezogen und nicht abgewickelt (Veränderung des Kabelaufbaus) werden.
* Netzwerkkabel sind getrennt von Stromkabeln in einem Kabelkanal zu verlegen. Zum Beispiel durch einen Trennsteg.
* Beim Auflegen sind die verdrillten Adern von Twisted-Pair-Kabel nicht zu weit zu öffnen und auch nicht mehr nach zu verdrillen, sonst bekommt die Kabelstrecke schlechte Werte bei der NEXT-Messung.
* Das geschirmte Leitungsnetz und alle metallischen Komponenten sind in den Potentialausgleich des Gebäudes einzubeziehen.

==Externe Links==
# https://www.elektronik-kompendium.de/sites/net/0510091.htm

[[Category:Netzwerke]]

Datei:Nfs bild1.png

2019-09-26T07:22:45Z

Meikschwalm:

Teams/Ab18it08/Netzwerkdokumentation

2019-09-18T07:09:49Z

Meikschwalm:

'''Router 0230'''

allow-hotplug enp2s0 
iface enp2s0 inet static 
address 10.20.0.2 
netmask 255.255.0.0 
gateway 10.20.0.1 

allow-hotplug enp5s0 
iface enp5s0 inet static 
address 10.20.20.1 
netmask 255.255.255.0 
gateway 10.20.20.1 

'''Router 0220'''

auto lo 
iface lo inet loopback 
allow-hotplug enp2s0 
iface enp2s0 inet static 
address 10.30.0.2 
netmask 255.255.0.0 
gateway 10.30.0.1 

allow-hotplug enp5s1 
iface enp5s1 inet static 
address 10.30.30.1 
netmask 255.255.255.0 
gateway 10.30.30.1 

'''Router 0210'''

'''Router 02'''

allow-hotplug enp0s6
iface enp0s6 inet static
address 10.0.0.2
netmask 255.0.0.0
gateway 10.0.0.1

#config 10.30.0.0 weiter ins 10.30.30.0
allow-hotplug enp1s6
iface enp1s6 inet static
address 10.30.0.1
netmask 255.255.0.0
post-up route add -net 10.30.30.0 netmask 255.255.255.0 gw 10.30.0.2

#config 10.10.0.0 weiter ins 10.10.10.0
allow-hotplug enp1s8
iface enp1s8 inet static
address 10.10.0.1
netmask 255.255.0.0
post-up route add -net 10.10.10.0 netmask 255.255.255.0 gw 10.10.0.2

#config 10.20.0.0 weiter ins 10.20.20.0
allow-hotplug enp1s9
iface enp1s9 inet static
address 10.20.0.1
netmask 255.255.0.0

'''OPNsense'''

ipv4 10.0.0.0/8 link#1
ipv4 10.0.0.1 link#1
ipv4 10.10.0.0/16 10.0.0.2
ipv4 10.10.10.0/24 10.0.0.2
ipv4 10.20.0.0/16 10.0.0.2
ipv4 10.20.20.0/24 10.0.0.2
ipv4 10.30.0.0/16 10.0.0.2
ipv4 10.30.30.0/24 10.0.0.2

Teams/Ab18it08/Netzwerkdokumentation

2019-09-18T07:01:05Z

Meikschwalm:

PuTTY/puttygen

2019-09-16T07:48:37Z

Meikschwalm: Meikschwalm verschob die Seite PuTTY - ein freier SSH-Client nach PuTTY - SSH-Client: Der alte Name war wohl nich so dolle

==Wozu dient PuTTY==
 
[[Datei:PuTTY_icon_128px.png|80px|left]]
:PuTTY ist eine freie Software zum Herstellen von Verbindungen über Secure Shell[https://wiki.itw-berlin.net/index.php?title=SSH_(secure_shell)].
Dabei dient PuTTY als Client und stellt die Verbindung zu einem Server her.
:Für Windows-Nutzer stellt Putty einen passenden Ersatz zur Linux-Shell dar.
 

==Authentifizierung==
[[Datei:Beispielbild PuTTY2.png|500px|thumb|left|Beispielbild]]
Im hier veranschaulichten Fenster werden die Verbindungsdaten(1,2) eingeben, sowie unter '''Saved Sessions (3)''' ein Profil anlegen um eine Session zu Speichern.

Anschließend stellt man mit '''Open(4)''' die Verbindung zum Server her.

Beim Verbindungsaufbau wird die Identität des Benutzers zur Authentifizierung überprüft.

In der nun bereitgestellten Terminalsitzung können direkt Befehle abgesetzt werden, die auf dem fernen System ausgeführt werden.
 
 
'''Hinweis:'''
Das Programm zum Download finden Sie unter https://www.putty.org/.
 Auf der PuTTY-Homepage www.chiark.greenend.org.uk finden Sie ausführliche FAQs und eine Dokumentation - ebenfalls in englischer Sprache.
 
[[Category:Netzwerk]]

LPIC102/110.3 Schlüsselerstellung mit GnuPG

2019-08-01T13:12:02Z

Meikschwalm:

===GnuPG===

* GNU Privacy Guard, kurz GPG
* Verschlüsselt und signiert Daten
* Asymmetrisches Verschlüsselungsverfahren (Public-Key)
* Öffentlicher Schlüssel = Verschlüsselungsschlüssel
* Privater Schlüssel = Entschlüsselungsschlüssel
* Privater Schlüssel wird beim generieren von Signaturen verwendet
* Der Schlüssel sollte also gut geschützt werden
* Schlüsselverschlüsselungsschlüssel (symmetrische Verschlüsselung anschließend mit einem asymmetrischen Schlüssel verschlüsseln)
* Grafische Benutzeroberflächen sind: GNU Privacy Assistant (GPA), für GNOME - Seahorse, und für KDE - KGpg

Beispiel anhand einer Mail:
* Übermittlung von Mails erfordert Verschlüsselung
* Ein SMTP-Server nimmt sich dieser Problematik nicht an
* Mails werden unverschlüsselt auf Server gespeichert
* Schlechter Sicherheitsstandard wie bei einer Postkarte
* Es gibt mehrere Mailprogramme, die GPG direkt oder indirekt über Plugins unterstützt
* Beispiele: Evolution, Mutt, Kmail, Thunderbird, Eudora, Enigmail, Apple Mail und sogar Microsoft Outlook
* Für die LPI-Prüfung müssen Sie natürlich nicht mit den Frontends arbeiten können
* sondern das Programm GPG selbst mit den dazugehörenden Dateien kennen
* Das Programm ist sehr umfangreich, wie ein Blick in die Manpage sofort verrät

Als erstes muss ein Schlüsselpaar mit gpg --gen-key generiert werden:

[[Category:Linux]]

LPIC102/110.3 SSH Authentifizierung mit Schlüsseln

2019-08-01T13:08:04Z

Meikschwalm:

==Authentifizierung der Server mit Schlüsseln==
* Server authentifiziert sich am Client mit seinem Hostkey
* Ist der Ziel-Host dem Client noch nicht bekannt, erfolgt eine Warnmeldung
* In der Meldung erscheint auch der Fingerprint des Hostkeys

[root@scientific /]# ssh uvm1.nwa-net.de
The authenticity of host
uvm1.nwa-net.de (176.95.26.236)' can't be established
ECDSA key fingerprint is SHA256:TbVCtl6TJHAHacrTdwh9gqzvx8fB5bzhi1lL/ByFbYE
ECDSA key fingerprint is MD5:c8:db:4a:6f:99:7a:e9:9d:ca:82:c7:36:99:ac:14:c9
Are you sure you want to continue connecting (yes/no)?

* Bestätigt man mit yes, wird der Hostkey des Servers in die Datei ''~./ssh/known_hosts'' des Benutzers eingetragen und die Verbindung hergestellt
* Bei späteren Anmeldungen entfällt entsprechend die Warnmeldung
* Folgendes Kommando zeigt eine Liste der bekannten Hosts

# ssh-keygen -l -f ~/.ssh/known_hosts
256 SHA256:VOrsAcZc//9EiAATV2DfSN2jHONQBEuJpyrmW+Q3CWQ
user,192.168.178.2 (ECDSA)
256 SHA256:TbVCtl6TJHAHacrTdwh9gqzvx8fB5bzhi1lL/ByFbYE
uvm1.nwa-net.de,176.95.26.236 (ECDSA)

* Ändert sich der Schlüssel eines Zielsystems, erfolgt die Warnmeldung

$ ssh scientific
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:r+9OEu2EM5ubr0P5wl4lLgUo5n/8/AkX2exIiPqQ9rs.
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /root/.ssh/known_hosts:15
ECDSA host key for scientific has changed and you have requested strict checking.
Host key verification failed.

* Bei einer echten man-in-the-middle-attack, Schlüssel aus der known_hosts-Datei entfernen und Verbindung neu aufbauen

* Die Datei ''/etc/ssh/ssh_known_hosts'' macht nichts anderes als die Datei ''~/.ssh/known_hosts'' für jeden Benutzer, nur eben am Client

==Hostkeys==

* OpenSSH erstellt in der Regel automatisch Hostkeys
* Sie dienen der Authentifizierung zwischen Server und Clientcomputer

ssh_host_dsa_key
ssh_host_dsa_key.pub
ssh_host_ecdsa_key
ssh_host_ecdsa_key.pub
ssh_host_ed25519_key
ssh_host_ed25519_key.pub
ssh_host_rsa_key
ssh_host_rsa_key.pub

* Ohne Dateierweiterung = privater Schlüssel
* Mit Erweiterung .pub = öffentlicher (public) Schlüssel
* Die Konfigurationsdatei dazu ist ''sshd_config''

Erläuterung zu den einzelnen Schlüsseldateien

* DSA: veraltet, bekannte Schwächen, wird nicht mehr unterstützt 
* ECDSA: Standard bei Linux-Distros, kleinere Schlüsselgrößen als etwa RSA, Verdacht gleiche Schwächen aufzuweisen wie DSA
* RSA: etablierter Standard, überall unterstützt, existiert seit 1977 
* Ed25519: ähnelt technisch ECDSA, weist jedoch nicht dieselbe Schwäche auf 
* Wird von sehr neuen SSH-Versionen unterstützt, empfiehlt sich daher nicht als Standalone-Lösung, wenn man auch ältere Clientsysteme im Einsatz hat 

* ''ssh-keygen'' generiert neue Schlüssel
* Optional die Pfadangabe des Users angeben
* Option ''–t'' legt den Typ des Schlüssels fest
* Zur Auswahl stehen rsa, dsa, ecdsa und ed25519

'''Beispiel:'''
* Erstellen eines neuen Schlüsselpaares für RSA
* Es wurde keine passphrase verwendet

# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
/etc/ssh/ssh_host_rsa_key
/etc/ssh/ssh_host_rsa_key already exists.
Overwrite (y/n)? y
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /etc/ssh/ssh_host_rsa_key.
Your public key has been saved in /etc/ssh/ssh_host_rsa_key.pub.
The key fingerprint is:
SHA256:zinmLbZLTBxcCOWN52QBDniQVAE9GfD/MuuQHzk3QQ4 root@scientific

* Generierte Datei ''ssh_host_rsa_key.pub'' enthält den öffentlichen Schlüssel des Systems
* Dieser lässt sich an Clients verteilen
* Datei ''ssh_host_rsa_key'' enthält privaten Schlüssel des Servers (geheim halten)

Folgende Kommandos können vom Clientsystem verwendet werden um den öffentlichen Schlüssel zu importieren

# scp scientific:/etc/ssh/ssh_host_rsa_key.pub ./
# cat ssh_host_rsa_key.pub >> /etc/ssh/ssh_known_hosts
# rm ssh_host_rsa_key.pub

==Benutzerauthentifizierung mit Schlüsseln==

* Hostkeys können auch zur Authentifizierung von Benutzern verwendet werden
* Verzichtet man auf ein Passwortes, lassen sich ''ssh'' oder ''scp'' in Skripten z. B. für Backups zu verwenden
* Generierung der Schlüssel ebenfalls mittels ''ssh-keygen''
* Schlüssel werden automatisch an der richtigen Stelle abgelegt

$ ssh-keygen -t ecdsa
Generating public/private ecdsa key pair.
Enter file in which to save the key (/home/harald/.ssh/id_ecdsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/harald/.ssh/id_ecdsa.
Your public key has been saved in /home/harald/.ssh/id_ecdsa.pub.
The key fingerprint is:
SHA256:Br+8SdXitm/XnUmqVQB1/+aO0HkJKsrbAjzvTwV8FNI user@10.0.0.1

* Der Schlüssel wurde ohne passphrase erstellt und muss jetzt auf die Zielsysteme verteilt werden
* Dafür verwendet man das komfortable Tool ''ssh-copy-id''

$ ssh-copy-id user
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed:
"/home/harald/.ssh/id_ecdsa.pub"
The authenticity of host 'archangel (192.168.178.2)' can't be established.
ECDSA key fingerprint is SHA256:VOrsAcZc//9EiAATV2DfSN2jHONQBEuJpyrmW+Q3CWQ.
ECDSA key fingerprint is MD5:8d:28:e5:f1:3b:e2:fd:69:cf:28:d9:06:5e:30:f3:30.
Are you sure you want to continue connecting (yes/no)? yes
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s),
to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are
prompted now it is to install the new keys

* Der Schlüssel wurde in die Datei ''~/.ssh/authorized_keys'' des Zielsystems (user) eingetragen und muss nun bei weiteren Anmeldungen nicht mehr angegeben werden
* Die Schlüsseldateien befinden sich im Verzeichnis ''~/.ssh'' eines Benutzers und lauten auf diese Dateinamen

id_rsa
id_rsa.pub
id_dsa
id_dsa.pub
id_ecdsa
id_ecdsa.pub
id_ed25519
id_ed25519.pub

* Die Dateinamen zu den Schlüsseln sind im Unterkapitel Hostkeys beschrieben
* Für die Authentifizierung wird nur ein Schlüsselpaar benötigt
* Server und Client Schlüsseltyp müssen natürlich identisch sein

==Der Authentifizierungsagent==

* Der SSH-Agent ist eine weitere Möglichkeit ohne Passwörter Authentifizierungen auszuführen
* Es lassen sich mehrere Schlüssel für einen Benutzer verwalten
* Dafür muss er bei der Startphase von X ausgeführt werden
* ''ssh-add'' kann dem SSH-Agent Schlüssel hinzufügen
* Ohne Optionen sucht das Programm automatisch nach
''~/.ssh/id_rsa, ~/.ssh/id_dsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ed25519 und ~/.ssh/identity.''

''Wichtige Optionen sind:''

-l – listet die Fingerabdrücke der verfügbaren Schlüssel auf
-d – entfernt einen einzelnen (angegebenen) Schlüssel vom Agenten
-D – entfernt alle Schlüssel vom Agenten
-s – liest Schlüssel von einer Smartcard
-e – entfernt Schlüssel der Smartcard
-x – sperrt den Agenten (mit Passwortschutz)
-X – entsperrt den Agenten

#WEITERLEITUNG [[110.3 Schlüsselerstellung mit GnuPG]]

[[Category:Linux]]

[[Benutzer:Meikschwalm|Meikschwalm]] ([[Benutzer Diskussion:Meikschwalm|Diskussion]]) 21:38, 29. Jul. 2019 (CEST)

LPIC102/110.3 SSH Authentifizierung mit Schlüsseln

2019-08-01T12:51:42Z

Meikschwalm: /* Authentifizierung der Server mit Schlüsseln */

==Authentifizierung der Server mit Schlüsseln==
* Server authentifiziert sich am Client mit seinem Hostkey
* Ist der Ziel-Host dem Client noch nicht bekannt, erfolgt eine Warnmeldung
* In der Meldung erscheint auch der Fingerprint des Hostkeys

[root@scientific /]# ssh uvm1.nwa-net.de
The authenticity of host
uvm1.nwa-net.de (176.95.26.236)' can't be established
ECDSA key fingerprint is SHA256:TbVCtl6TJHAHacrTdwh9gqzvx8fB5bzhi1lL/ByFbYE
ECDSA key fingerprint is MD5:c8:db:4a:6f:99:7a:e9:9d:ca:82:c7:36:99:ac:14:c9
Are you sure you want to continue connecting (yes/no)?

* Bestätigt man mit yes, wird der Hostkey des Servers in die Datei ''~./ssh/known_hosts'' des Benutzers eingetragen und die Verbindung hergestellt
* Bei späteren Anmeldungen entfällt entsprechend die Warnmeldung
* Folgendes Kommando zeigt eine Liste der bekannten Hosts

# ssh-keygen -l -f ~/.ssh/known_hosts
256 SHA256:VOrsAcZc//9EiAATV2DfSN2jHONQBEuJpyrmW+Q3CWQ
user,192.168.178.2 (ECDSA)
256 SHA256:TbVCtl6TJHAHacrTdwh9gqzvx8fB5bzhi1lL/ByFbYE
uvm1.nwa-net.de,176.95.26.236 (ECDSA)

* Ändert sich der Schlüssel eines Zielsystems, erfolgt die Warnmeldung

$ ssh scientific
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:r+9OEu2EM5ubr0P5wl4lLgUo5n/8/AkX2exIiPqQ9rs.
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /root/.ssh/known_hosts:15
ECDSA host key for scientific has changed and you have requested strict checking.
Host key verification failed.

* Wenn es sich um keine echte man-in-the-middle-attack handelt, entfernt man mithilfe eines Editors den veralteten Schlüssel aus der known_hosts-Datei und baut die Verbindung erneut auf

* Die Datei ''/etc/ssh/ssh_known_hosts'' macht nichts anderes als die Datei ''~/.ssh/known_hosts'' für jeden Benutzer, nur eben am Client

==Hostkeys==

* OpenSSH erstellt in der Regel automatisch Hostkeys.
* Sie dienen der Authentifizierung zwischen Server und Clientcomputer.

ssh_host_dsa_key
ssh_host_dsa_key.pub
ssh_host_ecdsa_key
ssh_host_ecdsa_key.pub
ssh_host_ed25519_key
ssh_host_ed25519_key.pub
ssh_host_rsa_key
ssh_host_rsa_key.pub

* Ohne Dateierweiterung = privater Schlüssel.
* Mit Erweiterung .pub = öffentlicher (public) Schlüssel.
* Die Konfigurationsdatei dazu ist ''sshd_config''.

Erläuterung zu den einzelnen Schlüsseldateien

* DSA: veraltet, bekannte Schwächen, wird nicht mehr unterstützt. 
* ECDSA: Momentan Standard bei Linux-Distributionen, kleinere Schlüsselgrößen als etwa RSA, Verdacht die gleichen Schwächen aufzuweisen wie DSA.
* RSA: etablierter Standard, überall unterstützt, existiert seit 1977. 
* Ed25519: ähnelt technisch ECDSA, weist jedoch nicht dieselbe Schwäche auf. 
* Wird von sehr neuen SSH-Versionen unterstützt, empfiehlt sich daher nicht als Standalone-Lösung, wenn man auch ältere Clientsysteme im Einsatz hat. 

* ''ssh-keygen'' generiert neue Schlüssel.
* Optional die Pfadangabe des Users angeben.
* Option ''–t'' legt den Typ des Schlüssels fest.
* Zur Auswahl stehen rsa, dsa, ecdsa und ed25519.

'''Beispiel:'''
* Erstellen eines neuen Schlüsselpaares für RSA.
* Es wurde keine passphrase verwendet.

# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
/etc/ssh/ssh_host_rsa_key
/etc/ssh/ssh_host_rsa_key already exists.
Overwrite (y/n)? y
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /etc/ssh/ssh_host_rsa_key.
Your public key has been saved in /etc/ssh/ssh_host_rsa_key.pub.
The key fingerprint is:
SHA256:zinmLbZLTBxcCOWN52QBDniQVAE9GfD/MuuQHzk3QQ4 root@scientific

* Generierte Datei ''ssh_host_rsa_key.pub'' enthält den öffentlichen Schlüssel des Systems.
* Dieser lässt sich an Clients verteilen.
* Datei ''ssh_host_rsa_key'' enthält privaten Schlüssel des Servers (geheim halten).

Folgende Kommandos können vom Clientsystem verwendet werden um den öffentlichen Schlüssel zu importieren:

# scp scientific:/etc/ssh/ssh_host_rsa_key.pub ./
# cat ssh_host_rsa_key.pub >> /etc/ssh/ssh_known_hosts
# rm ssh_host_rsa_key.pub

==Benutzerauthentifizierung mit Schlüsseln==

* Hostkeys können auch zur Authentifizierung von Benutzern verwendet werden.
* Verzichtet man auf ein Passwortes, lassen sich ''ssh'' oder ''scp'' in Skripten z. B. für Backups zu verwenden.
* Generierung der Schlüssel ebenfalls mittels ''ssh-keygen''.
* Schlüssel werden automatisch an der richtigen Stelle abgelegt.

$ ssh-keygen -t ecdsa
Generating public/private ecdsa key pair.
Enter file in which to save the key (/home/harald/.ssh/id_ecdsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/harald/.ssh/id_ecdsa.
Your public key has been saved in /home/harald/.ssh/id_ecdsa.pub.
The key fingerprint is:
SHA256:Br+8SdXitm/XnUmqVQB1/+aO0HkJKsrbAjzvTwV8FNI user@10.0.0.1

* Der Schlüssel wurde ohne passphrase erstellt und muss jetzt auf die Zielsysteme verteilt werden. 
* Dafür verwendet man das komfortable Tool ''ssh-copy-id''.

$ ssh-copy-id user
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed:
"/home/harald/.ssh/id_ecdsa.pub"
The authenticity of host 'archangel (192.168.178.2)' can't be established.
ECDSA key fingerprint is SHA256:VOrsAcZc//9EiAATV2DfSN2jHONQBEuJpyrmW+Q3CWQ.
ECDSA key fingerprint is MD5:8d:28:e5:f1:3b:e2:fd:69:cf:28:d9:06:5e:30:f3:30.
Are you sure you want to continue connecting (yes/no)? yes
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s),
to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are
prompted now it is to install the new keys

* Der Schlüssel wurde in die Datei ''~/.ssh/authorized_keys'' des Zielsystems (user) eingetragen und muss nun bei weiteren Anmeldungen nicht mehr angegeben werden.
* Die Schlüsseldateien befinden sich im Verzeichnis ''~/.ssh'' eines Benutzers und lauten auf diese Dateinamen:

id_rsa
id_rsa.pub
id_dsa
id_dsa.pub
id_ecdsa
id_ecdsa.pub
id_ed25519
id_ed25519.pub

* Die Dateinamen zu den Schlüsseln sind im Unterkapitel Hostkeys beschrieben.
* Für die Authentifizierung wird nur ein Schlüsselpaar benötigt.
* Server und Client Schlüsseltyp müssen natürlich identisch sein.

==Der Authentifizierungsagent==

* Der SSH-Agent ist eine weitere Möglichkeit ohne Passwörter Authentifizierungen auszuführen.
* Es lassen sich mehrere Schlüssel für einen Benutzer verwalten.
* Dafür muss er bei der Startphase von X ausgeführt werden.
* ''ssh-add'' kann dem SSH-Agent Schlüssel hinzufügen.
* Ohne Optionen sucht das Programm automatisch nach
''~/.ssh/id_rsa, ~/.ssh/id_dsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ed25519 und ~/.ssh/identity.''

''Wichtige Optionen sind:''

-l – listet die Fingerabdrücke der verfügbaren Schlüssel auf.
-d – entfernt einen einzelnen (angegebenen) Schlüssel vom Agenten.
-D – entfernt alle Schlüssel vom Agenten.
-s – liest Schlüssel von einer Smartcard.
-e – entfernt Schlüssel der Smartcard.
-x – sperrt den Agenten (mit Passwortschutz).
-X – entsperrt den Agenten.

#WEITERLEITUNG [[110.3 Schlüsselerstellung mit GnuPG]]

[[Category:Linux]]

[[Benutzer:Meikschwalm|Meikschwalm]] ([[Benutzer Diskussion:Meikschwalm|Diskussion]]) 21:38, 29. Jul. 2019 (CEST)

LPIC102/110.3 Daten durch Kryptografie schützen

2019-08-01T12:50:17Z

Meikschwalm:

==SSH Daemon==
* Das Paket ''openssh-server'' installiert die serverseitige Komponente von SSH
* Folgende Befehle starten unter systemd den SSH Dienst
# systemctl start sshd.service
# systemctl enable sshd.service

==SSH-Client==
* Die Verbidung startet ssh
* Host-Namen bzw. die IP-Adresse wird angegeben
* Anschliessend folgt die Eingabe des Kennwortes
$ ssh server
root@server's password:

* Zwei Wege um sich mit einem alternativen Benutzerkonto anzumelden
$ ssh -l willi server
$ ssh willi@server

===Grafische Anwendungen unter X tunneln===

* SSH-Verbindung wird von einem X-Terminal aus mit der zusätzlichen Option -X (großes X) initiiert

$ ssh -X server

* Auf der Konsole des Remote-Systems führt man die Anwendung aus

user@server:~ $ libreoffice

* Grafische Ausgabe und Bedienung erfolgt lokal am SSH-Client-Rechner
* Das hier beschriebene Verfahren wird als X11-Tunnel bezeichnet

===Weiterleitung anderer Ports durch einen SSH-Tunnel===

* Als Beispiel, der Zugriff auf einen Terminalserver im entfernten Netzwerk hinter einem SSH-Server

* IP-Adresse des Terminalservers 192.168.50.10 
* Terminalserver lauscht an Port 3389 
* IP des SSH-Server 119.117.63.126

* Zunächst wird die SSH-Verbindung initiiert

ssh 119.117.63.126 -L 4711:192.168.50.10:3389

* Option -L leitet Port 4711 an 192.168.50.10 mit Portnummer 3389 weiter
* Verbindungen werden an 192.168.50.10:3389 weitergeleitet
* Terminal-Dienste-Clients (z. B. remmina) nutzen nun als Ziel localhost:4711 

'''Hinweis''' 
Auch vom Windows-Computer aus kann mittels PuTTy auf einen Linux-Host zugegriffen werden 
Läuft ein X-Server auf dem Windows-Computer (z. B. Xming oder Cygwin), ist auch das Tunneln von Ports inklusive X11 durchführbar 

#WEITERLEITUNG [[PuTTY - ein freier SSH-Client]]

==SSH-Konfigurationsdateien==

''/etc/ssh/sshd_config''
* Die Konfigurationsdatei sshd_config dient der Konfiguration von sshd, also den SSH-Server

Port 22
Protocol 2
ListenAddress 192.168.0.58
PermitRootLogin no
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key

Erläuterung:

* sshd verwendet den Standardport 22.
* Ausschließlich SSH-2-Verbindungen.
* Zugriff auf Schnittstelle des Rechners: 192.168.0.58
* Kein login für root.
* Als Hostkey kommen RSA, ECDSA und Ed25519 in Frage.

'''Hinweis''' 
Auf die Authentifizierung mit Schlüsseln und ssh_known_hosts Datei wird später näher eingegangen
 

''/etc/ssh/ssh_config''
* Die Konfigurationsdatei ssh_config
* Sie dient der clientseitigen Konfiguration von SSH

z.B.
Clientseitige X11-Weiterleitung oder Passwortauthentifizierung
RSA-Authentifizierung aktiv
Standardport für ausgehende Verbindungen festlegen

* Die Optionsnamen innerhalb dieser Datei sind ansonsten selbsterklärend oder in der Manpage nachzuschlagen
* Die beiden gerade besprochenen Dateien kann man aufgrund ihrer Namensähnlichkeit schnell verwechseln
 

''/etc/hosts.allow'' und ''/etc/hosts.deny''

* Die beiden Dateien steuern wie die oben beschriebenen Dateien, den Zugriff auf SSH
* ''hosts.allow'' hat Vorrang vor der Datei ''hosts.deny
* Wird einem Host der Zugriff auf SSH durch ''hosts.allow'' gewährt, kann das durch keinen Eintrag in hosts.deny zurückgenommen werden
 

''/etc/nologin''

* Mit dem erstellen einer leeren Datei namens /etc/nologin lässt sich der Zugriff auf SSH verhindern
* Nur root kann sich dann noch am System anmelden
* In dieser Datei kann auch eine Nachricht an Benutzer hinterlassen werden die sich lokal anmelden wollen

==Wichtigste Wissensgebiete==

* einen OpenSSH-2-Client grundlegend konfigurieren und verwenden
* die Rolle von OpenSSH-2-Rechnerschlüsseln verstehen
* GnuPG grundlegend konfigurieren und verwenden
* GPG verwenden um Dateien zu verschlüsseln, entschlüsseln, signieren und zu überprüfen
* SSH-Port-Tunnel (auch X11-Tunnel) verstehen

==Liste wichtiger Dateien, Verzeichnisse und Anwendungen==

* ssh
* ssh-keygen
* ssh-agent
* ssh-add
* ~/.ssh/id_rsa und id_rsa.pub
* ~/.ssh/id_dsa und id_dsa.pub
* ~/.ssh/id_ecdsa und id_ecdsa.pub
* ~/.ssh/id_ed25519 und id_ed25519.pub
* /etc/ssh/ssh_host_rsa_key und ssh_host_rsa_key.pub
* /etc/ssh/ssh_host_dsa_key und ssh_host_dsa_key.pub
* /etc/ssh/ssh_host_ecdsa_key und ssh_host_ecdsa_key.pub
* /etc/ssh/ssh_host_ed25519_key und ssh_host_ed25519_key.pub
* ~/.ssh/authorized_keys
* ssh_known_hosts
* gpg
* gpg-agent
* ~/.gnupg/
 #WEITERLEITUNG [[110.3 SSH Authentifizierung mit Schlüsseln]]

=Quellenangaben=

[[Benutzer:Meikschwalm|Meikschwalm]] ([[Benutzer Diskussion:Meikschwalm|Diskussion]]) 21:38, 29. Jul. 2019 (CEST)

[[Category:Linux]]

LPIC102/110.3 Daten durch Kryptografie schützen

2019-08-01T12:31:13Z

Meikschwalm: /* SSH Daemon */

==SSH Daemon==
* Das Paket ''openssh-server'' installiert die serverseitige Komponente von SSH. 
* Folgende Befehle starten unter systemd den SSH Dienst.
# systemctl start sshd.service
# systemctl enable sshd.service

==SSH-Client==
* Die Verbidung startet ssh.
* Host-Namen bzw. die IP-Adresse wird angegeben.
* Anschliessend folgt die Eingabe des Kennwortes.
$ ssh server
root@server's password:

* Zwei Wege um sich mit einem alternativen Benutzerkonto anzumelden:
$ ssh -l willi server
$ ssh willi@server

===Grafische Anwendungen unter X tunneln===

* SSH-Verbindung wird von einem X-Terminal aus mit der zusätzlichen Option -X (großes X) initiiert.

$ ssh -X server

* Auf der Konsole des Remote-Systems führt man die Anwendung aus:

user@server:~ $ libreoffice

* Grafische Ausgabe und Bedienung erfolgt lokal am SSH-Client-Rechner.
* Das hier beschriebene Verfahren wird als X11-Tunnel bezeichnet.
*
===Weiterleitung anderer Ports durch einen SSH-Tunnel.===

* Als Beispiel, der Zugriff auf einen Terminalserver im entfernten Netzwerk hinter einem SSH-Server.

*IP-Adresse des Terminalservers 192.168.50.10 
*Terminalserver lauscht an Port 3389 
*IP des SSH-Server 119.117.63.126

* Zunächst wird die SSH-Verbindung initiiert.

ssh 119.117.63.126 -L 4711:192.168.50.10:3389

*Option -L leitet Port 4711 an 192.168.50.10 mit Portnummer 3389 weiter. 
*Verbindungen werden an 192.168.50.10:3389 weitergeleitet. 
*Terminal-Dienste-Clients (z. B. remmina) nutzen nun als Ziel localhost:4711 

'''Hinweis''' 
Auch vom Windows-Computer aus kann mittels PuTTy auf einen Linux-Host zugegriffen werden. 
Läuft ein X-Server auf dem Windows-Computer (z. B. Xming oder Cygwin), ist auch das Tunneln von Ports inklusive X11 durchführbar. 

#WEITERLEITUNG [[PuTTY - ein freier SSH-Client]]

==SSH-Konfigurationsdateien==

''/etc/ssh/sshd_config''
* Die Konfigurationsdatei sshd_config dient der Konfiguration von sshd, also den SSH-Server.

Port 22
Protocol 2
ListenAddress 192.168.0.58
PermitRootLogin no
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key

Erläuterung:

* sshd verwendet den Standardport 22.
* Ausschließlich SSH-2-Verbindungen.
* Zugriff auf Schnittstelle des Rechners: 192.168.0.58
* Kein login für root.
* Als Hostkey kommen RSA, ECDSA und Ed25519 in Frage.

'''Hinweis''' 
Auf die Authentifizierung mit Schlüsseln und ssh_known_hosts Datei wird später näher eingegangen.
 

''/etc/ssh/ssh_config''
* Die Konfigurationsdatei ssh_config.
* Sie dient der clientseitigen Konfiguration von SSH.

z.B.
Clientseitige X11-Weiterleitung oder Passwortauthentifizierung
RSA-Authentifizierung aktiv
Standardport für ausgehende Verbindungen festlegen

* Die Optionsnamen innerhalb dieser Datei sind ansonsten selbsterklärend oder in der Manpage nachzuschlagen.
* Die beiden gerade besprochenen Dateien kann man aufgrund ihrer Namensähnlichkeit schnell verwechseln.
 

''/etc/hosts.allow'' und ''/etc/hosts.deny''

* Die beiden Dateien steuern wie die oben beschriebenen Dateien, den Zugriff auf SSH.
* ''hosts.allow'' hat Vorrang vor der Datei ''hosts.deny.
* Wird einem Host der Zugriff auf SSH durch ''hosts.allow'' gewährt, kann das durch keinen Eintrag in hosts.deny zurückgenommen werden.
 

''/etc/nologin''

* Mit dem erstellen einer leeren Datei namens /etc/nologin lässt sich der Zugriff auf SSH verhindern.
* Nur root kann sich dann noch am System anmelden.
* In dieser Datei kann auch eine Nachricht an Benutzer hinterlassen werden die sich lokal anmelden wollen.

==Wichtigste Wissensgebiete==

* einen OpenSSH-2-Client grundlegend konfigurieren und verwenden
* die Rolle von OpenSSH-2-Rechnerschlüsseln verstehen
* GnuPG grundlegend konfigurieren und verwenden
* GPG verwenden um Dateien zu verschlüsseln, entschlüsseln, signieren und zu überprüfen
* SSH-Port-Tunnel (auch X11-Tunnel) verstehen

==Liste wichtiger Dateien, Verzeichnisse und Anwendungen==

* ssh
* ssh-keygen
* ssh-agent
* ssh-add
* ~/.ssh/id_rsa und id_rsa.pub
* ~/.ssh/id_dsa und id_dsa.pub
* ~/.ssh/id_ecdsa und id_ecdsa.pub
* ~/.ssh/id_ed25519 und id_ed25519.pub
* /etc/ssh/ssh_host_rsa_key und ssh_host_rsa_key.pub
* /etc/ssh/ssh_host_dsa_key und ssh_host_dsa_key.pub
* /etc/ssh/ssh_host_ecdsa_key und ssh_host_ecdsa_key.pub
* /etc/ssh/ssh_host_ed25519_key und ssh_host_ed25519_key.pub
* ~/.ssh/authorized_keys
* ssh_known_hosts
* gpg
* gpg-agent
* ~/.gnupg/
 #WEITERLEITUNG [[110.3 SSH Authentifizierung mit Schlüsseln]]

=Quellenangaben=

[[Benutzer:Meikschwalm|Meikschwalm]] ([[Benutzer Diskussion:Meikschwalm|Diskussion]]) 21:38, 29. Jul. 2019 (CEST)

[[Category:Linux]]

LPIC102/110.3 Schlüsselerstellung mit GnuPG

2019-08-01T12:27:52Z

Meikschwalm:

LPIC102/110.3 Schlüsselerstellung mit GnuPG

2019-08-01T12:27:25Z

Meikschwalm: /* GnuPG */

===GnuPG===

* GNU Privacy Guard, kurz GPG
* Verschlüsselt und signiert Daten
* Asymmetrisches Verschlüsselungsverfahren (Public-Key)
* Öffentlicher Schlüssel = Verschlüsselungsschlüssel
* Privater Schlüssel = Entschlüsselungsschlüssel
* Privater Schlüssel wird beim generieren von Signaturen verwendet
* Der Schlüssel sollte also gut geschützt werden
* Stichwort Schlüsselverschlüsselungsschlüssel
(symmetrische Verschlüsselung anschließend mit einem asymmetrischen Schlüssel verschlüsseln)
* Grafische Benutzeroberflächen sind: GNU Privacy Assistant (GPA), für GNOME - Seahorse, und für KDE - KGpg

Beispiel anhand einer Mail:
* Übermittlung von Mails erfordert Verschlüsselung
* Ein SMTP-Server nimmt sich dieser Problematik nicht an
* Mails werden unverschlüsselt auf Server gespeichert
* Schlechter Sicherheitsstandard wie bei einer Postkarte
* Es gibt mehrere Mailprogramme, die GPG direkt oder indirekt über Plugins unterstützt
* Beispiele: Evolution, Mutt, Kmail, Thunderbird, Eudora, Enigmail, Apple Mail und sogar Microsoft Outlook
* Für die LPI-Prüfung müssen Sie natürlich nicht mit den Frontends arbeiten können
* sondern das Programm GPG selbst mit den dazugehörenden Dateien kennen
* Das Programm ist sehr umfangreich, wie ein Blick in die Manpage sofort verrät

[[Category:Linux]]

LPIC102/110.3 Schlüsselerstellung mit GnuPG

2019-08-01T12:25:15Z

Meikschwalm: /* GnuPG */

===GnuPG===

* GNU Privacy Guard, kurz GPG
* Verschlüsselt und signiert Daten
* Asymmetrisches Verschlüsselungsverfahren (Public-Key)
* Öffentlicher Schlüssel = Verschlüsselungsschlüssel
* Privater Schlüssel = Entschlüsselungsschlüssel
* Privater Schlüssel wird beim generieren von Signaturen verwendet
* Der Schlüssel sollte also gut geschützt werden
* Stichwort Schlüsselverschlüsselungsschlüssel (symmetrische Verschlüsselung anschließend mit einem asymmetrischen Schlüssel verschlüsseln)
* Grafische Benutzeroberflächen sind: GNU Privacy Assistant (GPA), für GNOME - Seahorse, und für KDE - KGpg

Beispiel anhand einer Mail:
* Übermittlung von Mails erfordert Verschlüsselung
* Ein SMTP-Server nimmt sich dieser Problematik nicht an
* Mails werden unverschlüsselt auf Server gespeichert
* Schlechter Sicherheitsstandard wie bei einer Postkarte
* Es gibt mehrere Mailprogramme, die GPG direkt oder indirekt über Plugins unterstützt
* Beispiele: Evolution, Mutt, Kmail, Thunderbird, Eudora, Enigmail, Apple Mail und sogar Microsoft Outlook
* Für die LPI-Prüfung müssen Sie natürlich nicht mit den Frontends arbeiten können
* sondern das Programm GPG selbst mit den dazugehörenden Dateien kennen
* Das Programm ist sehr umfangreich, wie ein Blick in die Manpage sofort verrät

[[Category:Linux]]

LPIC102/110.3 Schlüsselerstellung mit GnuPG

2019-07-31T12:50:31Z

Meikschwalm: /* GnuPG */

===GnuPG===

* GNU Privacy Guard, kurz GPG
* Verschlüsselt und signiert Daten
* Asymmetrisches Verschlüsselungsverfahren
* Öffentlicher Schlüssel ist der Verschlüsselungsschlüssel, der private Schlüssel ist der Entschlüsselungsschlüssel.
* Privater Schlüssel wird beim Generieren von Signaturen verwendet.
* Der Schlüssel sollte also gut geschützt werden.
* Stischwort Schlüsselverschlüsselungsschlüssel (symmetrische Verschlüsselung anschließend mit einem asymmetrischen Schlüssel verschlüsseln).
* Grafische Benutzeroberflächen GNU Privacy Assistant (GPA), für GNOME - Seahorse, und für KDE - KGpg.

Bei der Übermittlung von Mail-Nachrichten ist Verschlüsselung notwendig.
Ein SMTP-Server nimmt sich dieser Problematik nicht an.
Mails werden bei der Lagerung auf dem Server unverschlüsselt gespeichert.
Ohne Verschlüsselung ist der Sicherheitsstandard quasi wie bei einer Postkarte.
Es gibt mehrere Mailprogramme, die GPG direkt oder indirekt über Plugins unterstützen. B
Beispiele: Evolution, Mutt, Kmail, Thunderbird, Eudora, Enigmail, Apple Mail und sogar Microsoft Outlook.
Für die LPI-Prüfung müssen Sie natürlich nicht mit den Frontends arbeiten können,
sondern das Programm GPG selbst mit den dazugehörenden Dateien kennen.
Das Programm ist sehr umfangreich, wie ein Blick in die Manpage sofort verrät.

[[Category:Linux]]

WebDAV/Client

2019-07-30T11:28:03Z

Meikschwalm: /* Wozu dient davfs2 */

==Wozu dient davfs2==

davfs2, das WebDAV Linux File System, ist ein Dateisystemtreiber, der es erlaubt, WebDAV-Internet-Ressourcen als lokales Dateisystem zu mounten.

'''Grundlegende Installation'''

# Installation des WebDav Linux File System (davfs2)
# Erstellen eines Verzeichnissen als Mountpoint <code> mkdir ~/media/nextcloud </code>
# Mittels vim die /etc/fstab bearbeiten <code> https://cloud.itw-berlin.net/remote.php/webdav/ ~/nextcloud davfs uid=1000,gid=1000,noauto,user,_netdev,rw 0 0 </code>
# Die Datei Secrets erstellen und um die Anmeldedaten erweitern <code> ~/.davfs2/secrets</code> <code>/media/nextcloud mustername "musterpasswort" </code>
# Die Rechte der Datei secrets Datei wie folgt ändern <code>chmod 600 ~/.davfs2/secrets</code>
# Außerdem muss der Benutzer Mitglied der Gruppe davfs2 sein
# <code>usermod -aG davfs2 <Benutzername></code> (als root)
# Den Ordner nextcloud mounten <code>mount ~/nextcloud</code>

==Verbindung über Dateimanager==

Mit dem Dateimanager Dolphin respektive Konquerer lässt sich direkt auf WebDAV-Ressourcen zugreifen. Dazu müssen im Regelfall keine weiteren Pakete installiert werden.

Um mittels WebDAV auf beispielsweise die Nextcloud-Dateien Zugriff zu erhalten, muss man folgendes in die Adressleiste des Dateimanagers eingeben.

webdavs://cloud.itw-berlin.net/remote.php/webdav/

==Debugging==
Messages of davfs2 should be prefixed with a time stamp and "mount.davfs".
grep -Eni "mount.davfs" /var/log/syslog

# enables detailed davfs2 logging
echo "debug most" >> /etc/davfs2/davfs2.conf

==Quellen==
https://wiki.ubuntuusers.de/WebDAV/ 
http://www.hagemann.ws/blog/linux-mount-webdav-share-using-fstab-and-davfs2.html

[[Category:Nextcloud]]

[[Benutzer:Meikschwalm|Meikschwalm]] ([[Benutzer Diskussion:Meikschwalm|Diskussion]]) 11:27, 21. Mai 2019 (CEST)

LPIC102/110.3 Schlüsselerstellung mit GnuPG

2019-07-30T09:28:12Z

Meikschwalm: /* GnuPG */

===GnuPG===

* GNU Privacy Guard, auch kurz als GPG bezeichnet
* Auf einfache Weise Daten verschlüsseln oder signieren.
* Bietet asymmetrisches Verschlüsselungsverfahren. Bedeutet, ein Schlüsselpaar ist erforderlich.
* Der öffentliche Schlüssel ist der Verschlüsselungsschlüssel, der private Schlüssel ist der Entschlüsselungsschlüssel.
* Der private Schlüssel wird beim Generieren von Signaturen verwendet.
Das sind zwei gute Gründe, den Schlüssel wie seinen eigenen Augapfel zu schützen.

Zur Sicherheit können Sie den Schlüssel der symmetrischen Verschlüsselung anschließend mit einem asymmetrischen 
Schlüssel verschlüsseln. 
Man spricht dann bei dem verwendeten öffentlichen Schlüssel auch von einem Schlüsselverschlüsselungsschlüssel.

Eine grafische Benutzeroberfläche bietet der GNU Privacy Assistant (GPA)
für GNOME das Programm Seahorse, und für KDE wurde KGpg entwickelt.

Damit Windows-Computer in einem solchen Umfeld nicht zur Sicherheitslücke werden, können diese Gpg4win einsetzen,
das übrigens absolut kompatibel zu den Linux-Versionen ist.

[[Category:Linux]]

WebDAV/Client

2019-07-30T08:44:17Z

Meikschwalm: /* Wozu dient davfs2 */

==Wozu dient davfs2==

davfs2, das WebDAV Linux File System, ist ein Dateisystemtreiber, der es erlaubt, WebDAV-Internet-Ressourcen als lokales Dateisystem zu mounten.

'''Grundlegende Installation'''

# Installation des WebDav Linux File System (davfs2)
# Erstellen eines Verzeichnissen als Mountpoint <code> mkdir /media/nextcloud </code>
# Mittels vim die /etc/fstab bearbeiten <code> https://cloud.itw-berlin.net/remote.php/webdav/ /media/nextcloud davfs uid=1000,gid=1000,noauto,user,_netdev,rw 0 0 </code>
# Die Datei Secrets erstellen und um die Anmeldedaten erweitern <code> ~/.davfs2/secrets</code> <code>/media/nextcloud mustername "musterpasswort" </code>
# Die Rechte der Datei secrets Datei wie folgt ändern <code>chmod 600 ~/.davfs2/secrets</code>
# Außerdem muss der Benutzer Mitglied der Gruppe davfs2 sein
# <code>usermod -aG davfs2 <Benutzername></code> (als root)
# Den Ordner nextcloud mounten <code>mount ~/nextcloud</code>

==Verbindung über Dateimanager==

Mit dem Dateimanager Dolphin respektive Konquerer lässt sich direkt auf WebDAV-Ressourcen zugreifen. Dazu müssen im Regelfall keine weiteren Pakete installiert werden.

Um mittels WebDAV auf beispielsweise die Nextcloud-Dateien Zugriff zu erhalten, muss man folgendes in die Adressleiste des Dateimanagers eingeben.

webdavs://cloud.itw-berlin.net/remote.php/webdav/

==Debugging==
Messages of davfs2 should be prefixed with a time stamp and "mount.davfs".
grep -Eni "mount.davfs" /var/log/syslog

# enables detailed davfs2 logging
echo "debug most" >> /etc/davfs2/davfs2.conf

==Quellen==
https://wiki.ubuntuusers.de/WebDAV/ 
http://www.hagemann.ws/blog/linux-mount-webdav-share-using-fstab-and-davfs2.html

[[Category:Nextcloud]]

[[Benutzer:Meikschwalm|Meikschwalm]] ([[Benutzer Diskussion:Meikschwalm|Diskussion]]) 11:27, 21. Mai 2019 (CEST)

LPIC102/110.3 Daten durch Kryptografie schützen

2019-07-29T20:09:48Z

Meikschwalm: /* SSH-Konfigurationsdateien */

==SSH Daemon==
* Das Paket openssh-server installiert die serverseitige Komponente von SSH. 
* Folgende Befehle starten unter systemd den SSH Dienst.
# systemctl start sshd.service
# systemctl enable sshd.service

==SSH-Client==
* Die Verbidung startet ssh.
* Host-Namen bzw. die IP-Adresse wird angegeben.
* Anschliessend folgt die Eingabe des Kennwortes.
$ ssh server
root@server's password:

* Zwei Wege um sich mit einem alternativen Benutzerkonto anzumelden:
$ ssh -l willi server
$ ssh willi@server

===Grafische Anwendungen unter X tunneln===

* SSH-Verbindung wird von einem X-Terminal aus mit der zusätzlichen Option -X (großes X) initiiert.

$ ssh -X server

* Auf der Konsole des Remote-Systems führt man die Anwendung aus:

user@server:~ $ libreoffice

* Grafische Ausgabe und Bedienung erfolgt lokal am SSH-Client-Rechner.
* Das hier beschriebene Verfahren wird als X11-Tunnel bezeichnet.
*
===Weiterleitung anderer Ports durch einen SSH-Tunnel.===

* Als Beispiel, der Zugriff auf einen Terminalserver im entfernten Netzwerk hinter einem SSH-Server.

*IP-Adresse des Terminalservers 192.168.50.10 
*Terminalserver lauscht an Port 3389 
*IP des SSH-Server 119.117.63.126

* Zunächst wird die SSH-Verbindung initiiert.

ssh 119.117.63.126 -L 4711:192.168.50.10:3389

*Option -L leitet Port 4711 an 192.168.50.10 mit Portnummer 3389 weiter. 
*Verbindungen werden an 192.168.50.10:3389 weitergeleitet. 
*Terminal-Dienste-Clients (z. B. remmina) nutzen nun als Ziel localhost:4711 

'''Hinweis''' 
Auch vom Windows-Computer aus kann mittels PuTTy auf einen Linux-Host zugegriffen werden. 
Läuft ein X-Server auf dem Windows-Computer (z. B. Xming oder Cygwin), ist auch das Tunneln von Ports inklusive X11 durchführbar. 

#WEITERLEITUNG [[PuTTY - ein freier SSH-Client]]

==SSH-Konfigurationsdateien==

''/etc/ssh/sshd_config''
* Die Konfigurationsdatei sshd_config dient der Konfiguration von sshd, also den SSH-Server.

Port 22
Protocol 2
ListenAddress 192.168.0.58
PermitRootLogin no
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key

Erläuterung:

* sshd verwendet den Standardport 22.
* Ausschließlich SSH-2-Verbindungen.
* Zugriff auf Schnittstelle des Rechners: 192.168.0.58
* Kein login für root.
* Als Hostkey kommen RSA, ECDSA und Ed25519 in Frage.

'''Hinweis''' 
Auf die Authentifizierung mit Schlüsseln und ssh_known_hosts Datei wird später näher eingegangen.
 

''/etc/ssh/ssh_config''
* Die Konfigurationsdatei ssh_config.
* Sie dient der clientseitigen Konfiguration von SSH.

z.B.
Clientseitige X11-Weiterleitung oder Passwortauthentifizierung
RSA-Authentifizierung aktiv
Standardport für ausgehende Verbindungen festlegen

* Die Optionsnamen innerhalb dieser Datei sind ansonsten selbsterklärend oder in der Manpage nachzuschlagen.
* Die beiden gerade besprochenen Dateien kann man aufgrund ihrer Namensähnlichkeit schnell verwechseln.
 

''/etc/hosts.allow'' und ''/etc/hosts.deny''

* Die beiden Dateien steuern wie die oben beschriebenen Dateien, den Zugriff auf SSH.
* ''hosts.allow'' hat Vorrang vor der Datei ''hosts.deny.
* Wird einem Host der Zugriff auf SSH durch ''hosts.allow'' gewährt, kann das durch keinen Eintrag in hosts.deny zurückgenommen werden.
 

''/etc/nologin''

* Mit dem erstellen einer leeren Datei namens /etc/nologin lässt sich der Zugriff auf SSH verhindern.
* Nur root kann sich dann noch am System anmelden.
* In dieser Datei kann auch eine Nachricht an Benutzer hinterlassen werden die sich lokal anmelden wollen.

==Wichtigste Wissensgebiete==

* einen OpenSSH-2-Client grundlegend konfigurieren und verwenden
* die Rolle von OpenSSH-2-Rechnerschlüsseln verstehen
* GnuPG grundlegend konfigurieren und verwenden
* GPG verwenden um Dateien zu verschlüsseln, entschlüsseln, signieren und zu überprüfen
* SSH-Port-Tunnel (auch X11-Tunnel) verstehen

==Liste wichtiger Dateien, Verzeichnisse und Anwendungen==

* ssh
* ssh-keygen
* ssh-agent
* ssh-add
* ~/.ssh/id_rsa und id_rsa.pub
* ~/.ssh/id_dsa und id_dsa.pub
* ~/.ssh/id_ecdsa und id_ecdsa.pub
* ~/.ssh/id_ed25519 und id_ed25519.pub
* /etc/ssh/ssh_host_rsa_key und ssh_host_rsa_key.pub
* /etc/ssh/ssh_host_dsa_key und ssh_host_dsa_key.pub
* /etc/ssh/ssh_host_ecdsa_key und ssh_host_ecdsa_key.pub
* /etc/ssh/ssh_host_ed25519_key und ssh_host_ed25519_key.pub
* ~/.ssh/authorized_keys
* ssh_known_hosts
* gpg
* gpg-agent
* ~/.gnupg/
 #WEITERLEITUNG [[110.3 SSH Authentifizierung mit Schlüsseln]]

=Quellenangaben=

[[Benutzer:Meikschwalm|Meikschwalm]] ([[Benutzer Diskussion:Meikschwalm|Diskussion]]) 21:38, 29. Jul. 2019 (CEST)

[[Category:Linux]]

LPIC102/110.3 Daten durch Kryptografie schützen

2019-07-29T20:09:12Z

Meikschwalm: /* SSH-Konfigurationsdateien */

==SSH Daemon==
* Das Paket openssh-server installiert die serverseitige Komponente von SSH. 
* Folgende Befehle starten unter systemd den SSH Dienst.
# systemctl start sshd.service
# systemctl enable sshd.service

==SSH-Client==
* Die Verbidung startet ssh.
* Host-Namen bzw. die IP-Adresse wird angegeben.
* Anschliessend folgt die Eingabe des Kennwortes.
$ ssh server
root@server's password:

* Zwei Wege um sich mit einem alternativen Benutzerkonto anzumelden:
$ ssh -l willi server
$ ssh willi@server

===Grafische Anwendungen unter X tunneln===

* SSH-Verbindung wird von einem X-Terminal aus mit der zusätzlichen Option -X (großes X) initiiert.

$ ssh -X server

* Auf der Konsole des Remote-Systems führt man die Anwendung aus:

user@server:~ $ libreoffice

* Grafische Ausgabe und Bedienung erfolgt lokal am SSH-Client-Rechner.
* Das hier beschriebene Verfahren wird als X11-Tunnel bezeichnet.
*
===Weiterleitung anderer Ports durch einen SSH-Tunnel.===

* Als Beispiel, der Zugriff auf einen Terminalserver im entfernten Netzwerk hinter einem SSH-Server.

*IP-Adresse des Terminalservers 192.168.50.10 
*Terminalserver lauscht an Port 3389 
*IP des SSH-Server 119.117.63.126

* Zunächst wird die SSH-Verbindung initiiert.

ssh 119.117.63.126 -L 4711:192.168.50.10:3389

*Option -L leitet Port 4711 an 192.168.50.10 mit Portnummer 3389 weiter. 
*Verbindungen werden an 192.168.50.10:3389 weitergeleitet. 
*Terminal-Dienste-Clients (z. B. remmina) nutzen nun als Ziel localhost:4711 

'''Hinweis''' 
Auch vom Windows-Computer aus kann mittels PuTTy auf einen Linux-Host zugegriffen werden. 
Läuft ein X-Server auf dem Windows-Computer (z. B. Xming oder Cygwin), ist auch das Tunneln von Ports inklusive X11 durchführbar. 

#WEITERLEITUNG [[PuTTY - ein freier SSH-Client]]

==SSH-Konfigurationsdateien==

''/etc/ssh/sshd_config''
* Die Konfigurationsdatei sshd_config dient der Konfiguration von sshd, also den SSH-Server.

Port 22
Protocol 2
ListenAddress 192.168.0.58
PermitRootLogin no
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key

Erläuterung:

* sshd verwendet den Standardport 22.
* Ausschließlich SSH-2-Verbindungen.
* Zugriff auf Schnittstelle des Rechners: 192.168.0.58
* Kein login für root.
* Als Hostkey kommen RSA, ECDSA und Ed25519 in Frage.

'''Hinweis''' 
Auf die Authentifizierung mit Schlüsseln und ssh_known_hosts Datei wird später näher eingegangen.
 

''/etc/ssh/ssh_config''
* Die Konfigurationsdatei ssh_config.
* Sie dient der clientseitigen Konfiguration von SSH.

z.B.
* Clientseitige X11-Weiterleitung oder Passwortauthentifizierung
* RSA-Authentifizierung aktiv
* Standardport für ausgehende Verbindungen festlegen

* Die Optionsnamen innerhalb dieser Datei sind ansonsten selbsterklärend oder in der Manpage nachzuschlagen.
* Die beiden gerade besprochenen Dateien kann man aufgrund ihrer Namensähnlichkeit schnell verwechseln.
 

''/etc/hosts.allow'' und ''/etc/hosts.deny''

* Die beiden Dateien steuern wie die oben beschriebenen Dateien, den Zugriff auf SSH.
* ''hosts.allow'' hat Vorrang vor der Datei ''hosts.deny.
* Wird einem Host der Zugriff auf SSH durch ''hosts.allow'' gewährt, kann das durch keinen Eintrag in hosts.deny zurückgenommen werden.
 

''/etc/nologin''

* Mit dem erstellen einer leeren Datei namens /etc/nologin lässt sich der Zugriff auf SSH verhindern.
* Nur root kann sich dann noch am System anmelden.
* In dieser Datei kann auch eine Nachricht an Benutzer hinterlassen werden die sich lokal anmelden wollen.

==Wichtigste Wissensgebiete==

* einen OpenSSH-2-Client grundlegend konfigurieren und verwenden
* die Rolle von OpenSSH-2-Rechnerschlüsseln verstehen
* GnuPG grundlegend konfigurieren und verwenden
* GPG verwenden um Dateien zu verschlüsseln, entschlüsseln, signieren und zu überprüfen
* SSH-Port-Tunnel (auch X11-Tunnel) verstehen

==Liste wichtiger Dateien, Verzeichnisse und Anwendungen==

* ssh
* ssh-keygen
* ssh-agent
* ssh-add
* ~/.ssh/id_rsa und id_rsa.pub
* ~/.ssh/id_dsa und id_dsa.pub
* ~/.ssh/id_ecdsa und id_ecdsa.pub
* ~/.ssh/id_ed25519 und id_ed25519.pub
* /etc/ssh/ssh_host_rsa_key und ssh_host_rsa_key.pub
* /etc/ssh/ssh_host_dsa_key und ssh_host_dsa_key.pub
* /etc/ssh/ssh_host_ecdsa_key und ssh_host_ecdsa_key.pub
* /etc/ssh/ssh_host_ed25519_key und ssh_host_ed25519_key.pub
* ~/.ssh/authorized_keys
* ssh_known_hosts
* gpg
* gpg-agent
* ~/.gnupg/
 #WEITERLEITUNG [[110.3 SSH Authentifizierung mit Schlüsseln]]

=Quellenangaben=

[[Benutzer:Meikschwalm|Meikschwalm]] ([[Benutzer Diskussion:Meikschwalm|Diskussion]]) 21:38, 29. Jul. 2019 (CEST)

[[Category:Linux]]

LPIC102/110.3 Daten durch Kryptografie schützen

2019-07-29T20:08:26Z

Meikschwalm: /* SSH-Konfigurationsdateien */

==SSH Daemon==
* Das Paket openssh-server installiert die serverseitige Komponente von SSH. 
* Folgende Befehle starten unter systemd den SSH Dienst.
# systemctl start sshd.service
# systemctl enable sshd.service

==SSH-Client==
* Die Verbidung startet ssh.
* Host-Namen bzw. die IP-Adresse wird angegeben.
* Anschliessend folgt die Eingabe des Kennwortes.
$ ssh server
root@server's password:

* Zwei Wege um sich mit einem alternativen Benutzerkonto anzumelden:
$ ssh -l willi server
$ ssh willi@server

===Grafische Anwendungen unter X tunneln===

* SSH-Verbindung wird von einem X-Terminal aus mit der zusätzlichen Option -X (großes X) initiiert.

$ ssh -X server

* Auf der Konsole des Remote-Systems führt man die Anwendung aus:

user@server:~ $ libreoffice

* Grafische Ausgabe und Bedienung erfolgt lokal am SSH-Client-Rechner.
* Das hier beschriebene Verfahren wird als X11-Tunnel bezeichnet.
*
===Weiterleitung anderer Ports durch einen SSH-Tunnel.===

* Als Beispiel, der Zugriff auf einen Terminalserver im entfernten Netzwerk hinter einem SSH-Server.

*IP-Adresse des Terminalservers 192.168.50.10 
*Terminalserver lauscht an Port 3389 
*IP des SSH-Server 119.117.63.126

* Zunächst wird die SSH-Verbindung initiiert.

ssh 119.117.63.126 -L 4711:192.168.50.10:3389

*Option -L leitet Port 4711 an 192.168.50.10 mit Portnummer 3389 weiter. 
*Verbindungen werden an 192.168.50.10:3389 weitergeleitet. 
*Terminal-Dienste-Clients (z. B. remmina) nutzen nun als Ziel localhost:4711 

'''Hinweis''' 
Auch vom Windows-Computer aus kann mittels PuTTy auf einen Linux-Host zugegriffen werden. 
Läuft ein X-Server auf dem Windows-Computer (z. B. Xming oder Cygwin), ist auch das Tunneln von Ports inklusive X11 durchführbar. 

#WEITERLEITUNG [[PuTTY - ein freier SSH-Client]]

==SSH-Konfigurationsdateien==

''/etc/ssh/sshd_config''
* Die Konfigurationsdatei sshd_config dient der Konfiguration von sshd, also den SSH-Server.

Port 22
Protocol 2
ListenAddress 192.168.0.58
PermitRootLogin no
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key

Erläuterung:

* sshd verwendet den Standardport 22.
* Ausschließlich SSH-2-Verbindungen.
* Zugriff auf Schnittstelle des Rechners: 192.168.0.58
* Kein login für root.
* Als Hostkey kommen RSA, ECDSA und Ed25519 in Frage.

'''Hinweis''' 
Auf die Authentifizierung mit Schlüsseln und ssh_known_hosts Datei wird später näher eingegangen.
 

''/etc/ssh/ssh_config''
* Die Konfigurationsdatei ssh_config.
* Sie dient der clientseitigen Konfiguration von SSH.

z.B.
* Clientseitige X11-Weiterleitung oder Passwortauthentifizierung
* RSA-Authentifizierung aktiv
* Standardport für ausgehende Verbindungen festlegen
 
* Die Optionsnamen innerhalb dieser Datei sind ansonsten selbsterklärend oder in der Manpage nachzuschlagen.
* Die beiden gerade besprochenen Dateien kann man aufgrund ihrer Namensähnlichkeit schnell verwechseln.
 

''/etc/hosts.allow'' und ''/etc/hosts.deny''

* Die beiden Dateien steuern wie die oben beschriebenen Dateien, den Zugriff auf SSH.
* ''hosts.allow'' hat Vorrang vor der Datei ''hosts.deny.
* Wird einem Host der Zugriff auf SSH durch ''hosts.allow'' gewährt, kann das durch keinen Eintrag in hosts.deny zurückgenommen werden.

''/etc/nologin''

* Mit dem erstellen einer leeren Datei namens /etc/nologin lässt sich der Zugriff auf SSH verhindern.
* Nur root kann sich dann noch am System anmelden.
* In dieser Datei kann auch eine Nachricht an Benutzer hinterlassen werden die sich lokal anmelden wollen.

==Wichtigste Wissensgebiete==

* einen OpenSSH-2-Client grundlegend konfigurieren und verwenden
* die Rolle von OpenSSH-2-Rechnerschlüsseln verstehen
* GnuPG grundlegend konfigurieren und verwenden
* GPG verwenden um Dateien zu verschlüsseln, entschlüsseln, signieren und zu überprüfen
* SSH-Port-Tunnel (auch X11-Tunnel) verstehen

==Liste wichtiger Dateien, Verzeichnisse und Anwendungen==

* ssh
* ssh-keygen
* ssh-agent
* ssh-add
* ~/.ssh/id_rsa und id_rsa.pub
* ~/.ssh/id_dsa und id_dsa.pub
* ~/.ssh/id_ecdsa und id_ecdsa.pub
* ~/.ssh/id_ed25519 und id_ed25519.pub
* /etc/ssh/ssh_host_rsa_key und ssh_host_rsa_key.pub
* /etc/ssh/ssh_host_dsa_key und ssh_host_dsa_key.pub
* /etc/ssh/ssh_host_ecdsa_key und ssh_host_ecdsa_key.pub
* /etc/ssh/ssh_host_ed25519_key und ssh_host_ed25519_key.pub
* ~/.ssh/authorized_keys
* ssh_known_hosts
* gpg
* gpg-agent
* ~/.gnupg/
 #WEITERLEITUNG [[110.3 SSH Authentifizierung mit Schlüsseln]]

=Quellenangaben=

[[Benutzer:Meikschwalm|Meikschwalm]] ([[Benutzer Diskussion:Meikschwalm|Diskussion]]) 21:38, 29. Jul. 2019 (CEST)

[[Category:Linux]]

LPIC102/110.3 Daten durch Kryptografie schützen

2019-07-29T20:06:09Z

Meikschwalm: /* SSH-Konfigurationsdateien */

==SSH Daemon==
* Das Paket openssh-server installiert die serverseitige Komponente von SSH. 
* Folgende Befehle starten unter systemd den SSH Dienst.
# systemctl start sshd.service
# systemctl enable sshd.service

==SSH-Client==
* Die Verbidung startet ssh.
* Host-Namen bzw. die IP-Adresse wird angegeben.
* Anschliessend folgt die Eingabe des Kennwortes.
$ ssh server
root@server's password:

* Zwei Wege um sich mit einem alternativen Benutzerkonto anzumelden:
$ ssh -l willi server
$ ssh willi@server

===Grafische Anwendungen unter X tunneln===

* SSH-Verbindung wird von einem X-Terminal aus mit der zusätzlichen Option -X (großes X) initiiert.

$ ssh -X server

* Auf der Konsole des Remote-Systems führt man die Anwendung aus:

user@server:~ $ libreoffice

* Grafische Ausgabe und Bedienung erfolgt lokal am SSH-Client-Rechner.
* Das hier beschriebene Verfahren wird als X11-Tunnel bezeichnet.
*
===Weiterleitung anderer Ports durch einen SSH-Tunnel.===

* Als Beispiel, der Zugriff auf einen Terminalserver im entfernten Netzwerk hinter einem SSH-Server.

*IP-Adresse des Terminalservers 192.168.50.10 
*Terminalserver lauscht an Port 3389 
*IP des SSH-Server 119.117.63.126

* Zunächst wird die SSH-Verbindung initiiert.

ssh 119.117.63.126 -L 4711:192.168.50.10:3389

*Option -L leitet Port 4711 an 192.168.50.10 mit Portnummer 3389 weiter. 
*Verbindungen werden an 192.168.50.10:3389 weitergeleitet. 
*Terminal-Dienste-Clients (z. B. remmina) nutzen nun als Ziel localhost:4711 

'''Hinweis''' 
Auch vom Windows-Computer aus kann mittels PuTTy auf einen Linux-Host zugegriffen werden. 
Läuft ein X-Server auf dem Windows-Computer (z. B. Xming oder Cygwin), ist auch das Tunneln von Ports inklusive X11 durchführbar. 

#WEITERLEITUNG [[PuTTY - ein freier SSH-Client]]

==SSH-Konfigurationsdateien==

''/etc/ssh/sshd_config''
* Die Konfigurationsdatei sshd_config dient der Konfiguration von sshd, also den SSH-Server.

Port 22
Protocol 2
ListenAddress 192.168.0.58
PermitRootLogin no
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key

Erläuterung:

* sshd verwendet den Standardport 22.
* Ausschließlich SSH-2-Verbindungen.
* Zugriff auf Schnittstelle des Rechners: 192.168.0.58
* Kein login für root.
* Als Hostkey kommen RSA, ECDSA und Ed25519 in Frage.

'''Hinweis''' 
Auf die Authentifizierung mit Schlüsseln und ssh_known_hosts Datei wird später näher eingegangen.
 

''/etc/ssh/ssh_config''
* Die Konfigurationsdatei ssh_config.
* Sie dient der clientseitigen Konfiguration von SSH.

z.B.
* Clientseitige X11-Weiterleitung oder Passwortauthentifizierung
* RSA-Authentifizierung aktiv
* Standardport für ausgehende Verbindungen festlegen
 
Die Optionsnamen innerhalb dieser Datei sind ansonsten selbsterklärend oder in der Manpage nachzuschlagen. 
ACHTUNG! Die beiden gerade besprochenen Dateien kann man aufgrund ihrer Namensähnlichkeit schnell verwechseln.

''/etc/hosts.allow'' und ''/etc/hosts.deny''

''Die beiden Dateien steuern wie die oben beschriebenen Dateien, den Zugriff auf SSH.''

''hosts.allow'' hat Vorrang vor der Datei ''hosts.deny.''
* Wird einem Host der Zugriff auf SSH durch ''hosts.allow'' gewährt, kann das durch keinen Eintrag in hosts.deny zurückgenommen werden.

''/etc/nologin''

* Mit dem erstellen einer leeren Datei namens /etc/nologin lässt sich der Zugriff auf SSH verhindern.
* Nur root kann sich dann noch am System anmelden.
* In dieser Datei kann auch eine Nachricht an Benutzer hinterlassen werden die sich lokal anmelden wollen.

==Wichtigste Wissensgebiete==

* einen OpenSSH-2-Client grundlegend konfigurieren und verwenden
* die Rolle von OpenSSH-2-Rechnerschlüsseln verstehen
* GnuPG grundlegend konfigurieren und verwenden
* GPG verwenden um Dateien zu verschlüsseln, entschlüsseln, signieren und zu überprüfen
* SSH-Port-Tunnel (auch X11-Tunnel) verstehen

==Liste wichtiger Dateien, Verzeichnisse und Anwendungen==

* ssh
* ssh-keygen
* ssh-agent
* ssh-add
* ~/.ssh/id_rsa und id_rsa.pub
* ~/.ssh/id_dsa und id_dsa.pub
* ~/.ssh/id_ecdsa und id_ecdsa.pub
* ~/.ssh/id_ed25519 und id_ed25519.pub
* /etc/ssh/ssh_host_rsa_key und ssh_host_rsa_key.pub
* /etc/ssh/ssh_host_dsa_key und ssh_host_dsa_key.pub
* /etc/ssh/ssh_host_ecdsa_key und ssh_host_ecdsa_key.pub
* /etc/ssh/ssh_host_ed25519_key und ssh_host_ed25519_key.pub
* ~/.ssh/authorized_keys
* ssh_known_hosts
* gpg
* gpg-agent
* ~/.gnupg/
 #WEITERLEITUNG [[110.3 SSH Authentifizierung mit Schlüsseln]]

=Quellenangaben=

[[Benutzer:Meikschwalm|Meikschwalm]] ([[Benutzer Diskussion:Meikschwalm|Diskussion]]) 21:38, 29. Jul. 2019 (CEST)

[[Category:Linux]]

LPIC102/110.3 Daten durch Kryptografie schützen

2019-07-29T20:05:47Z

Meikschwalm: /* SSH-Konfigurationsdateien */

==SSH Daemon==
* Das Paket openssh-server installiert die serverseitige Komponente von SSH. 
* Folgende Befehle starten unter systemd den SSH Dienst.
# systemctl start sshd.service
# systemctl enable sshd.service

==SSH-Client==
* Die Verbidung startet ssh.
* Host-Namen bzw. die IP-Adresse wird angegeben.
* Anschliessend folgt die Eingabe des Kennwortes.
$ ssh server
root@server's password:

* Zwei Wege um sich mit einem alternativen Benutzerkonto anzumelden:
$ ssh -l willi server
$ ssh willi@server

===Grafische Anwendungen unter X tunneln===

* SSH-Verbindung wird von einem X-Terminal aus mit der zusätzlichen Option -X (großes X) initiiert.

$ ssh -X server

* Auf der Konsole des Remote-Systems führt man die Anwendung aus:

user@server:~ $ libreoffice

* Grafische Ausgabe und Bedienung erfolgt lokal am SSH-Client-Rechner.
* Das hier beschriebene Verfahren wird als X11-Tunnel bezeichnet.
*
===Weiterleitung anderer Ports durch einen SSH-Tunnel.===

* Als Beispiel, der Zugriff auf einen Terminalserver im entfernten Netzwerk hinter einem SSH-Server.

*IP-Adresse des Terminalservers 192.168.50.10 
*Terminalserver lauscht an Port 3389 
*IP des SSH-Server 119.117.63.126

* Zunächst wird die SSH-Verbindung initiiert.

ssh 119.117.63.126 -L 4711:192.168.50.10:3389

*Option -L leitet Port 4711 an 192.168.50.10 mit Portnummer 3389 weiter. 
*Verbindungen werden an 192.168.50.10:3389 weitergeleitet. 
*Terminal-Dienste-Clients (z. B. remmina) nutzen nun als Ziel localhost:4711 

'''Hinweis''' 
Auch vom Windows-Computer aus kann mittels PuTTy auf einen Linux-Host zugegriffen werden. 
Läuft ein X-Server auf dem Windows-Computer (z. B. Xming oder Cygwin), ist auch das Tunneln von Ports inklusive X11 durchführbar. 

#WEITERLEITUNG [[PuTTY - ein freier SSH-Client]]

==SSH-Konfigurationsdateien==

''/etc/ssh/sshd_config''
* Die Konfigurationsdatei sshd_config dient der Konfiguration von sshd, also den SSH-Server.

Port 22
Protocol 2
ListenAddress 192.168.0.58
PermitRootLogin no
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key

Erläuterung:

* sshd verwendet den Standardport 22.
* Ausschließlich SSH-2-Verbindungen.
* Zugriff auf Schnittstelle des Rechners: 192.168.0.58
* Kein login für root.
* Als Hostkey kommen RSA, ECDSA und Ed25519 in Frage.

'''Hinweis''' 
Auf die Authentifizierung mit Schlüsseln und ssh_known_hosts Datei wird später näher eingegangen.
 

''/etc/ssh/ssh_config''
* Die Konfigurationsdatei ssh_config.
* Sie dient der clientseitigen Konfiguration von SSH.

z.B.
* Clientseitige X11-Weiterleitung oder Passwortauthentifizierung
* RSA-Authentifizierung aktiv
* Standardport für ausgehende Verbindungen festlegen
 
Die Optionsnamen innerhalb dieser Datei sind ansonsten selbsterklärend oder in der Manpage nachzuschlagen. 
ACHTUNG! Die beiden gerade besprochenen Dateien kann man aufgrund ihrer Namensähnlichkeit schnell verwechseln.

''/etc/hosts.allow'' und ''/etc/hosts.deny''

''Die beiden Dateien steuern wie die oben beschriebenen Dateien, den Zugriff auf SSH.''

''hosts.allow'' hat Vorrang vor der Datei ''hosts.deny.''
* Wird einem Host der Zugriff auf SSH durch ''hosts.allow'' gewährt, kann das durch keinen Eintrag in hosts.deny zurückgenommen werden.

''/etc/nologin''

* Mit dem erstellen einer leeren Datei namens /etc/nologin lässt sich der Zugriff auf SSH verhindern.
* Nur root kann sich dann noch am System anmelden.
* In dieser Datei kann auch eine Nachricht an Benutzer hinterlassen werden die sich lokal anmelden wollen.

==Wichtigste Wissensgebiete==

* einen OpenSSH-2-Client grundlegend konfigurieren und verwenden
* die Rolle von OpenSSH-2-Rechnerschlüsseln verstehen
* GnuPG grundlegend konfigurieren und verwenden
* GPG verwenden um Dateien zu verschlüsseln, entschlüsseln, signieren und zu überprüfen
* SSH-Port-Tunnel (auch X11-Tunnel) verstehen

==Liste wichtiger Dateien, Verzeichnisse und Anwendungen==

* ssh
* ssh-keygen
* ssh-agent
* ssh-add
* ~/.ssh/id_rsa und id_rsa.pub
* ~/.ssh/id_dsa und id_dsa.pub
* ~/.ssh/id_ecdsa und id_ecdsa.pub
* ~/.ssh/id_ed25519 und id_ed25519.pub
* /etc/ssh/ssh_host_rsa_key und ssh_host_rsa_key.pub
* /etc/ssh/ssh_host_dsa_key und ssh_host_dsa_key.pub
* /etc/ssh/ssh_host_ecdsa_key und ssh_host_ecdsa_key.pub
* /etc/ssh/ssh_host_ed25519_key und ssh_host_ed25519_key.pub
* ~/.ssh/authorized_keys
* ssh_known_hosts
* gpg
* gpg-agent
* ~/.gnupg/
 #WEITERLEITUNG [[110.3 SSH Authentifizierung mit Schlüsseln]]

=Quellenangaben=

[[Benutzer:Meikschwalm|Meikschwalm]] ([[Benutzer Diskussion:Meikschwalm|Diskussion]]) 21:38, 29. Jul. 2019 (CEST)

[[Category:Linux]]

LPIC102/110.3 Daten durch Kryptografie schützen

2019-07-29T20:03:46Z

Meikschwalm: /* SSH-Konfigurationsdateien */

==SSH Daemon==
* Das Paket openssh-server installiert die serverseitige Komponente von SSH. 
* Folgende Befehle starten unter systemd den SSH Dienst.
# systemctl start sshd.service
# systemctl enable sshd.service

==SSH-Client==
* Die Verbidung startet ssh.
* Host-Namen bzw. die IP-Adresse wird angegeben.
* Anschliessend folgt die Eingabe des Kennwortes.
$ ssh server
root@server's password:

* Zwei Wege um sich mit einem alternativen Benutzerkonto anzumelden:
$ ssh -l willi server
$ ssh willi@server

===Grafische Anwendungen unter X tunneln===

* SSH-Verbindung wird von einem X-Terminal aus mit der zusätzlichen Option -X (großes X) initiiert.

$ ssh -X server

* Auf der Konsole des Remote-Systems führt man die Anwendung aus:

user@server:~ $ libreoffice

* Grafische Ausgabe und Bedienung erfolgt lokal am SSH-Client-Rechner.
* Das hier beschriebene Verfahren wird als X11-Tunnel bezeichnet.
*
===Weiterleitung anderer Ports durch einen SSH-Tunnel.===

* Als Beispiel, der Zugriff auf einen Terminalserver im entfernten Netzwerk hinter einem SSH-Server.

*IP-Adresse des Terminalservers 192.168.50.10 
*Terminalserver lauscht an Port 3389 
*IP des SSH-Server 119.117.63.126

* Zunächst wird die SSH-Verbindung initiiert.

ssh 119.117.63.126 -L 4711:192.168.50.10:3389

*Option -L leitet Port 4711 an 192.168.50.10 mit Portnummer 3389 weiter. 
*Verbindungen werden an 192.168.50.10:3389 weitergeleitet. 
*Terminal-Dienste-Clients (z. B. remmina) nutzen nun als Ziel localhost:4711 

'''Hinweis''' 
Auch vom Windows-Computer aus kann mittels PuTTy auf einen Linux-Host zugegriffen werden. 
Läuft ein X-Server auf dem Windows-Computer (z. B. Xming oder Cygwin), ist auch das Tunneln von Ports inklusive X11 durchführbar. 

#WEITERLEITUNG [[PuTTY - ein freier SSH-Client]]

==SSH-Konfigurationsdateien==

''/etc/ssh/sshd_config''
* Die Konfigurationsdatei sshd_config dient der Konfiguration von sshd, also den SSH-Server.

Port 22
Protocol 2
ListenAddress 192.168.0.58
PermitRootLogin no
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key

Erläuterung:

* sshd verwendet den Standardport 22.
* Ausschließlich SSH-2-Verbindungen.
* Zugriff auf Schnittstelle des Rechners: 192.168.0.58
* Kein login für root.
* Als Hostkey kommen RSA, ECDSA und Ed25519 in Frage.

'''Hinweis''' 
Auf die Authentifizierung mit Schlüsseln und ssh_known_hosts Datei wird später näher eingegangen.
 
''/etc/ssh/ssh_config''
* Die Konfigurationsdatei ssh_config.
* Sie dient der clientseitigen Konfiguration von SSH.

z.B.
* Clientseitige X11-Weiterleitung oder Passwortauthentifizierung
* RSA-Authentifizierung aktiv
* Standardport für ausgehende Verbindungen festlegen
 
Die Optionsnamen innerhalb dieser Datei sind ansonsten selbsterklärend oder in der Manpage nachzuschlagen. 
ACHTUNG! Die beiden gerade besprochenen Dateien kann man aufgrund ihrer Namensähnlichkeit schnell verwechseln.

''/etc/hosts.allow'' und ''/etc/hosts.deny''

''Die beiden Dateien steuern wie die oben beschriebenen Dateien, den Zugriff auf SSH.''

''hosts.allow'' hat Vorrang vor der Datei ''hosts.deny.''
* Wird einem Host der Zugriff auf SSH durch ''hosts.allow'' gewährt, kann das durch keinen Eintrag in hosts.deny zurückgenommen werden.

''/etc/nologin''

* Mit dem erstellen einer leeren Datei namens /etc/nologin lässt sich der Zugriff auf SSH verhindern.
* Nur root kann sich dann noch am System anmelden.
* In dieser Datei kann auch eine Nachricht an Benutzer hinterlassen werden die sich lokal anmelden wollen.

==Wichtigste Wissensgebiete==

* einen OpenSSH-2-Client grundlegend konfigurieren und verwenden
* die Rolle von OpenSSH-2-Rechnerschlüsseln verstehen
* GnuPG grundlegend konfigurieren und verwenden
* GPG verwenden um Dateien zu verschlüsseln, entschlüsseln, signieren und zu überprüfen
* SSH-Port-Tunnel (auch X11-Tunnel) verstehen

==Liste wichtiger Dateien, Verzeichnisse und Anwendungen==

* ssh
* ssh-keygen
* ssh-agent
* ssh-add
* ~/.ssh/id_rsa und id_rsa.pub
* ~/.ssh/id_dsa und id_dsa.pub
* ~/.ssh/id_ecdsa und id_ecdsa.pub
* ~/.ssh/id_ed25519 und id_ed25519.pub
* /etc/ssh/ssh_host_rsa_key und ssh_host_rsa_key.pub
* /etc/ssh/ssh_host_dsa_key und ssh_host_dsa_key.pub
* /etc/ssh/ssh_host_ecdsa_key und ssh_host_ecdsa_key.pub
* /etc/ssh/ssh_host_ed25519_key und ssh_host_ed25519_key.pub
* ~/.ssh/authorized_keys
* ssh_known_hosts
* gpg
* gpg-agent
* ~/.gnupg/
 #WEITERLEITUNG [[110.3 SSH Authentifizierung mit Schlüsseln]]

=Quellenangaben=

[[Benutzer:Meikschwalm|Meikschwalm]] ([[Benutzer Diskussion:Meikschwalm|Diskussion]]) 21:38, 29. Jul. 2019 (CEST)

[[Category:Linux]]

LPIC102/110.3 Daten durch Kryptografie schützen

2019-07-29T20:03:04Z

Meikschwalm: /* SSH-Konfigurationsdateien */

==SSH Daemon==
* Das Paket openssh-server installiert die serverseitige Komponente von SSH. 
* Folgende Befehle starten unter systemd den SSH Dienst.
# systemctl start sshd.service
# systemctl enable sshd.service

==SSH-Client==
* Die Verbidung startet ssh.
* Host-Namen bzw. die IP-Adresse wird angegeben.
* Anschliessend folgt die Eingabe des Kennwortes.
$ ssh server
root@server's password:

* Zwei Wege um sich mit einem alternativen Benutzerkonto anzumelden:
$ ssh -l willi server
$ ssh willi@server

===Grafische Anwendungen unter X tunneln===

* SSH-Verbindung wird von einem X-Terminal aus mit der zusätzlichen Option -X (großes X) initiiert.

$ ssh -X server

* Auf der Konsole des Remote-Systems führt man die Anwendung aus:

user@server:~ $ libreoffice

* Grafische Ausgabe und Bedienung erfolgt lokal am SSH-Client-Rechner.
* Das hier beschriebene Verfahren wird als X11-Tunnel bezeichnet.
*
===Weiterleitung anderer Ports durch einen SSH-Tunnel.===

* Als Beispiel, der Zugriff auf einen Terminalserver im entfernten Netzwerk hinter einem SSH-Server.

*IP-Adresse des Terminalservers 192.168.50.10 
*Terminalserver lauscht an Port 3389 
*IP des SSH-Server 119.117.63.126

* Zunächst wird die SSH-Verbindung initiiert.

ssh 119.117.63.126 -L 4711:192.168.50.10:3389

*Option -L leitet Port 4711 an 192.168.50.10 mit Portnummer 3389 weiter. 
*Verbindungen werden an 192.168.50.10:3389 weitergeleitet. 
*Terminal-Dienste-Clients (z. B. remmina) nutzen nun als Ziel localhost:4711 

'''Hinweis''' 
Auch vom Windows-Computer aus kann mittels PuTTy auf einen Linux-Host zugegriffen werden. 
Läuft ein X-Server auf dem Windows-Computer (z. B. Xming oder Cygwin), ist auch das Tunneln von Ports inklusive X11 durchführbar. 

#WEITERLEITUNG [[PuTTY - ein freier SSH-Client]]

==SSH-Konfigurationsdateien==

/etc/ssh/sshd_config
* Die Konfigurationsdatei sshd_config dient der Konfiguration von sshd, also den SSH-Server.

Port 22
Protocol 2
ListenAddress 192.168.0.58
PermitRootLogin no
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key

Erläuterung:

* sshd verwendet den Standardport 22.
* Ausschließlich SSH-2-Verbindungen.
* Zugriff auf Schnittstelle des Rechners: 192.168.0.58
* Kein login für root.
* Als Hostkey kommen RSA, ECDSA und Ed25519 in Frage.

'''Hinweis''' 
Auf die Authentifizierung mit Schlüsseln und ssh_known_hosts Datei wird später näher eingegangen.
 
''/etc/ssh/ssh_config''
* Die Konfigurationsdatei ssh_config.
* Sie dient der clientseitigen Konfiguration von SSH.

z.B.
* Clientseitige X11-Weiterleitung oder Passwortauthentifizierung
* RSA-Authentifizierung aktiv
* Standardport für ausgehende Verbindungen festlegen
 
Die Optionsnamen innerhalb dieser Datei sind ansonsten selbsterklärend oder in der Manpage nachzuschlagen. 
ACHTUNG! Die beiden gerade besprochenen Dateien kann man aufgrund ihrer Namensähnlichkeit schnell verwechseln.

''/etc/hosts.allow'' und ''/etc/hosts.deny''

''Die beiden Dateien steuern wie die oben beschriebenen Dateien, den Zugriff auf SSH.''

''hosts.allow'' hat Vorrang vor der Datei ''hosts.deny.''
* Wird einem Host der Zugriff auf SSH durch ''hosts.allow'' gewährt, kann das durch keinen Eintrag in hosts.deny zurückgenommen werden.

''/etc/nologin''

* Mit dem erstellen einer leeren Datei namens /etc/nologin lässt sich der Zugriff auf SSH verhindern.
* Nur root kann sich dann noch am System anmelden.
* In dieser Datei kann auch eine Nachricht an Benutzer hinterlassen werden die sich lokal anmelden wollen.

==Wichtigste Wissensgebiete==

* einen OpenSSH-2-Client grundlegend konfigurieren und verwenden
* die Rolle von OpenSSH-2-Rechnerschlüsseln verstehen
* GnuPG grundlegend konfigurieren und verwenden
* GPG verwenden um Dateien zu verschlüsseln, entschlüsseln, signieren und zu überprüfen
* SSH-Port-Tunnel (auch X11-Tunnel) verstehen

==Liste wichtiger Dateien, Verzeichnisse und Anwendungen==

* ssh
* ssh-keygen
* ssh-agent
* ssh-add
* ~/.ssh/id_rsa und id_rsa.pub
* ~/.ssh/id_dsa und id_dsa.pub
* ~/.ssh/id_ecdsa und id_ecdsa.pub
* ~/.ssh/id_ed25519 und id_ed25519.pub
* /etc/ssh/ssh_host_rsa_key und ssh_host_rsa_key.pub
* /etc/ssh/ssh_host_dsa_key und ssh_host_dsa_key.pub
* /etc/ssh/ssh_host_ecdsa_key und ssh_host_ecdsa_key.pub
* /etc/ssh/ssh_host_ed25519_key und ssh_host_ed25519_key.pub
* ~/.ssh/authorized_keys
* ssh_known_hosts
* gpg
* gpg-agent
* ~/.gnupg/
 #WEITERLEITUNG [[110.3 SSH Authentifizierung mit Schlüsseln]]

=Quellenangaben=

[[Benutzer:Meikschwalm|Meikschwalm]] ([[Benutzer Diskussion:Meikschwalm|Diskussion]]) 21:38, 29. Jul. 2019 (CEST)

[[Category:Linux]]

LPIC102/110.3 Daten durch Kryptografie schützen

2019-07-29T19:50:34Z

Meikschwalm:

==SSH Daemon==
* Das Paket openssh-server installiert die serverseitige Komponente von SSH. 
* Folgende Befehle starten unter systemd den SSH Dienst.
# systemctl start sshd.service
# systemctl enable sshd.service

==SSH-Client==
* Die Verbidung startet ssh.
* Host-Namen bzw. die IP-Adresse wird angegeben.
* Anschliessend folgt die Eingabe des Kennwortes.
$ ssh server
root@server's password:

* Zwei Wege um sich mit einem alternativen Benutzerkonto anzumelden:
$ ssh -l willi server
$ ssh willi@server

===Grafische Anwendungen unter X tunneln===

* SSH-Verbindung wird von einem X-Terminal aus mit der zusätzlichen Option -X (großes X) initiiert.

$ ssh -X server

* Auf der Konsole des Remote-Systems führt man die Anwendung aus:

user@server:~ $ libreoffice

* Grafische Ausgabe und Bedienung erfolgt lokal am SSH-Client-Rechner.
* Das hier beschriebene Verfahren wird als X11-Tunnel bezeichnet.
*
===Weiterleitung anderer Ports durch einen SSH-Tunnel.===

* Als Beispiel, der Zugriff auf einen Terminalserver im entfernten Netzwerk hinter einem SSH-Server.

*IP-Adresse des Terminalservers 192.168.50.10 
*Terminalserver lauscht an Port 3389 
*IP des SSH-Server 119.117.63.126

* Zunächst wird die SSH-Verbindung initiiert.

ssh 119.117.63.126 -L 4711:192.168.50.10:3389

*Option -L leitet Port 4711 an 192.168.50.10 mit Portnummer 3389 weiter. 
*Verbindungen werden an 192.168.50.10:3389 weitergeleitet. 
*Terminal-Dienste-Clients (z. B. remmina) nutzen nun als Ziel localhost:4711 

'''Hinweis''' 
Auch vom Windows-Computer aus kann mittels PuTTy auf einen Linux-Host zugegriffen werden. 
Läuft ein X-Server auf dem Windows-Computer (z. B. Xming oder Cygwin), ist auch das Tunneln von Ports inklusive X11 durchführbar. 

#WEITERLEITUNG [[PuTTY - ein freier SSH-Client]]

==SSH-Konfigurationsdateien==

/etc/ssh/sshd_config
Die Konfigurationsdatei sshd_config dient der Konfiguration von sshd, also den SSH-Server. 

Port 22
Protocol 2
ListenAddress 192.168.0.58
PermitRootLogin no
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key

Erläuterung:

* sshd verwendet den Standardport 22.
* Ausschließlich SSH-2-Verbindungen.
* Zugriff auf Schnittstelle des Rechners: 192.168.0.58
* Kein login für root.
* Als Hostkey kommen RSA, ECDSA und Ed25519 in Frage.

'''Hinweis''' 
Der Authentifizierung mit Schlüsseln und ssh_known_hosts Datei, wird unter [[SSH Authentifizierung mit Schlüsseln]] ein separater Abschnitt gewidmet, weil sie ausdrücklich als Prüfungsthema genannt sind.
 
/etc/ssh/ssh_config
Die Konfigurationsdatei ssh_config dient der clientseitigen Konfiguration von SSH.

z.B.
* Clientseitige X11-Weiterleitung oder Passwortauthentifizierung
* RSA-Authentifizierung aktiv
* Standardport für ausgehende Verbindungen festlegen
 
Die Optionsnamen innerhalb dieser Datei sind ansonsten selbsterklärend oder in der Manpage nachzuschlagen. 
ACHTUNG! Die beiden gerade besprochenen Dateien kann man aufgrund ihrer Namensähnlichkeit schnell verwechseln.

/etc/hosts.allow und /etc/hosts.deny

Die Dateien /etc/hosts.allow und /etc/hosts.deny steuern wie die oben beschriebenen Dateien, den Zugriff auf SSH. 

Wichtig für die Prüfung:
Die Datei hosts.allow hat Vorrang vor der Datei hosts.deny. 
Wird einem Host der Zugriff auf SSH durch hosts.allow gewährt, kann das durch keinen Eintrag in hosts.deny zurückgenommen werden.

/etc/nologin

Mit dem erstellen einer leeren Datei namens /etc/nologin lässt sich der Zugriff auf SSH verhindern. 
Nur root kann sich dann noch am System anmelden. 
In dieser Datei kann auch eine Nachricht an Benutzer hinterlassen werden die sich lokal anmelden wollen.

==Wichtigste Wissensgebiete==

* einen OpenSSH-2-Client grundlegend konfigurieren und verwenden
* die Rolle von OpenSSH-2-Rechnerschlüsseln verstehen
* GnuPG grundlegend konfigurieren und verwenden
* GPG verwenden um Dateien zu verschlüsseln, entschlüsseln, signieren und zu überprüfen
* SSH-Port-Tunnel (auch X11-Tunnel) verstehen

==Liste wichtiger Dateien, Verzeichnisse und Anwendungen==

* ssh
* ssh-keygen
* ssh-agent
* ssh-add
* ~/.ssh/id_rsa und id_rsa.pub
* ~/.ssh/id_dsa und id_dsa.pub
* ~/.ssh/id_ecdsa und id_ecdsa.pub
* ~/.ssh/id_ed25519 und id_ed25519.pub
* /etc/ssh/ssh_host_rsa_key und ssh_host_rsa_key.pub
* /etc/ssh/ssh_host_dsa_key und ssh_host_dsa_key.pub
* /etc/ssh/ssh_host_ecdsa_key und ssh_host_ecdsa_key.pub
* /etc/ssh/ssh_host_ed25519_key und ssh_host_ed25519_key.pub
* ~/.ssh/authorized_keys
* ssh_known_hosts
* gpg
* gpg-agent
* ~/.gnupg/
 #WEITERLEITUNG [[110.3 SSH Authentifizierung mit Schlüsseln]]

=Quellenangaben=

[[Benutzer:Meikschwalm|Meikschwalm]] ([[Benutzer Diskussion:Meikschwalm|Diskussion]]) 21:38, 29. Jul. 2019 (CEST)

[[Category:Linux]]

LPIC102/110.3 Daten durch Kryptografie schützen

2019-07-29T19:39:34Z

Meikschwalm: /* Liste wichtiger Dateien, Verzeichnisse und Anwendungen */

==SSH Daemon==
Das Paket openssh-server installiert die serverseitige Komponente von SSH. 
Folgende Befehle starten unter systemd den SSH Dienst.
# systemctl start sshd.service
# systemctl enable sshd.service

==SSH-Client==
Um eine Verbindung zwischen zwei Linux-Systemen aufzubauen, startet man ssh und übergibt den Host-Namen bzw. die IP-Adresse. 
Anschliessend folgt die Eingabe eines Kennwortes:
$ ssh server
root@server's password:

Möchte man sich nicht mit seinem lokalen Benutzerkonto anmelden, gibt es zwei Wege:
$ ssh -l willi server
$ ssh willi@server

===Grafische Anwendungen unter X tunneln===

Zuerst wird die SSH-Verbindung von einem X-Terminal aus mit der zusätzlichen Option -X (großes X) initiiert. 

$ ssh -X server

Auf der Konsole des Remote-Systems führt man die Anwendung aus:

user@server:~ $ libreoffice

Die grafische Ausgabe und die Bedienung erfolgt lokal am SSH-Client-Rechner.
Das hier beschriebene Verfahren wird als X11-Tunnel bezeichnet.

===Weiterleitung anderer Ports durch einen SSH-Tunnel.===

Als Beispiel, der Zugriff auf einen Terminalserver im entfernten Netzwerk hinter einem SSH-Server. 

*IP-Adresse des Terminalservers 192.168.50.10 
*Terminalserver lauscht an Port 3389 
*IP des SSH-Server 119.117.63.126

Zunächst wird die SSH-Verbindung initiiert:

ssh 119.117.63.126 -L 4711:192.168.50.10:3389

*Option -L leitet Port 4711 an 192.168.50.10 mit Portnummer 3389 weiter. 
*Verbindungen werden an 192.168.50.10:3389 weitergeleitet. 
*Terminal-Dienste-Clients (z. B. remmina) nutzen nun als Ziel localhost:4711 

'''Hinweis''' 
Auch vom Windows-Computer aus kann mittels PuTTy auf einen Linux-Host zugegriffen werden. 
Läuft ein X-Server auf dem Windows-Computer (z. B. Xming oder Cygwin), ist auch das Tunneln von Ports inklusive X11 durchführbar. 

Wiki Artikel zu PuTTy 
[[PuTTY - ein freier SSH-Client]]

==SSH-Konfigurationsdateien==

/etc/ssh/sshd_config
Die Konfigurationsdatei sshd_config dient der Konfiguration von sshd, also den SSH-Server. 

Port 22
Protocol 2
ListenAddress 192.168.0.58
PermitRootLogin no
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key

Erläuterung:

* sshd verwendet den Standardport 22.
* Ausschließlich SSH-2-Verbindungen.
* Zugriff auf Schnittstelle des Rechners: 192.168.0.58
* Kein login für root.
* Als Hostkey kommen RSA, ECDSA und Ed25519 in Frage.

'''Hinweis''' 
Der Authentifizierung mit Schlüsseln und ssh_known_hosts Datei, wird unter [[SSH Authentifizierung mit Schlüsseln]] ein separater Abschnitt gewidmet, weil sie ausdrücklich als Prüfungsthema genannt sind.
 
/etc/ssh/ssh_config
Die Konfigurationsdatei ssh_config dient der clientseitigen Konfiguration von SSH.

z.B.
* Clientseitige X11-Weiterleitung oder Passwortauthentifizierung
* RSA-Authentifizierung aktiv
* Standardport für ausgehende Verbindungen festlegen
 
Die Optionsnamen innerhalb dieser Datei sind ansonsten selbsterklärend oder in der Manpage nachzuschlagen. 
ACHTUNG! Die beiden gerade besprochenen Dateien kann man aufgrund ihrer Namensähnlichkeit schnell verwechseln.

/etc/hosts.allow und /etc/hosts.deny

Die Dateien /etc/hosts.allow und /etc/hosts.deny steuern wie die oben beschriebenen Dateien, den Zugriff auf SSH. 

Wichtig für die Prüfung:
Die Datei hosts.allow hat Vorrang vor der Datei hosts.deny. 
Wird einem Host der Zugriff auf SSH durch hosts.allow gewährt, kann das durch keinen Eintrag in hosts.deny zurückgenommen werden.

/etc/nologin

Mit dem erstellen einer leeren Datei namens /etc/nologin lässt sich der Zugriff auf SSH verhindern. 
Nur root kann sich dann noch am System anmelden. 
In dieser Datei kann auch eine Nachricht an Benutzer hinterlassen werden die sich lokal anmelden wollen.

==Wichtigste Wissensgebiete==

* einen OpenSSH-2-Client grundlegend konfigurieren und verwenden
* die Rolle von OpenSSH-2-Rechnerschlüsseln verstehen
* GnuPG grundlegend konfigurieren und verwenden
* GPG verwenden um Dateien zu verschlüsseln, entschlüsseln, signieren und zu überprüfen
* SSH-Port-Tunnel (auch X11-Tunnel) verstehen

==Liste wichtiger Dateien, Verzeichnisse und Anwendungen==

* ssh
* ssh-keygen
* ssh-agent
* ssh-add
* ~/.ssh/id_rsa und id_rsa.pub
* ~/.ssh/id_dsa und id_dsa.pub
* ~/.ssh/id_ecdsa und id_ecdsa.pub
* ~/.ssh/id_ed25519 und id_ed25519.pub
* /etc/ssh/ssh_host_rsa_key und ssh_host_rsa_key.pub
* /etc/ssh/ssh_host_dsa_key und ssh_host_dsa_key.pub
* /etc/ssh/ssh_host_ecdsa_key und ssh_host_ecdsa_key.pub
* /etc/ssh/ssh_host_ed25519_key und ssh_host_ed25519_key.pub
* ~/.ssh/authorized_keys
* ssh_known_hosts
* gpg
* gpg-agent
* ~/.gnupg/
 #WEITERLEITUNG [[110.3 SSH Authentifizierung mit Schlüsseln]]

=Quellenangaben=

[[Benutzer:Meikschwalm|Meikschwalm]] ([[Benutzer Diskussion:Meikschwalm|Diskussion]]) 21:38, 29. Jul. 2019 (CEST)

[[Category:Linux]]

LPIC102/110.3 Daten durch Kryptografie schützen

2019-07-29T19:39:16Z

Meikschwalm: /* Liste wichtiger Dateien, Verzeichnisse und Anwendungen */

==SSH Daemon==
Das Paket openssh-server installiert die serverseitige Komponente von SSH. 
Folgende Befehle starten unter systemd den SSH Dienst.
# systemctl start sshd.service
# systemctl enable sshd.service

==SSH-Client==
Um eine Verbindung zwischen zwei Linux-Systemen aufzubauen, startet man ssh und übergibt den Host-Namen bzw. die IP-Adresse. 
Anschliessend folgt die Eingabe eines Kennwortes:
$ ssh server
root@server's password:

Möchte man sich nicht mit seinem lokalen Benutzerkonto anmelden, gibt es zwei Wege:
$ ssh -l willi server
$ ssh willi@server

===Grafische Anwendungen unter X tunneln===

Zuerst wird die SSH-Verbindung von einem X-Terminal aus mit der zusätzlichen Option -X (großes X) initiiert. 

$ ssh -X server

Auf der Konsole des Remote-Systems führt man die Anwendung aus:

user@server:~ $ libreoffice

Die grafische Ausgabe und die Bedienung erfolgt lokal am SSH-Client-Rechner.
Das hier beschriebene Verfahren wird als X11-Tunnel bezeichnet.

===Weiterleitung anderer Ports durch einen SSH-Tunnel.===

Als Beispiel, der Zugriff auf einen Terminalserver im entfernten Netzwerk hinter einem SSH-Server. 

*IP-Adresse des Terminalservers 192.168.50.10 
*Terminalserver lauscht an Port 3389 
*IP des SSH-Server 119.117.63.126

Zunächst wird die SSH-Verbindung initiiert:

ssh 119.117.63.126 -L 4711:192.168.50.10:3389

*Option -L leitet Port 4711 an 192.168.50.10 mit Portnummer 3389 weiter. 
*Verbindungen werden an 192.168.50.10:3389 weitergeleitet. 
*Terminal-Dienste-Clients (z. B. remmina) nutzen nun als Ziel localhost:4711 

'''Hinweis''' 
Auch vom Windows-Computer aus kann mittels PuTTy auf einen Linux-Host zugegriffen werden. 
Läuft ein X-Server auf dem Windows-Computer (z. B. Xming oder Cygwin), ist auch das Tunneln von Ports inklusive X11 durchführbar. 

Wiki Artikel zu PuTTy 
[[PuTTY - ein freier SSH-Client]]

==SSH-Konfigurationsdateien==

/etc/ssh/sshd_config
Die Konfigurationsdatei sshd_config dient der Konfiguration von sshd, also den SSH-Server. 

Port 22
Protocol 2
ListenAddress 192.168.0.58
PermitRootLogin no
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key

Erläuterung:

* sshd verwendet den Standardport 22.
* Ausschließlich SSH-2-Verbindungen.
* Zugriff auf Schnittstelle des Rechners: 192.168.0.58
* Kein login für root.
* Als Hostkey kommen RSA, ECDSA und Ed25519 in Frage.

'''Hinweis''' 
Der Authentifizierung mit Schlüsseln und ssh_known_hosts Datei, wird unter [[SSH Authentifizierung mit Schlüsseln]] ein separater Abschnitt gewidmet, weil sie ausdrücklich als Prüfungsthema genannt sind.
 
/etc/ssh/ssh_config
Die Konfigurationsdatei ssh_config dient der clientseitigen Konfiguration von SSH.

z.B.
* Clientseitige X11-Weiterleitung oder Passwortauthentifizierung
* RSA-Authentifizierung aktiv
* Standardport für ausgehende Verbindungen festlegen
 
Die Optionsnamen innerhalb dieser Datei sind ansonsten selbsterklärend oder in der Manpage nachzuschlagen. 
ACHTUNG! Die beiden gerade besprochenen Dateien kann man aufgrund ihrer Namensähnlichkeit schnell verwechseln.

/etc/hosts.allow und /etc/hosts.deny

Die Dateien /etc/hosts.allow und /etc/hosts.deny steuern wie die oben beschriebenen Dateien, den Zugriff auf SSH. 

Wichtig für die Prüfung:
Die Datei hosts.allow hat Vorrang vor der Datei hosts.deny. 
Wird einem Host der Zugriff auf SSH durch hosts.allow gewährt, kann das durch keinen Eintrag in hosts.deny zurückgenommen werden.

/etc/nologin

Mit dem erstellen einer leeren Datei namens /etc/nologin lässt sich der Zugriff auf SSH verhindern. 
Nur root kann sich dann noch am System anmelden. 
In dieser Datei kann auch eine Nachricht an Benutzer hinterlassen werden die sich lokal anmelden wollen.

==Wichtigste Wissensgebiete==

* einen OpenSSH-2-Client grundlegend konfigurieren und verwenden
* die Rolle von OpenSSH-2-Rechnerschlüsseln verstehen
* GnuPG grundlegend konfigurieren und verwenden
* GPG verwenden um Dateien zu verschlüsseln, entschlüsseln, signieren und zu überprüfen
* SSH-Port-Tunnel (auch X11-Tunnel) verstehen

==Liste wichtiger Dateien, Verzeichnisse und Anwendungen==

* ssh
* ssh-keygen
* ssh-agent
* ssh-add
* ~/.ssh/id_rsa und id_rsa.pub
* ~/.ssh/id_dsa und id_dsa.pub
* ~/.ssh/id_ecdsa und id_ecdsa.pub
* ~/.ssh/id_ed25519 und id_ed25519.pub
* /etc/ssh/ssh_host_rsa_key und ssh_host_rsa_key.pub
* /etc/ssh/ssh_host_dsa_key und ssh_host_dsa_key.pub
* /etc/ssh/ssh_host_ecdsa_key und ssh_host_ecdsa_key.pub
* /etc/ssh/ssh_host_ed25519_key und ssh_host_ed25519_key.pub
* ~/.ssh/authorized_keys
* ssh_known_hosts
* gpg
* gpg-agent
* ~/.gnupg/

#WEITERLEITUNG [[110.3 SSH Authentifizierung mit Schlüsseln]]

=Quellenangaben=

[[Benutzer:Meikschwalm|Meikschwalm]] ([[Benutzer Diskussion:Meikschwalm|Diskussion]]) 21:38, 29. Jul. 2019 (CEST)

[[Category:Linux]]

LPIC102/110.3 Daten durch Kryptografie schützen

2019-07-29T19:39:00Z

Meikschwalm: /* Liste wichtiger Dateien, Verzeichnisse und Anwendungen */

==SSH Daemon==
Das Paket openssh-server installiert die serverseitige Komponente von SSH. 
Folgende Befehle starten unter systemd den SSH Dienst.
# systemctl start sshd.service
# systemctl enable sshd.service

==SSH-Client==
Um eine Verbindung zwischen zwei Linux-Systemen aufzubauen, startet man ssh und übergibt den Host-Namen bzw. die IP-Adresse. 
Anschliessend folgt die Eingabe eines Kennwortes:
$ ssh server
root@server's password:

Möchte man sich nicht mit seinem lokalen Benutzerkonto anmelden, gibt es zwei Wege:
$ ssh -l willi server
$ ssh willi@server

===Grafische Anwendungen unter X tunneln===

Zuerst wird die SSH-Verbindung von einem X-Terminal aus mit der zusätzlichen Option -X (großes X) initiiert. 

$ ssh -X server

Auf der Konsole des Remote-Systems führt man die Anwendung aus:

user@server:~ $ libreoffice

Die grafische Ausgabe und die Bedienung erfolgt lokal am SSH-Client-Rechner.
Das hier beschriebene Verfahren wird als X11-Tunnel bezeichnet.

===Weiterleitung anderer Ports durch einen SSH-Tunnel.===

Als Beispiel, der Zugriff auf einen Terminalserver im entfernten Netzwerk hinter einem SSH-Server. 

*IP-Adresse des Terminalservers 192.168.50.10 
*Terminalserver lauscht an Port 3389 
*IP des SSH-Server 119.117.63.126

Zunächst wird die SSH-Verbindung initiiert:

ssh 119.117.63.126 -L 4711:192.168.50.10:3389

*Option -L leitet Port 4711 an 192.168.50.10 mit Portnummer 3389 weiter. 
*Verbindungen werden an 192.168.50.10:3389 weitergeleitet. 
*Terminal-Dienste-Clients (z. B. remmina) nutzen nun als Ziel localhost:4711 

'''Hinweis''' 
Auch vom Windows-Computer aus kann mittels PuTTy auf einen Linux-Host zugegriffen werden. 
Läuft ein X-Server auf dem Windows-Computer (z. B. Xming oder Cygwin), ist auch das Tunneln von Ports inklusive X11 durchführbar. 

Wiki Artikel zu PuTTy 
[[PuTTY - ein freier SSH-Client]]

==SSH-Konfigurationsdateien==

/etc/ssh/sshd_config
Die Konfigurationsdatei sshd_config dient der Konfiguration von sshd, also den SSH-Server. 

Port 22
Protocol 2
ListenAddress 192.168.0.58
PermitRootLogin no
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key

Erläuterung:

* sshd verwendet den Standardport 22.
* Ausschließlich SSH-2-Verbindungen.
* Zugriff auf Schnittstelle des Rechners: 192.168.0.58
* Kein login für root.
* Als Hostkey kommen RSA, ECDSA und Ed25519 in Frage.

'''Hinweis''' 
Der Authentifizierung mit Schlüsseln und ssh_known_hosts Datei, wird unter [[SSH Authentifizierung mit Schlüsseln]] ein separater Abschnitt gewidmet, weil sie ausdrücklich als Prüfungsthema genannt sind.
 
/etc/ssh/ssh_config
Die Konfigurationsdatei ssh_config dient der clientseitigen Konfiguration von SSH.

z.B.
* Clientseitige X11-Weiterleitung oder Passwortauthentifizierung
* RSA-Authentifizierung aktiv
* Standardport für ausgehende Verbindungen festlegen
 
Die Optionsnamen innerhalb dieser Datei sind ansonsten selbsterklärend oder in der Manpage nachzuschlagen. 
ACHTUNG! Die beiden gerade besprochenen Dateien kann man aufgrund ihrer Namensähnlichkeit schnell verwechseln.

/etc/hosts.allow und /etc/hosts.deny

Die Dateien /etc/hosts.allow und /etc/hosts.deny steuern wie die oben beschriebenen Dateien, den Zugriff auf SSH. 

Wichtig für die Prüfung:
Die Datei hosts.allow hat Vorrang vor der Datei hosts.deny. 
Wird einem Host der Zugriff auf SSH durch hosts.allow gewährt, kann das durch keinen Eintrag in hosts.deny zurückgenommen werden.

/etc/nologin

Mit dem erstellen einer leeren Datei namens /etc/nologin lässt sich der Zugriff auf SSH verhindern. 
Nur root kann sich dann noch am System anmelden. 
In dieser Datei kann auch eine Nachricht an Benutzer hinterlassen werden die sich lokal anmelden wollen.

==Wichtigste Wissensgebiete==

* einen OpenSSH-2-Client grundlegend konfigurieren und verwenden
* die Rolle von OpenSSH-2-Rechnerschlüsseln verstehen
* GnuPG grundlegend konfigurieren und verwenden
* GPG verwenden um Dateien zu verschlüsseln, entschlüsseln, signieren und zu überprüfen
* SSH-Port-Tunnel (auch X11-Tunnel) verstehen

==Liste wichtiger Dateien, Verzeichnisse und Anwendungen==

* ssh
* ssh-keygen
* ssh-agent
* ssh-add
* ~/.ssh/id_rsa und id_rsa.pub
* ~/.ssh/id_dsa und id_dsa.pub
* ~/.ssh/id_ecdsa und id_ecdsa.pub
* ~/.ssh/id_ed25519 und id_ed25519.pub
* /etc/ssh/ssh_host_rsa_key und ssh_host_rsa_key.pub
* /etc/ssh/ssh_host_dsa_key und ssh_host_dsa_key.pub
* /etc/ssh/ssh_host_ecdsa_key und ssh_host_ecdsa_key.pub
* /etc/ssh/ssh_host_ed25519_key und ssh_host_ed25519_key.pub
* ~/.ssh/authorized_keys
* ssh_known_hosts
* gpg
* gpg-agent
* ~/.gnupg/
 
#WEITERLEITUNG [[110.3 SSH Authentifizierung mit Schlüsseln]]

=Quellenangaben=

[[Benutzer:Meikschwalm|Meikschwalm]] ([[Benutzer Diskussion:Meikschwalm|Diskussion]]) 21:38, 29. Jul. 2019 (CEST)

[[Category:Linux]]

LPIC102/110.3 SSH Authentifizierung mit Schlüsseln

2019-07-29T19:38:37Z

Meikschwalm: /* Der Authentifizierungsagent */

==Authentifizierung der Server mit Schlüsseln==
* Server authentifiziert sich am Client mit seinem Hostkey. 
* Ist der Ziel-Host dem Client noch nicht bekannt, erfolgt eine Warnmeldung. 
* In der Meldung erscheint auch der Fingerprint des Hostkeys.

[root@scientific /]# ssh uvm1.nwa-net.de
The authenticity of host
uvm1.nwa-net.de (176.95.26.236)' can't be established.
ECDSA key fingerprint is SHA256:TbVCtl6TJHAHacrTdwh9gqzvx8fB5bzhi1lL/ByFbYE.
ECDSA key fingerprint is MD5:c8:db:4a:6f:99:7a:e9:9d:ca:82:c7:36:99:ac:14:c9.
Are you sure you want to continue connecting (yes/no)?

* Bestätigt man mit yes, wird der Hostkey des Servers in die Datei ''~./ssh/known_hosts'' des Benutzers eingetragen und die Verbindung hergestellt.
* Bei späteren Anmeldungen entfällt entsprechend die Warnmeldung.
* Folgendes Kommando zeigt eine Liste der bekannten Hosts

# ssh-keygen -l -f ~/.ssh/known_hosts
256 SHA256:VOrsAcZc//9EiAATV2DfSN2jHONQBEuJpyrmW+Q3CWQ
user,192.168.178.2 (ECDSA)
256 SHA256:TbVCtl6TJHAHacrTdwh9gqzvx8fB5bzhi1lL/ByFbYE
uvm1.nwa-net.de,176.95.26.236 (ECDSA)

* Ändert sich der Schlüssel eines Zielsystems, erfolgt die Warnmeldung.

$ ssh scientific
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:r+9OEu2EM5ubr0P5wl4lLgUo5n/8/AkX2exIiPqQ9rs.
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /root/.ssh/known_hosts:15
ECDSA host key for scientific has changed and you have requested strict checking.
Host key verification failed.

* Wenn es sich um keine echte man-in-the-middle-attack handelt, entfernt man mithilfe eines Editors den veralteten Schlüssel aus der known_hosts-Datei und baut die Verbindung erneut auf.

* Die Datei ''/etc/ssh/ssh_known_hosts'' macht nichts anderes als die Datei ''~/.ssh/known_hosts'' für jeden Benutzer, nur eben am Client.

==Hostkeys==

* OpenSSH erstellt in der Regel automatisch Hostkeys.
* Sie dienen der Authentifizierung zwischen Server und Clientcomputer.

ssh_host_dsa_key
ssh_host_dsa_key.pub
ssh_host_ecdsa_key
ssh_host_ecdsa_key.pub
ssh_host_ed25519_key
ssh_host_ed25519_key.pub
ssh_host_rsa_key
ssh_host_rsa_key.pub

* Ohne Dateierweiterung = privater Schlüssel.
* Mit Erweiterung .pub = öffentlicher (public) Schlüssel.
* Die Konfigurationsdatei dazu ist ''sshd_config''.

Erläuterung zu den einzelnen Schlüsseldateien

* DSA: veraltet, bekannte Schwächen, wird nicht mehr unterstützt. 
* ECDSA: Momentan Standard bei Linux-Distributionen, kleinere Schlüsselgrößen als etwa RSA, Verdacht die gleichen Schwächen aufzuweisen wie DSA.
* RSA: etablierter Standard, überall unterstützt, existiert seit 1977. 
* Ed25519: ähnelt technisch ECDSA, weist jedoch nicht dieselbe Schwäche auf. 
* Wird von sehr neuen SSH-Versionen unterstützt, empfiehlt sich daher nicht als Standalone-Lösung, wenn man auch ältere Clientsysteme im Einsatz hat. 

* ''ssh-keygen'' generiert neue Schlüssel.
* Optional die Pfadangabe des Users angeben.
* Option ''–t'' legt den Typ des Schlüssels fest.
* Zur Auswahl stehen rsa, dsa, ecdsa und ed25519.

'''Beispiel:'''
* Erstellen eines neuen Schlüsselpaares für RSA.
* Es wurde keine passphrase verwendet.

# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
/etc/ssh/ssh_host_rsa_key
/etc/ssh/ssh_host_rsa_key already exists.
Overwrite (y/n)? y
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /etc/ssh/ssh_host_rsa_key.
Your public key has been saved in /etc/ssh/ssh_host_rsa_key.pub.
The key fingerprint is:
SHA256:zinmLbZLTBxcCOWN52QBDniQVAE9GfD/MuuQHzk3QQ4 root@scientific

* Generierte Datei ''ssh_host_rsa_key.pub'' enthält den öffentlichen Schlüssel des Systems.
* Dieser lässt sich an Clients verteilen.
* Datei ''ssh_host_rsa_key'' enthält privaten Schlüssel des Servers (geheim halten).

Folgende Kommandos können vom Clientsystem verwendet werden um den öffentlichen Schlüssel zu importieren:

# scp scientific:/etc/ssh/ssh_host_rsa_key.pub ./
# cat ssh_host_rsa_key.pub >> /etc/ssh/ssh_known_hosts
# rm ssh_host_rsa_key.pub

==Benutzerauthentifizierung mit Schlüsseln==

* Hostkeys können auch zur Authentifizierung von Benutzern verwendet werden.
* Verzichtet man auf ein Passwortes, lassen sich ''ssh'' oder ''scp'' in Skripten z. B. für Backups zu verwenden.
* Generierung der Schlüssel ebenfalls mittels ''ssh-keygen''.
* Schlüssel werden automatisch an der richtigen Stelle abgelegt.

$ ssh-keygen -t ecdsa
Generating public/private ecdsa key pair.
Enter file in which to save the key (/home/harald/.ssh/id_ecdsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/harald/.ssh/id_ecdsa.
Your public key has been saved in /home/harald/.ssh/id_ecdsa.pub.
The key fingerprint is:
SHA256:Br+8SdXitm/XnUmqVQB1/+aO0HkJKsrbAjzvTwV8FNI user@10.0.0.1

* Der Schlüssel wurde ohne passphrase erstellt und muss jetzt auf die Zielsysteme verteilt werden. 
* Dafür verwendet man das komfortable Tool ''ssh-copy-id''.

$ ssh-copy-id user
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed:
"/home/harald/.ssh/id_ecdsa.pub"
The authenticity of host 'archangel (192.168.178.2)' can't be established.
ECDSA key fingerprint is SHA256:VOrsAcZc//9EiAATV2DfSN2jHONQBEuJpyrmW+Q3CWQ.
ECDSA key fingerprint is MD5:8d:28:e5:f1:3b:e2:fd:69:cf:28:d9:06:5e:30:f3:30.
Are you sure you want to continue connecting (yes/no)? yes
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s),
to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are
prompted now it is to install the new keys

* Der Schlüssel wurde in die Datei ''~/.ssh/authorized_keys'' des Zielsystems (user) eingetragen und muss nun bei weiteren Anmeldungen nicht mehr angegeben werden.
* Die Schlüsseldateien befinden sich im Verzeichnis ''~/.ssh'' eines Benutzers und lauten auf diese Dateinamen:

id_rsa
id_rsa.pub
id_dsa
id_dsa.pub
id_ecdsa
id_ecdsa.pub
id_ed25519
id_ed25519.pub

* Die Dateinamen zu den Schlüsseln sind im Unterkapitel Hostkeys beschrieben.
* Für die Authentifizierung wird nur ein Schlüsselpaar benötigt.
* Server und Client Schlüsseltyp müssen natürlich identisch sein.

==Der Authentifizierungsagent==

* Der SSH-Agent ist eine weitere Möglichkeit ohne Passwörter Authentifizierungen auszuführen.
* Es lassen sich mehrere Schlüssel für einen Benutzer verwalten.
* Dafür muss er bei der Startphase von X ausgeführt werden.
* ''ssh-add'' kann dem SSH-Agent Schlüssel hinzufügen.
* Ohne Optionen sucht das Programm automatisch nach
''~/.ssh/id_rsa, ~/.ssh/id_dsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ed25519 und ~/.ssh/identity.''

''Wichtige Optionen sind:''

-l – listet die Fingerabdrücke der verfügbaren Schlüssel auf.
-d – entfernt einen einzelnen (angegebenen) Schlüssel vom Agenten.
-D – entfernt alle Schlüssel vom Agenten.
-s – liest Schlüssel von einer Smartcard.
-e – entfernt Schlüssel der Smartcard.
-x – sperrt den Agenten (mit Passwortschutz).
-X – entsperrt den Agenten.

#WEITERLEITUNG [[110.3 Schlüsselerstellung mit GnuPG]]

[[Category:Linux]]

[[Benutzer:Meikschwalm|Meikschwalm]] ([[Benutzer Diskussion:Meikschwalm|Diskussion]]) 21:38, 29. Jul. 2019 (CEST)

LPIC102/110.3 Daten durch Kryptografie schützen

2019-07-29T19:38:09Z

Meikschwalm: /* Quellenangaben */

==SSH Daemon==
Das Paket openssh-server installiert die serverseitige Komponente von SSH. 
Folgende Befehle starten unter systemd den SSH Dienst.
# systemctl start sshd.service
# systemctl enable sshd.service

==SSH-Client==
Um eine Verbindung zwischen zwei Linux-Systemen aufzubauen, startet man ssh und übergibt den Host-Namen bzw. die IP-Adresse. 
Anschliessend folgt die Eingabe eines Kennwortes:
$ ssh server
root@server's password:

Möchte man sich nicht mit seinem lokalen Benutzerkonto anmelden, gibt es zwei Wege:
$ ssh -l willi server
$ ssh willi@server

===Grafische Anwendungen unter X tunneln===

Zuerst wird die SSH-Verbindung von einem X-Terminal aus mit der zusätzlichen Option -X (großes X) initiiert. 

$ ssh -X server

Auf der Konsole des Remote-Systems führt man die Anwendung aus:

user@server:~ $ libreoffice

Die grafische Ausgabe und die Bedienung erfolgt lokal am SSH-Client-Rechner.
Das hier beschriebene Verfahren wird als X11-Tunnel bezeichnet.

===Weiterleitung anderer Ports durch einen SSH-Tunnel.===

Als Beispiel, der Zugriff auf einen Terminalserver im entfernten Netzwerk hinter einem SSH-Server. 

*IP-Adresse des Terminalservers 192.168.50.10 
*Terminalserver lauscht an Port 3389 
*IP des SSH-Server 119.117.63.126

Zunächst wird die SSH-Verbindung initiiert:

ssh 119.117.63.126 -L 4711:192.168.50.10:3389

*Option -L leitet Port 4711 an 192.168.50.10 mit Portnummer 3389 weiter. 
*Verbindungen werden an 192.168.50.10:3389 weitergeleitet. 
*Terminal-Dienste-Clients (z. B. remmina) nutzen nun als Ziel localhost:4711 

'''Hinweis''' 
Auch vom Windows-Computer aus kann mittels PuTTy auf einen Linux-Host zugegriffen werden. 
Läuft ein X-Server auf dem Windows-Computer (z. B. Xming oder Cygwin), ist auch das Tunneln von Ports inklusive X11 durchführbar. 

Wiki Artikel zu PuTTy 
[[PuTTY - ein freier SSH-Client]]

==SSH-Konfigurationsdateien==

/etc/ssh/sshd_config
Die Konfigurationsdatei sshd_config dient der Konfiguration von sshd, also den SSH-Server. 

Port 22
Protocol 2
ListenAddress 192.168.0.58
PermitRootLogin no
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key

Erläuterung:

* sshd verwendet den Standardport 22.
* Ausschließlich SSH-2-Verbindungen.
* Zugriff auf Schnittstelle des Rechners: 192.168.0.58
* Kein login für root.
* Als Hostkey kommen RSA, ECDSA und Ed25519 in Frage.

'''Hinweis''' 
Der Authentifizierung mit Schlüsseln und ssh_known_hosts Datei, wird unter [[SSH Authentifizierung mit Schlüsseln]] ein separater Abschnitt gewidmet, weil sie ausdrücklich als Prüfungsthema genannt sind.
 
/etc/ssh/ssh_config
Die Konfigurationsdatei ssh_config dient der clientseitigen Konfiguration von SSH.

z.B.
* Clientseitige X11-Weiterleitung oder Passwortauthentifizierung
* RSA-Authentifizierung aktiv
* Standardport für ausgehende Verbindungen festlegen
 
Die Optionsnamen innerhalb dieser Datei sind ansonsten selbsterklärend oder in der Manpage nachzuschlagen. 
ACHTUNG! Die beiden gerade besprochenen Dateien kann man aufgrund ihrer Namensähnlichkeit schnell verwechseln.

/etc/hosts.allow und /etc/hosts.deny

Die Dateien /etc/hosts.allow und /etc/hosts.deny steuern wie die oben beschriebenen Dateien, den Zugriff auf SSH. 

Wichtig für die Prüfung:
Die Datei hosts.allow hat Vorrang vor der Datei hosts.deny. 
Wird einem Host der Zugriff auf SSH durch hosts.allow gewährt, kann das durch keinen Eintrag in hosts.deny zurückgenommen werden.

/etc/nologin

Mit dem erstellen einer leeren Datei namens /etc/nologin lässt sich der Zugriff auf SSH verhindern. 
Nur root kann sich dann noch am System anmelden. 
In dieser Datei kann auch eine Nachricht an Benutzer hinterlassen werden die sich lokal anmelden wollen.

==Wichtigste Wissensgebiete==

* einen OpenSSH-2-Client grundlegend konfigurieren und verwenden
* die Rolle von OpenSSH-2-Rechnerschlüsseln verstehen
* GnuPG grundlegend konfigurieren und verwenden
* GPG verwenden um Dateien zu verschlüsseln, entschlüsseln, signieren und zu überprüfen
* SSH-Port-Tunnel (auch X11-Tunnel) verstehen

==Liste wichtiger Dateien, Verzeichnisse und Anwendungen==

* ssh
* ssh-keygen
* ssh-agent
* ssh-add
* ~/.ssh/id_rsa und id_rsa.pub
* ~/.ssh/id_dsa und id_dsa.pub
* ~/.ssh/id_ecdsa und id_ecdsa.pub
* ~/.ssh/id_ed25519 und id_ed25519.pub
* /etc/ssh/ssh_host_rsa_key und ssh_host_rsa_key.pub
* /etc/ssh/ssh_host_dsa_key und ssh_host_dsa_key.pub
* /etc/ssh/ssh_host_ecdsa_key und ssh_host_ecdsa_key.pub
* /etc/ssh/ssh_host_ed25519_key und ssh_host_ed25519_key.pub
* ~/.ssh/authorized_keys
* ssh_known_hosts
* gpg
* gpg-agent
* ~/.gnupg/
 

#WEITERLEITUNG [[110.3 SSH Authentifizierung mit Schlüsseln]]

=Quellenangaben=

[[Benutzer:Meikschwalm|Meikschwalm]] ([[Benutzer Diskussion:Meikschwalm|Diskussion]]) 21:38, 29. Jul. 2019 (CEST)

[[Category:Linux]]

LPIC102/110.3 Daten durch Kryptografie schützen

2019-07-29T19:37:19Z

Meikschwalm: /* Liste wichtiger Dateien, Verzeichnisse und Anwendungen */

==SSH Daemon==
Das Paket openssh-server installiert die serverseitige Komponente von SSH. 
Folgende Befehle starten unter systemd den SSH Dienst.
# systemctl start sshd.service
# systemctl enable sshd.service

==SSH-Client==
Um eine Verbindung zwischen zwei Linux-Systemen aufzubauen, startet man ssh und übergibt den Host-Namen bzw. die IP-Adresse. 
Anschliessend folgt die Eingabe eines Kennwortes:
$ ssh server
root@server's password:

Möchte man sich nicht mit seinem lokalen Benutzerkonto anmelden, gibt es zwei Wege:
$ ssh -l willi server
$ ssh willi@server

===Grafische Anwendungen unter X tunneln===

Zuerst wird die SSH-Verbindung von einem X-Terminal aus mit der zusätzlichen Option -X (großes X) initiiert. 

$ ssh -X server

Auf der Konsole des Remote-Systems führt man die Anwendung aus:

user@server:~ $ libreoffice

Die grafische Ausgabe und die Bedienung erfolgt lokal am SSH-Client-Rechner.
Das hier beschriebene Verfahren wird als X11-Tunnel bezeichnet.

===Weiterleitung anderer Ports durch einen SSH-Tunnel.===

Als Beispiel, der Zugriff auf einen Terminalserver im entfernten Netzwerk hinter einem SSH-Server. 

*IP-Adresse des Terminalservers 192.168.50.10 
*Terminalserver lauscht an Port 3389 
*IP des SSH-Server 119.117.63.126

Zunächst wird die SSH-Verbindung initiiert:

ssh 119.117.63.126 -L 4711:192.168.50.10:3389

*Option -L leitet Port 4711 an 192.168.50.10 mit Portnummer 3389 weiter. 
*Verbindungen werden an 192.168.50.10:3389 weitergeleitet. 
*Terminal-Dienste-Clients (z. B. remmina) nutzen nun als Ziel localhost:4711 

'''Hinweis''' 
Auch vom Windows-Computer aus kann mittels PuTTy auf einen Linux-Host zugegriffen werden. 
Läuft ein X-Server auf dem Windows-Computer (z. B. Xming oder Cygwin), ist auch das Tunneln von Ports inklusive X11 durchführbar. 

Wiki Artikel zu PuTTy 
[[PuTTY - ein freier SSH-Client]]

==SSH-Konfigurationsdateien==

/etc/ssh/sshd_config
Die Konfigurationsdatei sshd_config dient der Konfiguration von sshd, also den SSH-Server. 

Port 22
Protocol 2
ListenAddress 192.168.0.58
PermitRootLogin no
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key

Erläuterung:

* sshd verwendet den Standardport 22.
* Ausschließlich SSH-2-Verbindungen.
* Zugriff auf Schnittstelle des Rechners: 192.168.0.58
* Kein login für root.
* Als Hostkey kommen RSA, ECDSA und Ed25519 in Frage.

'''Hinweis''' 
Der Authentifizierung mit Schlüsseln und ssh_known_hosts Datei, wird unter [[SSH Authentifizierung mit Schlüsseln]] ein separater Abschnitt gewidmet, weil sie ausdrücklich als Prüfungsthema genannt sind.
 
/etc/ssh/ssh_config
Die Konfigurationsdatei ssh_config dient der clientseitigen Konfiguration von SSH.

z.B.
* Clientseitige X11-Weiterleitung oder Passwortauthentifizierung
* RSA-Authentifizierung aktiv
* Standardport für ausgehende Verbindungen festlegen
 
Die Optionsnamen innerhalb dieser Datei sind ansonsten selbsterklärend oder in der Manpage nachzuschlagen. 
ACHTUNG! Die beiden gerade besprochenen Dateien kann man aufgrund ihrer Namensähnlichkeit schnell verwechseln.

/etc/hosts.allow und /etc/hosts.deny

Die Dateien /etc/hosts.allow und /etc/hosts.deny steuern wie die oben beschriebenen Dateien, den Zugriff auf SSH. 

Wichtig für die Prüfung:
Die Datei hosts.allow hat Vorrang vor der Datei hosts.deny. 
Wird einem Host der Zugriff auf SSH durch hosts.allow gewährt, kann das durch keinen Eintrag in hosts.deny zurückgenommen werden.

/etc/nologin

Mit dem erstellen einer leeren Datei namens /etc/nologin lässt sich der Zugriff auf SSH verhindern. 
Nur root kann sich dann noch am System anmelden. 
In dieser Datei kann auch eine Nachricht an Benutzer hinterlassen werden die sich lokal anmelden wollen.

==Wichtigste Wissensgebiete==

* einen OpenSSH-2-Client grundlegend konfigurieren und verwenden
* die Rolle von OpenSSH-2-Rechnerschlüsseln verstehen
* GnuPG grundlegend konfigurieren und verwenden
* GPG verwenden um Dateien zu verschlüsseln, entschlüsseln, signieren und zu überprüfen
* SSH-Port-Tunnel (auch X11-Tunnel) verstehen

==Liste wichtiger Dateien, Verzeichnisse und Anwendungen==

* ssh
* ssh-keygen
* ssh-agent
* ssh-add
* ~/.ssh/id_rsa und id_rsa.pub
* ~/.ssh/id_dsa und id_dsa.pub
* ~/.ssh/id_ecdsa und id_ecdsa.pub
* ~/.ssh/id_ed25519 und id_ed25519.pub
* /etc/ssh/ssh_host_rsa_key und ssh_host_rsa_key.pub
* /etc/ssh/ssh_host_dsa_key und ssh_host_dsa_key.pub
* /etc/ssh/ssh_host_ecdsa_key und ssh_host_ecdsa_key.pub
* /etc/ssh/ssh_host_ed25519_key und ssh_host_ed25519_key.pub
* ~/.ssh/authorized_keys
* ssh_known_hosts
* gpg
* gpg-agent
* ~/.gnupg/
 

#WEITERLEITUNG [[110.3 SSH Authentifizierung mit Schlüsseln]]

=Quellenangaben=

[[Benutzer:Meikschwalm|Meikschwalm]] ([[Benutzer Diskussion:Meikschwalm|Diskussion]]) 11:48, 17. Jul. 2019 (CEST)

[[Category:Linux]]

LPIC102/110.3 Daten durch Kryptografie schützen

2019-07-29T19:37:07Z

Meikschwalm: /* Liste wichtiger Dateien, Verzeichnisse und Anwendungen */

==SSH Daemon==
Das Paket openssh-server installiert die serverseitige Komponente von SSH. 
Folgende Befehle starten unter systemd den SSH Dienst.
# systemctl start sshd.service
# systemctl enable sshd.service

==SSH-Client==
Um eine Verbindung zwischen zwei Linux-Systemen aufzubauen, startet man ssh und übergibt den Host-Namen bzw. die IP-Adresse. 
Anschliessend folgt die Eingabe eines Kennwortes:
$ ssh server
root@server's password:

Möchte man sich nicht mit seinem lokalen Benutzerkonto anmelden, gibt es zwei Wege:
$ ssh -l willi server
$ ssh willi@server

===Grafische Anwendungen unter X tunneln===

Zuerst wird die SSH-Verbindung von einem X-Terminal aus mit der zusätzlichen Option -X (großes X) initiiert. 

$ ssh -X server

Auf der Konsole des Remote-Systems führt man die Anwendung aus:

user@server:~ $ libreoffice

Die grafische Ausgabe und die Bedienung erfolgt lokal am SSH-Client-Rechner.
Das hier beschriebene Verfahren wird als X11-Tunnel bezeichnet.

===Weiterleitung anderer Ports durch einen SSH-Tunnel.===

Als Beispiel, der Zugriff auf einen Terminalserver im entfernten Netzwerk hinter einem SSH-Server. 

*IP-Adresse des Terminalservers 192.168.50.10 
*Terminalserver lauscht an Port 3389 
*IP des SSH-Server 119.117.63.126

Zunächst wird die SSH-Verbindung initiiert:

ssh 119.117.63.126 -L 4711:192.168.50.10:3389

*Option -L leitet Port 4711 an 192.168.50.10 mit Portnummer 3389 weiter. 
*Verbindungen werden an 192.168.50.10:3389 weitergeleitet. 
*Terminal-Dienste-Clients (z. B. remmina) nutzen nun als Ziel localhost:4711 

'''Hinweis''' 
Auch vom Windows-Computer aus kann mittels PuTTy auf einen Linux-Host zugegriffen werden. 
Läuft ein X-Server auf dem Windows-Computer (z. B. Xming oder Cygwin), ist auch das Tunneln von Ports inklusive X11 durchführbar. 

Wiki Artikel zu PuTTy 
[[PuTTY - ein freier SSH-Client]]

==SSH-Konfigurationsdateien==

/etc/ssh/sshd_config
Die Konfigurationsdatei sshd_config dient der Konfiguration von sshd, also den SSH-Server. 

Port 22
Protocol 2
ListenAddress 192.168.0.58
PermitRootLogin no
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key

Erläuterung:

* sshd verwendet den Standardport 22.
* Ausschließlich SSH-2-Verbindungen.
* Zugriff auf Schnittstelle des Rechners: 192.168.0.58
* Kein login für root.
* Als Hostkey kommen RSA, ECDSA und Ed25519 in Frage.

'''Hinweis''' 
Der Authentifizierung mit Schlüsseln und ssh_known_hosts Datei, wird unter [[SSH Authentifizierung mit Schlüsseln]] ein separater Abschnitt gewidmet, weil sie ausdrücklich als Prüfungsthema genannt sind.
 
/etc/ssh/ssh_config
Die Konfigurationsdatei ssh_config dient der clientseitigen Konfiguration von SSH.

z.B.
* Clientseitige X11-Weiterleitung oder Passwortauthentifizierung
* RSA-Authentifizierung aktiv
* Standardport für ausgehende Verbindungen festlegen
 
Die Optionsnamen innerhalb dieser Datei sind ansonsten selbsterklärend oder in der Manpage nachzuschlagen. 
ACHTUNG! Die beiden gerade besprochenen Dateien kann man aufgrund ihrer Namensähnlichkeit schnell verwechseln.

/etc/hosts.allow und /etc/hosts.deny

Die Dateien /etc/hosts.allow und /etc/hosts.deny steuern wie die oben beschriebenen Dateien, den Zugriff auf SSH. 

Wichtig für die Prüfung:
Die Datei hosts.allow hat Vorrang vor der Datei hosts.deny. 
Wird einem Host der Zugriff auf SSH durch hosts.allow gewährt, kann das durch keinen Eintrag in hosts.deny zurückgenommen werden.

/etc/nologin

Mit dem erstellen einer leeren Datei namens /etc/nologin lässt sich der Zugriff auf SSH verhindern. 
Nur root kann sich dann noch am System anmelden. 
In dieser Datei kann auch eine Nachricht an Benutzer hinterlassen werden die sich lokal anmelden wollen.

==Wichtigste Wissensgebiete==

* einen OpenSSH-2-Client grundlegend konfigurieren und verwenden
* die Rolle von OpenSSH-2-Rechnerschlüsseln verstehen
* GnuPG grundlegend konfigurieren und verwenden
* GPG verwenden um Dateien zu verschlüsseln, entschlüsseln, signieren und zu überprüfen
* SSH-Port-Tunnel (auch X11-Tunnel) verstehen

==Liste wichtiger Dateien, Verzeichnisse und Anwendungen==

* ssh
* ssh-keygen
* ssh-agent
* ssh-add
* ~/.ssh/id_rsa und id_rsa.pub
* ~/.ssh/id_dsa und id_dsa.pub
* ~/.ssh/id_ecdsa und id_ecdsa.pub
* ~/.ssh/id_ed25519 und id_ed25519.pub
* /etc/ssh/ssh_host_rsa_key und ssh_host_rsa_key.pub
* /etc/ssh/ssh_host_dsa_key und ssh_host_dsa_key.pub
* /etc/ssh/ssh_host_ecdsa_key und ssh_host_ecdsa_key.pub
* /etc/ssh/ssh_host_ed25519_key und ssh_host_ed25519_key.pub
* ~/.ssh/authorized_keys
* ssh_known_hosts
* gpg
* gpg-agent
* ~/.gnupg/

#WEITERLEITUNG [[110.3 SSH Authentifizierung mit Schlüsseln]]

=Quellenangaben=

[[Benutzer:Meikschwalm|Meikschwalm]] ([[Benutzer Diskussion:Meikschwalm|Diskussion]]) 11:48, 17. Jul. 2019 (CEST)

[[Category:Linux]]

LPIC102/110.3 Daten durch Kryptografie schützen

2019-07-29T19:36:25Z

Meikschwalm: /* SSH-Konfigurationsdateien */

==SSH Daemon==
Das Paket openssh-server installiert die serverseitige Komponente von SSH. 
Folgende Befehle starten unter systemd den SSH Dienst.
# systemctl start sshd.service
# systemctl enable sshd.service

==SSH-Client==
Um eine Verbindung zwischen zwei Linux-Systemen aufzubauen, startet man ssh und übergibt den Host-Namen bzw. die IP-Adresse. 
Anschliessend folgt die Eingabe eines Kennwortes:
$ ssh server
root@server's password:

Möchte man sich nicht mit seinem lokalen Benutzerkonto anmelden, gibt es zwei Wege:
$ ssh -l willi server
$ ssh willi@server

===Grafische Anwendungen unter X tunneln===

Zuerst wird die SSH-Verbindung von einem X-Terminal aus mit der zusätzlichen Option -X (großes X) initiiert. 

$ ssh -X server

Auf der Konsole des Remote-Systems führt man die Anwendung aus:

user@server:~ $ libreoffice

Die grafische Ausgabe und die Bedienung erfolgt lokal am SSH-Client-Rechner.
Das hier beschriebene Verfahren wird als X11-Tunnel bezeichnet.

===Weiterleitung anderer Ports durch einen SSH-Tunnel.===

Als Beispiel, der Zugriff auf einen Terminalserver im entfernten Netzwerk hinter einem SSH-Server. 

*IP-Adresse des Terminalservers 192.168.50.10 
*Terminalserver lauscht an Port 3389 
*IP des SSH-Server 119.117.63.126

Zunächst wird die SSH-Verbindung initiiert:

ssh 119.117.63.126 -L 4711:192.168.50.10:3389

*Option -L leitet Port 4711 an 192.168.50.10 mit Portnummer 3389 weiter. 
*Verbindungen werden an 192.168.50.10:3389 weitergeleitet. 
*Terminal-Dienste-Clients (z. B. remmina) nutzen nun als Ziel localhost:4711 

'''Hinweis''' 
Auch vom Windows-Computer aus kann mittels PuTTy auf einen Linux-Host zugegriffen werden. 
Läuft ein X-Server auf dem Windows-Computer (z. B. Xming oder Cygwin), ist auch das Tunneln von Ports inklusive X11 durchführbar. 

Wiki Artikel zu PuTTy 
[[PuTTY - ein freier SSH-Client]]

==SSH-Konfigurationsdateien==

/etc/ssh/sshd_config
Die Konfigurationsdatei sshd_config dient der Konfiguration von sshd, also den SSH-Server. 

Port 22
Protocol 2
ListenAddress 192.168.0.58
PermitRootLogin no
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key

Erläuterung:

* sshd verwendet den Standardport 22.
* Ausschließlich SSH-2-Verbindungen.
* Zugriff auf Schnittstelle des Rechners: 192.168.0.58
* Kein login für root.
* Als Hostkey kommen RSA, ECDSA und Ed25519 in Frage.

'''Hinweis''' 
Der Authentifizierung mit Schlüsseln und ssh_known_hosts Datei, wird unter [[SSH Authentifizierung mit Schlüsseln]] ein separater Abschnitt gewidmet, weil sie ausdrücklich als Prüfungsthema genannt sind.
 
/etc/ssh/ssh_config
Die Konfigurationsdatei ssh_config dient der clientseitigen Konfiguration von SSH.

z.B.
* Clientseitige X11-Weiterleitung oder Passwortauthentifizierung
* RSA-Authentifizierung aktiv
* Standardport für ausgehende Verbindungen festlegen
 
Die Optionsnamen innerhalb dieser Datei sind ansonsten selbsterklärend oder in der Manpage nachzuschlagen. 
ACHTUNG! Die beiden gerade besprochenen Dateien kann man aufgrund ihrer Namensähnlichkeit schnell verwechseln.

/etc/hosts.allow und /etc/hosts.deny

Die Dateien /etc/hosts.allow und /etc/hosts.deny steuern wie die oben beschriebenen Dateien, den Zugriff auf SSH. 

Wichtig für die Prüfung:
Die Datei hosts.allow hat Vorrang vor der Datei hosts.deny. 
Wird einem Host der Zugriff auf SSH durch hosts.allow gewährt, kann das durch keinen Eintrag in hosts.deny zurückgenommen werden.

/etc/nologin

Mit dem erstellen einer leeren Datei namens /etc/nologin lässt sich der Zugriff auf SSH verhindern. 
Nur root kann sich dann noch am System anmelden. 
In dieser Datei kann auch eine Nachricht an Benutzer hinterlassen werden die sich lokal anmelden wollen.

==Wichtigste Wissensgebiete==

* einen OpenSSH-2-Client grundlegend konfigurieren und verwenden
* die Rolle von OpenSSH-2-Rechnerschlüsseln verstehen
* GnuPG grundlegend konfigurieren und verwenden
* GPG verwenden um Dateien zu verschlüsseln, entschlüsseln, signieren und zu überprüfen
* SSH-Port-Tunnel (auch X11-Tunnel) verstehen

==Liste wichtiger Dateien, Verzeichnisse und Anwendungen==

* ssh
* ssh-keygen
* ssh-agent
* ssh-add
* ~/.ssh/id_rsa und id_rsa.pub
* ~/.ssh/id_dsa und id_dsa.pub
* ~/.ssh/id_ecdsa und id_ecdsa.pub
* ~/.ssh/id_ed25519 und id_ed25519.pub
* /etc/ssh/ssh_host_rsa_key und ssh_host_rsa_key.pub
* /etc/ssh/ssh_host_dsa_key und ssh_host_dsa_key.pub
* /etc/ssh/ssh_host_ecdsa_key und ssh_host_ecdsa_key.pub
* /etc/ssh/ssh_host_ed25519_key und ssh_host_ed25519_key.pub
* ~/.ssh/authorized_keys
* ssh_known_hosts
* gpg
* gpg-agent
* ~/.gnupg/

=Quellenangaben=

[[Benutzer:Meikschwalm|Meikschwalm]] ([[Benutzer Diskussion:Meikschwalm|Diskussion]]) 11:48, 17. Jul. 2019 (CEST)

[[Category:Linux]]

LPIC102/110.3 SSH Authentifizierung mit Schlüsseln

2019-07-29T19:34:13Z

Meikschwalm: /* Der Authentifizierungsagent */

LPIC102/110.3 SSH Authentifizierung mit Schlüsseln

2019-07-29T19:31:11Z

Meikschwalm: /* Der Authentifizierungsagent */

LPIC102/110.3 SSH Authentifizierung mit Schlüsseln

2019-07-29T19:29:40Z

Meikschwalm: /* Benutzerauthentifizierung mit Schlüsseln */

==Authentifizierung der Server mit Schlüsseln==
* Server authentifiziert sich am Client mit seinem Hostkey. 
* Ist der Ziel-Host dem Client noch nicht bekannt, erfolgt eine Warnmeldung. 
* In der Meldung erscheint auch der Fingerprint des Hostkeys.

[root@scientific /]# ssh uvm1.nwa-net.de
The authenticity of host
uvm1.nwa-net.de (176.95.26.236)' can't be established.
ECDSA key fingerprint is SHA256:TbVCtl6TJHAHacrTdwh9gqzvx8fB5bzhi1lL/ByFbYE.
ECDSA key fingerprint is MD5:c8:db:4a:6f:99:7a:e9:9d:ca:82:c7:36:99:ac:14:c9.
Are you sure you want to continue connecting (yes/no)?

* Bestätigt man mit yes, wird der Hostkey des Servers in die Datei ''~./ssh/known_hosts'' des Benutzers eingetragen und die Verbindung hergestellt.
* Bei späteren Anmeldungen entfällt entsprechend die Warnmeldung.
* Folgendes Kommando zeigt eine Liste der bekannten Hosts

# ssh-keygen -l -f ~/.ssh/known_hosts
256 SHA256:VOrsAcZc//9EiAATV2DfSN2jHONQBEuJpyrmW+Q3CWQ
user,192.168.178.2 (ECDSA)
256 SHA256:TbVCtl6TJHAHacrTdwh9gqzvx8fB5bzhi1lL/ByFbYE
uvm1.nwa-net.de,176.95.26.236 (ECDSA)

* Ändert sich der Schlüssel eines Zielsystems, erfolgt die Warnmeldung.

$ ssh scientific
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:r+9OEu2EM5ubr0P5wl4lLgUo5n/8/AkX2exIiPqQ9rs.
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /root/.ssh/known_hosts:15
ECDSA host key for scientific has changed and you have requested strict checking.
Host key verification failed.

* Wenn es sich um keine echte man-in-the-middle-attack handelt, entfernt man mithilfe eines Editors den veralteten Schlüssel aus der known_hosts-Datei und baut die Verbindung erneut auf.

* Die Datei ''/etc/ssh/ssh_known_hosts'' macht nichts anderes als die Datei ''~/.ssh/known_hosts'' für jeden Benutzer, nur eben am Client.

==Hostkeys==

* OpenSSH erstellt in der Regel automatisch Hostkeys.
* Sie dienen der Authentifizierung zwischen Server und Clientcomputer.

ssh_host_dsa_key
ssh_host_dsa_key.pub
ssh_host_ecdsa_key
ssh_host_ecdsa_key.pub
ssh_host_ed25519_key
ssh_host_ed25519_key.pub
ssh_host_rsa_key
ssh_host_rsa_key.pub

* Ohne Dateierweiterung = privater Schlüssel.
* Mit Erweiterung .pub = öffentlicher (public) Schlüssel.
* Die Konfigurationsdatei dazu ist ''sshd_config''.

Erläuterung zu den einzelnen Schlüsseldateien

* DSA: veraltet, bekannte Schwächen, wird nicht mehr unterstützt. 
* ECDSA: Momentan Standard bei Linux-Distributionen, kleinere Schlüsselgrößen als etwa RSA, Verdacht die gleichen Schwächen aufzuweisen wie DSA.
* RSA: etablierter Standard, überall unterstützt, existiert seit 1977. 
* Ed25519: ähnelt technisch ECDSA, weist jedoch nicht dieselbe Schwäche auf. 
* Wird von sehr neuen SSH-Versionen unterstützt, empfiehlt sich daher nicht als Standalone-Lösung, wenn man auch ältere Clientsysteme im Einsatz hat. 

* ''ssh-keygen'' generiert neue Schlüssel.
* Optional die Pfadangabe des Users angeben.
* Option ''–t'' legt den Typ des Schlüssels fest.
* Zur Auswahl stehen rsa, dsa, ecdsa und ed25519.

'''Beispiel:'''
* Erstellen eines neuen Schlüsselpaares für RSA.
* Es wurde keine passphrase verwendet.

# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
/etc/ssh/ssh_host_rsa_key
/etc/ssh/ssh_host_rsa_key already exists.
Overwrite (y/n)? y
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /etc/ssh/ssh_host_rsa_key.
Your public key has been saved in /etc/ssh/ssh_host_rsa_key.pub.
The key fingerprint is:
SHA256:zinmLbZLTBxcCOWN52QBDniQVAE9GfD/MuuQHzk3QQ4 root@scientific

* Generierte Datei ''ssh_host_rsa_key.pub'' enthält den öffentlichen Schlüssel des Systems.
* Dieser lässt sich an Clients verteilen.
* Datei ''ssh_host_rsa_key'' enthält privaten Schlüssel des Servers (geheim halten).

Folgende Kommandos können vom Clientsystem verwendet werden um den öffentlichen Schlüssel zu importieren:

# scp scientific:/etc/ssh/ssh_host_rsa_key.pub ./
# cat ssh_host_rsa_key.pub >> /etc/ssh/ssh_known_hosts
# rm ssh_host_rsa_key.pub

==Benutzerauthentifizierung mit Schlüsseln==

* Hostkeys können auch zur Authentifizierung von Benutzern verwendet werden.
* Verzichtet man auf ein Passwortes, lassen sich ''ssh'' oder ''scp'' in Skripten z. B. für Backups zu verwenden.
* Generierung der Schlüssel ebenfalls mittels ''ssh-keygen''.
* Schlüssel werden automatisch an der richtigen Stelle abgelegt.

$ ssh-keygen -t ecdsa
Generating public/private ecdsa key pair.
Enter file in which to save the key (/home/harald/.ssh/id_ecdsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/harald/.ssh/id_ecdsa.
Your public key has been saved in /home/harald/.ssh/id_ecdsa.pub.
The key fingerprint is:
SHA256:Br+8SdXitm/XnUmqVQB1/+aO0HkJKsrbAjzvTwV8FNI user@10.0.0.1

* Der Schlüssel wurde ohne passphrase erstellt und muss jetzt auf die Zielsysteme verteilt werden. 
* Dafür verwendet man das komfortable Tool ''ssh-copy-id''.

$ ssh-copy-id user
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed:
"/home/harald/.ssh/id_ecdsa.pub"
The authenticity of host 'archangel (192.168.178.2)' can't be established.
ECDSA key fingerprint is SHA256:VOrsAcZc//9EiAATV2DfSN2jHONQBEuJpyrmW+Q3CWQ.
ECDSA key fingerprint is MD5:8d:28:e5:f1:3b:e2:fd:69:cf:28:d9:06:5e:30:f3:30.
Are you sure you want to continue connecting (yes/no)? yes
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s),
to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are
prompted now it is to install the new keys

* Der Schlüssel wurde in die Datei ''~/.ssh/authorized_keys'' des Zielsystems (user) eingetragen und muss nun bei weiteren Anmeldungen nicht mehr angegeben werden.
* Die Schlüsseldateien befinden sich im Verzeichnis ''~/.ssh'' eines Benutzers und lauten auf diese Dateinamen:

id_rsa
id_rsa.pub
id_dsa
id_dsa.pub
id_ecdsa
id_ecdsa.pub
id_ed25519
id_ed25519.pub

* Die Dateinamen zu den Schlüsseln sind im Unterkapitel Hostkeys beschrieben.
* Für die Authentifizierung wird nur ein Schlüsselpaar benötigt.
* Server und Client Schlüsseltyp müssen natürlich identisch sein.

===Der Authentifizierungsagent===

* Der SSH-Agent ist eine weitere Möglichkeit ohne Passwörter Authentifizierungen auszuführen.
* Es lassen sich mehrere Schlüssel für einen Benutzer verwalten.
* Dafür muss er bei der Startphase von X ausgeführt werden.
* ''ssh-add'' kann dem SSH-Agent Schlüssel hinzufügen.
* Ohne Optionen sucht das Programm automatisch nach
''~/.ssh/id_rsa, ~/.ssh/id_dsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ed25519 und ~/.ssh/identity.''

''Wichtige Optionen sind:''

-l – listet die Fingerabdrücke der verfügbaren Schlüssel auf.
-d – entfernt einen einzelnen (angegebenen) Schlüssel vom Agenten.
-D – entfernt alle Schlüssel vom Agenten.
-s – liest Schlüssel von einer Smartcard.
-e – entfernt Schlüssel der Smartcard.
-x – sperrt den Agenten (mit Passwortschutz).
-X – entsperrt den Agenten.

[[Category:Linux]]

LPIC102/110.3 SSH Authentifizierung mit Schlüsseln

2019-07-29T19:28:03Z

Meikschwalm:

==Authentifizierung der Server mit Schlüsseln==
* Server authentifiziert sich am Client mit seinem Hostkey. 
* Ist der Ziel-Host dem Client noch nicht bekannt, erfolgt eine Warnmeldung. 
* In der Meldung erscheint auch der Fingerprint des Hostkeys.

[root@scientific /]# ssh uvm1.nwa-net.de
The authenticity of host
uvm1.nwa-net.de (176.95.26.236)' can't be established.
ECDSA key fingerprint is SHA256:TbVCtl6TJHAHacrTdwh9gqzvx8fB5bzhi1lL/ByFbYE.
ECDSA key fingerprint is MD5:c8:db:4a:6f:99:7a:e9:9d:ca:82:c7:36:99:ac:14:c9.
Are you sure you want to continue connecting (yes/no)?

* Bestätigt man mit yes, wird der Hostkey des Servers in die Datei ''~./ssh/known_hosts'' des Benutzers eingetragen und die Verbindung hergestellt.
* Bei späteren Anmeldungen entfällt entsprechend die Warnmeldung.
* Folgendes Kommando zeigt eine Liste der bekannten Hosts

# ssh-keygen -l -f ~/.ssh/known_hosts
256 SHA256:VOrsAcZc//9EiAATV2DfSN2jHONQBEuJpyrmW+Q3CWQ
user,192.168.178.2 (ECDSA)
256 SHA256:TbVCtl6TJHAHacrTdwh9gqzvx8fB5bzhi1lL/ByFbYE
uvm1.nwa-net.de,176.95.26.236 (ECDSA)

* Ändert sich der Schlüssel eines Zielsystems, erfolgt die Warnmeldung.

$ ssh scientific
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:r+9OEu2EM5ubr0P5wl4lLgUo5n/8/AkX2exIiPqQ9rs.
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /root/.ssh/known_hosts:15
ECDSA host key for scientific has changed and you have requested strict checking.
Host key verification failed.

* Wenn es sich um keine echte man-in-the-middle-attack handelt, entfernt man mithilfe eines Editors den veralteten Schlüssel aus der known_hosts-Datei und baut die Verbindung erneut auf.

* Die Datei ''/etc/ssh/ssh_known_hosts'' macht nichts anderes als die Datei ''~/.ssh/known_hosts'' für jeden Benutzer, nur eben am Client.

==Hostkeys==

* OpenSSH erstellt in der Regel automatisch Hostkeys.
* Sie dienen der Authentifizierung zwischen Server und Clientcomputer.

ssh_host_dsa_key
ssh_host_dsa_key.pub
ssh_host_ecdsa_key
ssh_host_ecdsa_key.pub
ssh_host_ed25519_key
ssh_host_ed25519_key.pub
ssh_host_rsa_key
ssh_host_rsa_key.pub

* Ohne Dateierweiterung = privater Schlüssel.
* Mit Erweiterung .pub = öffentlicher (public) Schlüssel.
* Die Konfigurationsdatei dazu ist ''sshd_config''.

Erläuterung zu den einzelnen Schlüsseldateien

* DSA: veraltet, bekannte Schwächen, wird nicht mehr unterstützt. 
* ECDSA: Momentan Standard bei Linux-Distributionen, kleinere Schlüsselgrößen als etwa RSA, Verdacht die gleichen Schwächen aufzuweisen wie DSA.
* RSA: etablierter Standard, überall unterstützt, existiert seit 1977. 
* Ed25519: ähnelt technisch ECDSA, weist jedoch nicht dieselbe Schwäche auf. 
* Wird von sehr neuen SSH-Versionen unterstützt, empfiehlt sich daher nicht als Standalone-Lösung, wenn man auch ältere Clientsysteme im Einsatz hat. 

* ''ssh-keygen'' generiert neue Schlüssel.
* Optional die Pfadangabe des Users angeben.
* Option ''–t'' legt den Typ des Schlüssels fest.
* Zur Auswahl stehen rsa, dsa, ecdsa und ed25519.

'''Beispiel:'''
* Erstellen eines neuen Schlüsselpaares für RSA.
* Es wurde keine passphrase verwendet.

# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
/etc/ssh/ssh_host_rsa_key
/etc/ssh/ssh_host_rsa_key already exists.
Overwrite (y/n)? y
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /etc/ssh/ssh_host_rsa_key.
Your public key has been saved in /etc/ssh/ssh_host_rsa_key.pub.
The key fingerprint is:
SHA256:zinmLbZLTBxcCOWN52QBDniQVAE9GfD/MuuQHzk3QQ4 root@scientific

* Generierte Datei ''ssh_host_rsa_key.pub'' enthält den öffentlichen Schlüssel des Systems.
* Dieser lässt sich an Clients verteilen.
* Datei ''ssh_host_rsa_key'' enthält privaten Schlüssel des Servers (geheim halten).

Folgende Kommandos können vom Clientsystem verwendet werden um den öffentlichen Schlüssel zu importieren:

# scp scientific:/etc/ssh/ssh_host_rsa_key.pub ./
# cat ssh_host_rsa_key.pub >> /etc/ssh/ssh_known_hosts
# rm ssh_host_rsa_key.pub

===Benutzerauthentifizierung mit Schlüsseln===

* Hostkeys können auch zur Authentifizierung von Benutzern verwendet werden.
* Verzichtet man auf ein Passwortes, lassen sich ''ssh'' oder ''scp'' in Skripten z. B. für Backups zu verwenden.
* Generierung der Schlüssel ebenfalls mittels ''ssh-keygen''.
* Schlüssel werden automatisch an der richtigen Stelle abgelegt.

$ ssh-keygen -t ecdsa
Generating public/private ecdsa key pair.
Enter file in which to save the key (/home/harald/.ssh/id_ecdsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/harald/.ssh/id_ecdsa.
Your public key has been saved in /home/harald/.ssh/id_ecdsa.pub.
The key fingerprint is:
SHA256:Br+8SdXitm/XnUmqVQB1/+aO0HkJKsrbAjzvTwV8FNI user@10.0.0.1

* Der Schlüssel wurde ohne passphrase erstellt und muss jetzt auf die Zielsysteme verteilt werden. 
* Dafür verwendet man das komfortable Tool ''ssh-copy-id''.

$ ssh-copy-id user
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed:
"/home/harald/.ssh/id_ecdsa.pub"
The authenticity of host 'archangel (192.168.178.2)' can't be established.
ECDSA key fingerprint is SHA256:VOrsAcZc//9EiAATV2DfSN2jHONQBEuJpyrmW+Q3CWQ.
ECDSA key fingerprint is MD5:8d:28:e5:f1:3b:e2:fd:69:cf:28:d9:06:5e:30:f3:30.
Are you sure you want to continue connecting (yes/no)? yes
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s),
to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are
prompted now it is to install the new keys

* Der Schlüssel wurde in die Datei ''~/.ssh/authorized_keys'' des Zielsystems (user) eingetragen und muss nun bei weiteren Anmeldungen nicht mehr angegeben werden.
* Die Schlüsseldateien befinden sich im Verzeichnis ''~/.ssh'' eines Benutzers und lauten auf diese Dateinamen:

id_rsa
id_rsa.pub
id_dsa
id_dsa.pub
id_ecdsa
id_ecdsa.pub
id_ed25519
id_ed25519.pub

* Die Dateinamen zu den Schlüsseln sind im Unterkapitel Hostkeys beschrieben.
* Für die Authentifizierung wird nur ein Schlüsselpaar benötigt.
* Server und Client Schlüsseltyp müssen natürlich identisch sein.

===Der Authentifizierungsagent===

* Der SSH-Agent ist eine weitere Möglichkeit ohne Passwörter Authentifizierungen auszuführen.
* Es lassen sich mehrere Schlüssel für einen Benutzer verwalten.
* Dafür muss er bei der Startphase von X ausgeführt werden.
* ''ssh-add'' kann dem SSH-Agent Schlüssel hinzufügen.
* Ohne Optionen sucht das Programm automatisch nach
''~/.ssh/id_rsa, ~/.ssh/id_dsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ed25519 und ~/.ssh/identity.''

''Wichtige Optionen sind:''

-l – listet die Fingerabdrücke der verfügbaren Schlüssel auf.
-d – entfernt einen einzelnen (angegebenen) Schlüssel vom Agenten.
-D – entfernt alle Schlüssel vom Agenten.
-s – liest Schlüssel von einer Smartcard.
-e – entfernt Schlüssel der Smartcard.
-x – sperrt den Agenten (mit Passwortschutz).
-X – entsperrt den Agenten.

[[Category:Linux]]

LPIC102/110.3 SSH Authentifizierung mit Schlüsseln

2019-07-29T19:11:48Z

Meikschwalm:

'''Vorführung presentationsrechner überträgt schlüssel zu meik rechner und hinterlegt seinen privatkey danach profil erstellung in konsole um einfache handhabung zu zeigen'''

==Authentifizierung der Server mit Schlüsseln==
* Server authentifiziert sich am Client mit seinem Hostkey. 
* Ist der Ziel-Host dem Client noch nicht bekannt, erfolgt eine Warnmeldung. 
* In der Meldung erscheint auch der Fingerprint des Hostkeys:

[root@scientific /]# ssh uvm1.nwa-net.de
The authenticity of host
uvm1.nwa-net.de (176.95.26.236)' can't be established.
ECDSA key fingerprint is SHA256:TbVCtl6TJHAHacrTdwh9gqzvx8fB5bzhi1lL/ByFbYE.
ECDSA key fingerprint is MD5:c8:db:4a:6f:99:7a:e9:9d:ca:82:c7:36:99:ac:14:c9.
Are you sure you want to continue connecting (yes/no)?

* Bestätigt man mit yes, wird der Hostkey des Servers in die Datei ''~./ssh/known_hosts'' des Benutzers eingetragen und die Verbindung hergestellt.
* Bei späteren Anmeldungen entfällt entsprechend die Warnmeldung.
* Folgendes Kommando zeigt eine Liste der bekannten Hosts

# ssh-keygen -l -f ~/.ssh/known_hosts
256 SHA256:VOrsAcZc//9EiAATV2DfSN2jHONQBEuJpyrmW+Q3CWQ
user,192.168.178.2 (ECDSA)
256 SHA256:TbVCtl6TJHAHacrTdwh9gqzvx8fB5bzhi1lL/ByFbYE
uvm1.nwa-net.de,176.95.26.236 (ECDSA)

* Ändert sich der Schlüssel eines Zielsystems, erfolgt die Warnmeldung:

$ ssh scientific
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:r+9OEu2EM5ubr0P5wl4lLgUo5n/8/AkX2exIiPqQ9rs.
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /root/.ssh/known_hosts:15
ECDSA host key for scientific has changed and you have requested strict checking.
Host key verification failed.

* Wenn es sich um keine echte man-in-the-middle-attack handelt, entfernt man mithilfe eines Editors den veralteten Schlüssel aus der known_hosts-Datei und baut die Verbindung erneut auf.

* Die Datei ''/etc/ssh/ssh_known_hosts'' macht nichts anderes als die Datei ''~/.ssh/known_hosts'' für jeden Benutzer, nur eben am Client.

==Hostkeys==

* OpenSSH erstellt in der Regel automatisch Hostkeys.
* Sie dienen der Authentifizierung zwischen Server und Clientcomputer.

ssh_host_dsa_key
ssh_host_dsa_key.pub
ssh_host_ecdsa_key
ssh_host_ecdsa_key.pub
ssh_host_ed25519_key
ssh_host_ed25519_key.pub
ssh_host_rsa_key
ssh_host_rsa_key.pub

* Ohne Dateierweiterung = privater Schlüssel.
* Mit Erweiterung .pub = öffentlicher (public) Schlüssel.
* Die Konfigurationsdatei dazu ist ''sshd_config''.

Erläuterung zu den einzelnen Schlüsseldateien:

* DSA: veraltet, bekannte Schwächen, wird nicht mehr unterstützt. 
* ECDSA: Momentan Standard bei Linux-Distributionen, kleinere Schlüsselgrößen als etwa RSA, Verdacht die gleichen Schwächen aufzuweisen wie DSA.
* RSA: etablierter Standard, überall unterstützt, existiert seit 1977. 
* Ed25519: ähnelt technisch ECDSA, weist jedoch nicht dieselbe Schwäche auf. 
* Wird von sehr neuen SSH-Versionen unterstützt, empfiehlt sich daher nicht als Standalone-Lösung, wenn man auch ältere Clientsysteme im Einsatz hat. 

* ''ssh-keygen'' generiert neue Schlüssel.
* Optional die Pfadangabe des Users angeben.
* Option ''–t'' legt den Typ des Schlüssels fest.
* Zur Auswahl stehen rsa, dsa, ecdsa und ed25519.

'''Beispiel:'''
* Erstellen eines neuen Schlüsselpaares für RSA.
* Benutzereingaben fett gedruckt.
* Es wurde keine passphrase verwendet.

# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
/etc/ssh/ssh_host_rsa_key
/etc/ssh/ssh_host_rsa_key already exists.
Overwrite (y/n)? y
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /etc/ssh/ssh_host_rsa_key.
Your public key has been saved in /etc/ssh/ssh_host_rsa_key.pub.
The key fingerprint is:
SHA256:zinmLbZLTBxcCOWN52QBDniQVAE9GfD/MuuQHzk3QQ4 root@scientific

* Generierte Datei ''ssh_host_rsa_key.pub'' enthält den öffentlichen Schlüssel des Systems.
* Dieser lässt sich an Clients verteilen.
* Datei ''ssh_host_rsa_key'' enthält privaten Schlüssel des Servers (geheim halten).

Folgende Kommandos können vom Clientsystem verwendet werden um den öffentlichen Schlüssel zu importieren:

# scp scientific:/etc/ssh/ssh_host_rsa_key.pub ./
# cat ssh_host_rsa_key.pub >> /etc/ssh/ssh_known_hosts
# rm ssh_host_rsa_key.pub

===Benutzerauthentifizierung mit Schlüsseln===

Hostkeys können auch zur Authentifizierung von Benutzern verwendet werden.
Verzichtet man auf ein Passwortes, lassen sich ''ssh'' oder ''scp'' in Skripten z. B. für Backups zu verwenden.
Generierung der Schlüssel ebenfalls mittels ''ssh-keygen''.

Schlüssel werden automatisch an der richtigen Stelle abgelegt:

$ ssh-keygen -t ecdsa
Generating public/private ecdsa key pair.
Enter file in which to save the key (/home/harald/.ssh/id_ecdsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/harald/.ssh/id_ecdsa.
Your public key has been saved in /home/harald/.ssh/id_ecdsa.pub.
The key fingerprint is:
SHA256:Br+8SdXitm/XnUmqVQB1/+aO0HkJKsrbAjzvTwV8FNI user@10.0.0.1

Der Schlüssel wurde ohne passphrase erstellt und muss jetzt auf die Zielsysteme verteilt werden. 

Dafür verwendet man das komfortable Tool ''ssh-copy-id'':

$ ssh-copy-id user
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed:
"/home/harald/.ssh/id_ecdsa.pub"
The authenticity of host 'archangel (192.168.178.2)' can't be established.
ECDSA key fingerprint is SHA256:VOrsAcZc//9EiAATV2DfSN2jHONQBEuJpyrmW+Q3CWQ.
ECDSA key fingerprint is MD5:8d:28:e5:f1:3b:e2:fd:69:cf:28:d9:06:5e:30:f3:30.
Are you sure you want to continue connecting (yes/no)? yes
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s),
to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are
prompted now it is to install the new keys

Der Schlüssel wurde in die Datei ~/.ssh/authorized_keys des Zielsystems (user) eingetragen und muss nun bei weiteren Anmeldungen nicht mehr angegeben werden. 

Die Dateinamen der Benutzerschlüssel und Serverschlüssel sind Prüfungsrelevant. 
Sie befinden sich allesamt im Verzeichnis ~/.ssh eines Benutzers und lauten auf diese Dateinamen:

id_rsa
id_rsa.pub
id_dsa
id_dsa.pub
id_ecdsa
id_ecdsa.pub
id_ed25519
id_ed25519.pub

Die Dateinamen zu den Schlüsseln sind im Unterkapitel Hostkeys beschrieben. 
Für die Authentifizierung wird nur ein Schlüsselpaar benötigt. 
Server und Client Schlüsseltyp müssen natürlich identisch sein.

===Der Authentifizierungsagent===

Der SSH-Agent ist eine weitere Möglichkeit ohne Passwörter Authentifizierungen auszuführen. 
Es lassen sich mehrere Schlüssel für einen Benutzer verwalten. 
Dafür muss er bei der Startphase von X ausgeführt werden. 
''ssh-add'' kann dem SSH-Agent Schlüssel hinzufügen. 
Ohne Optionen sucht das Programm automatisch nach 
~/.ssh/id_rsa, ~/.ssh/id_dsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ed25519 und ~/.ssh/identity. 

Wichtige Optionen sind:

-l – listet die Fingerabdrücke der verfügbaren Schlüssel auf.
-d – entfernt einen einzelnen (angegebenen) Schlüssel vom Agenten.
-D – entfernt alle Schlüssel vom Agenten.
-s – liest Schlüssel von einer Smartcard.
-e – entfernt Schlüssel der Smartcard.
-x – sperrt den Agenten (mit Passwortschutz).
-X – entsperrt den Agenten.

[[Category:Linux]]

LPIC102/110.3 SSH Authentifizierung mit Schlüsseln

2019-07-29T19:10:15Z

Meikschwalm: /* Authentifizierung der Server mit Schlüsseln */

'''Vorführung presentationsrechner überträgt schlüssel zu meik rechner und hinterlegt seinen privatkey danach profil erstellung in konsole um einfache handhabung zu zeigen'''

===Authentifizierung der Server mit Schlüsseln===
* Server authentifiziert sich am Client mit seinem Hostkey. 
* Ist der Ziel-Host dem Client noch nicht bekannt, erfolgt eine Warnmeldung. 
* In der Meldung erscheint auch der Fingerprint des Hostkeys:

[root@scientific /]# ssh uvm1.nwa-net.de
The authenticity of host
uvm1.nwa-net.de (176.95.26.236)' can't be established.
ECDSA key fingerprint is SHA256:TbVCtl6TJHAHacrTdwh9gqzvx8fB5bzhi1lL/ByFbYE.
ECDSA key fingerprint is MD5:c8:db:4a:6f:99:7a:e9:9d:ca:82:c7:36:99:ac:14:c9.
Are you sure you want to continue connecting (yes/no)?

* Bestätigt man mit yes, wird der Hostkey des Servers in die Datei ''~./ssh/known_hosts'' des Benutzers eingetragen und die Verbindung hergestellt.
* Bei späteren Anmeldungen entfällt entsprechend die Warnmeldung.
* Folgendes Kommando zeigt eine Liste der bekannten Hosts

# ssh-keygen -l -f ~/.ssh/known_hosts
256 SHA256:VOrsAcZc//9EiAATV2DfSN2jHONQBEuJpyrmW+Q3CWQ
user,192.168.178.2 (ECDSA)
256 SHA256:TbVCtl6TJHAHacrTdwh9gqzvx8fB5bzhi1lL/ByFbYE
uvm1.nwa-net.de,176.95.26.236 (ECDSA)

* Ändert sich der Schlüssel eines Zielsystems, erfolgt die Warnmeldung:

$ ssh scientific
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:r+9OEu2EM5ubr0P5wl4lLgUo5n/8/AkX2exIiPqQ9rs.
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /root/.ssh/known_hosts:15
ECDSA host key for scientific has changed and you have requested strict checking.
Host key verification failed.

* Wenn es sich um keine echte man-in-the-middle-attack handelt, entfernt man mithilfe eines Editors den veralteten Schlüssel aus der known_hosts-Datei und baut die Verbindung erneut auf.

* Die Datei ''/etc/ssh/ssh_known_hosts'' macht nichts anderes als die Datei ''~/.ssh/known_hosts'' für jeden Benutzer, nur eben am Client.

==Hostkeys==

* OpenSSH erstellt in der Regel automatisch Hostkeys.
* Sie dienen der Authentifizierung zwischen Server und Clientcomputer.

ssh_host_dsa_key
ssh_host_dsa_key.pub
ssh_host_ecdsa_key
ssh_host_ecdsa_key.pub
ssh_host_ed25519_key
ssh_host_ed25519_key.pub
ssh_host_rsa_key
ssh_host_rsa_key.pub

* Ohne Dateierweiterung = privater Schlüssel.
* Mit Erweiterung .pub = öffentlicher (public) Schlüssel.
* Die Konfigurationsdatei dazu ist ''sshd_config''.

Erläuterung zu den einzelnen Schlüsseldateien:

* DSA: veraltet, bekannte Schwächen, wird nicht mehr unterstützt. 
* ECDSA: Momentan Standard bei Linux-Distributionen, kleinere Schlüsselgrößen als etwa RSA, Verdacht die gleichen Schwächen aufzuweisen wie DSA.
* RSA: etablierter Standard, überall unterstützt, existiert seit 1977. 
* Ed25519: ähnelt technisch ECDSA, weist jedoch nicht dieselbe Schwäche auf. 
* Wird von sehr neuen SSH-Versionen unterstützt, empfiehlt sich daher nicht als Standalone-Lösung, wenn man auch ältere Clientsysteme im Einsatz hat. 

* ''ssh-keygen'' generiert neue Schlüssel.
* Optional die Pfadangabe des Users angeben.
* Option ''–t'' legt den Typ des Schlüssels fest.
* Zur Auswahl stehen rsa, dsa, ecdsa und ed25519.

'''Beispiel:'''
* Erstellen eines neuen Schlüsselpaares für RSA.
* Benutzereingaben fett gedruckt.
* Es wurde keine passphrase verwendet.

# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
/etc/ssh/ssh_host_rsa_key
/etc/ssh/ssh_host_rsa_key already exists.
Overwrite (y/n)? y
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /etc/ssh/ssh_host_rsa_key.
Your public key has been saved in /etc/ssh/ssh_host_rsa_key.pub.
The key fingerprint is:
SHA256:zinmLbZLTBxcCOWN52QBDniQVAE9GfD/MuuQHzk3QQ4 root@scientific

* Generierte Datei ''ssh_host_rsa_key.pub'' enthält den öffentlichen Schlüssel des Systems.
* Dieser lässt sich an Clients verteilen.
* Datei ''ssh_host_rsa_key'' enthält privaten Schlüssel des Servers (geheim halten).

Folgende Kommandos können vom Clientsystem verwendet werden um den öffentlichen Schlüssel zu importieren:

# scp scientific:/etc/ssh/ssh_host_rsa_key.pub ./
# cat ssh_host_rsa_key.pub >> /etc/ssh/ssh_known_hosts
# rm ssh_host_rsa_key.pub

===Benutzerauthentifizierung mit Schlüsseln===

Hostkeys können auch zur Authentifizierung von Benutzern verwendet werden.
Verzichtet man auf ein Passwortes, lassen sich ''ssh'' oder ''scp'' in Skripten z. B. für Backups zu verwenden.
Generierung der Schlüssel ebenfalls mittels ''ssh-keygen''.

Schlüssel werden automatisch an der richtigen Stelle abgelegt:

$ ssh-keygen -t ecdsa
Generating public/private ecdsa key pair.
Enter file in which to save the key (/home/harald/.ssh/id_ecdsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/harald/.ssh/id_ecdsa.
Your public key has been saved in /home/harald/.ssh/id_ecdsa.pub.
The key fingerprint is:
SHA256:Br+8SdXitm/XnUmqVQB1/+aO0HkJKsrbAjzvTwV8FNI user@10.0.0.1

Der Schlüssel wurde ohne passphrase erstellt und muss jetzt auf die Zielsysteme verteilt werden. 

Dafür verwendet man das komfortable Tool ''ssh-copy-id'':

$ ssh-copy-id user
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed:
"/home/harald/.ssh/id_ecdsa.pub"
The authenticity of host 'archangel (192.168.178.2)' can't be established.
ECDSA key fingerprint is SHA256:VOrsAcZc//9EiAATV2DfSN2jHONQBEuJpyrmW+Q3CWQ.
ECDSA key fingerprint is MD5:8d:28:e5:f1:3b:e2:fd:69:cf:28:d9:06:5e:30:f3:30.
Are you sure you want to continue connecting (yes/no)? yes
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s),
to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are
prompted now it is to install the new keys

Der Schlüssel wurde in die Datei ~/.ssh/authorized_keys des Zielsystems (user) eingetragen und muss nun bei weiteren Anmeldungen nicht mehr angegeben werden. 

Die Dateinamen der Benutzerschlüssel und Serverschlüssel sind Prüfungsrelevant. 
Sie befinden sich allesamt im Verzeichnis ~/.ssh eines Benutzers und lauten auf diese Dateinamen:

id_rsa
id_rsa.pub
id_dsa
id_dsa.pub
id_ecdsa
id_ecdsa.pub
id_ed25519
id_ed25519.pub

Die Dateinamen zu den Schlüsseln sind im Unterkapitel Hostkeys beschrieben. 
Für die Authentifizierung wird nur ein Schlüsselpaar benötigt. 
Server und Client Schlüsseltyp müssen natürlich identisch sein.

===Der Authentifizierungsagent===

Der SSH-Agent ist eine weitere Möglichkeit ohne Passwörter Authentifizierungen auszuführen. 
Es lassen sich mehrere Schlüssel für einen Benutzer verwalten. 
Dafür muss er bei der Startphase von X ausgeführt werden. 
''ssh-add'' kann dem SSH-Agent Schlüssel hinzufügen. 
Ohne Optionen sucht das Programm automatisch nach 
~/.ssh/id_rsa, ~/.ssh/id_dsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ed25519 und ~/.ssh/identity. 

Wichtige Optionen sind:

-l – listet die Fingerabdrücke der verfügbaren Schlüssel auf.
-d – entfernt einen einzelnen (angegebenen) Schlüssel vom Agenten.
-D – entfernt alle Schlüssel vom Agenten.
-s – liest Schlüssel von einer Smartcard.
-e – entfernt Schlüssel der Smartcard.
-x – sperrt den Agenten (mit Passwortschutz).
-X – entsperrt den Agenten.

[[Category:Linux]]

LPIC102/110.3 SSH Authentifizierung mit Schlüsseln

2019-07-29T19:09:01Z

Meikschwalm: /* /etc/ssh/ssh_known_hosts */

'''Vorführung presentationsrechner überträgt schlüssel zu meik rechner und hinterlegt seinen privatkey danach profil erstellung in konsole um einfache handhabung zu zeigen'''

===Authentifizierung der Server mit Schlüsseln===
* Server authentifiziert sich am Client mit seinem Hostkey. 
* Ist der Ziel-Host dem Client noch nicht bekannt, erfolgt eine Warnmeldung. 
* In der Meldung erscheint auch der Fingerprint des Hostkeys:

[root@scientific /]# ssh uvm1.nwa-net.de
The authenticity of host
uvm1.nwa-net.de (176.95.26.236)' can't be established.
ECDSA key fingerprint is SHA256:TbVCtl6TJHAHacrTdwh9gqzvx8fB5bzhi1lL/ByFbYE.
ECDSA key fingerprint is MD5:c8:db:4a:6f:99:7a:e9:9d:ca:82:c7:36:99:ac:14:c9.
Are you sure you want to continue connecting (yes/no)?

* Bestätigt man mit yes, wird der Hostkey des Servers in die Datei ''~./ssh/known_hosts'' des Benutzers eingetragen und die Verbindung hergestellt.
* Bei späteren Anmeldungen entfällt entsprechend die Warnmeldung.
* Folgendes Kommando zeigt eine Liste der bekannten Hosts

# ssh-keygen -l -f ~/.ssh/known_hosts
256 SHA256:VOrsAcZc//9EiAATV2DfSN2jHONQBEuJpyrmW+Q3CWQ
user,192.168.178.2 (ECDSA)
256 SHA256:TbVCtl6TJHAHacrTdwh9gqzvx8fB5bzhi1lL/ByFbYE
uvm1.nwa-net.de,176.95.26.236 (ECDSA)

* Ändert sich der Schlüssel eines Zielsystems, erfolgt die Warnmeldung:

$ ssh scientific
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:r+9OEu2EM5ubr0P5wl4lLgUo5n/8/AkX2exIiPqQ9rs.
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /root/.ssh/known_hosts:15
ECDSA host key for scientific has changed and you have requested strict checking.
Host key verification failed.

* Wenn es sich um keine echte man-in-the-middle-attack handelt, entfernt man mithilfe eines Editors den veralteten Schlüssel aus der known_hosts-Datei und baut die Verbindung erneut auf.

* Die Datei ''/etc/ssh/ssh_known_hosts'' macht nichts anderes als die Datei ''~/.ssh/known_hosts'' für jeden Benutzer, nur eben zentralisiert.
==Hostkeys==

* OpenSSH erstellt in der Regel automatisch Hostkeys.
* Sie dienen der Authentifizierung zwischen Server und Clientcomputer.

ssh_host_dsa_key
ssh_host_dsa_key.pub
ssh_host_ecdsa_key
ssh_host_ecdsa_key.pub
ssh_host_ed25519_key
ssh_host_ed25519_key.pub
ssh_host_rsa_key
ssh_host_rsa_key.pub

* Ohne Dateierweiterung = privater Schlüssel.
* Mit Erweiterung .pub = öffentlicher (public) Schlüssel.
* Die Konfigurationsdatei dazu ist ''sshd_config''.

Erläuterung zu den einzelnen Schlüsseldateien:

* DSA: veraltet, bekannte Schwächen, wird nicht mehr unterstützt. 
* ECDSA: Momentan Standard bei Linux-Distributionen, kleinere Schlüsselgrößen als etwa RSA, Verdacht die gleichen Schwächen aufzuweisen wie DSA.
* RSA: etablierter Standard, überall unterstützt, existiert seit 1977. 
* Ed25519: ähnelt technisch ECDSA, weist jedoch nicht dieselbe Schwäche auf. 
* Wird von sehr neuen SSH-Versionen unterstützt, empfiehlt sich daher nicht als Standalone-Lösung, wenn man auch ältere Clientsysteme im Einsatz hat. 

* ''ssh-keygen'' generiert neue Schlüssel.
* Optional die Pfadangabe des Users angeben.
* Option ''–t'' legt den Typ des Schlüssels fest.
* Zur Auswahl stehen rsa, dsa, ecdsa und ed25519.

'''Beispiel:'''
* Erstellen eines neuen Schlüsselpaares für RSA.
* Benutzereingaben fett gedruckt.
* Es wurde keine passphrase verwendet.

# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
/etc/ssh/ssh_host_rsa_key
/etc/ssh/ssh_host_rsa_key already exists.
Overwrite (y/n)? y
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /etc/ssh/ssh_host_rsa_key.
Your public key has been saved in /etc/ssh/ssh_host_rsa_key.pub.
The key fingerprint is:
SHA256:zinmLbZLTBxcCOWN52QBDniQVAE9GfD/MuuQHzk3QQ4 root@scientific

* Generierte Datei ''ssh_host_rsa_key.pub'' enthält den öffentlichen Schlüssel des Systems.
* Dieser lässt sich an Clients verteilen.
* Datei ''ssh_host_rsa_key'' enthält privaten Schlüssel des Servers (geheim halten).

Folgende Kommandos können vom Clientsystem verwendet werden um den öffentlichen Schlüssel zu importieren:

# scp scientific:/etc/ssh/ssh_host_rsa_key.pub ./
# cat ssh_host_rsa_key.pub >> /etc/ssh/ssh_known_hosts
# rm ssh_host_rsa_key.pub

===Benutzerauthentifizierung mit Schlüsseln===

Hostkeys können auch zur Authentifizierung von Benutzern verwendet werden.
Verzichtet man auf ein Passwortes, lassen sich ''ssh'' oder ''scp'' in Skripten z. B. für Backups zu verwenden.
Generierung der Schlüssel ebenfalls mittels ''ssh-keygen''.

Schlüssel werden automatisch an der richtigen Stelle abgelegt:

$ ssh-keygen -t ecdsa
Generating public/private ecdsa key pair.
Enter file in which to save the key (/home/harald/.ssh/id_ecdsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/harald/.ssh/id_ecdsa.
Your public key has been saved in /home/harald/.ssh/id_ecdsa.pub.
The key fingerprint is:
SHA256:Br+8SdXitm/XnUmqVQB1/+aO0HkJKsrbAjzvTwV8FNI user@10.0.0.1

Der Schlüssel wurde ohne passphrase erstellt und muss jetzt auf die Zielsysteme verteilt werden. 

Dafür verwendet man das komfortable Tool ''ssh-copy-id'':

$ ssh-copy-id user
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed:
"/home/harald/.ssh/id_ecdsa.pub"
The authenticity of host 'archangel (192.168.178.2)' can't be established.
ECDSA key fingerprint is SHA256:VOrsAcZc//9EiAATV2DfSN2jHONQBEuJpyrmW+Q3CWQ.
ECDSA key fingerprint is MD5:8d:28:e5:f1:3b:e2:fd:69:cf:28:d9:06:5e:30:f3:30.
Are you sure you want to continue connecting (yes/no)? yes
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s),
to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are
prompted now it is to install the new keys

Der Schlüssel wurde in die Datei ~/.ssh/authorized_keys des Zielsystems (user) eingetragen und muss nun bei weiteren Anmeldungen nicht mehr angegeben werden. 

Die Dateinamen der Benutzerschlüssel und Serverschlüssel sind Prüfungsrelevant. 
Sie befinden sich allesamt im Verzeichnis ~/.ssh eines Benutzers und lauten auf diese Dateinamen:

id_rsa
id_rsa.pub
id_dsa
id_dsa.pub
id_ecdsa
id_ecdsa.pub
id_ed25519
id_ed25519.pub

Die Dateinamen zu den Schlüsseln sind im Unterkapitel Hostkeys beschrieben. 
Für die Authentifizierung wird nur ein Schlüsselpaar benötigt. 
Server und Client Schlüsseltyp müssen natürlich identisch sein.

===Der Authentifizierungsagent===

Der SSH-Agent ist eine weitere Möglichkeit ohne Passwörter Authentifizierungen auszuführen. 
Es lassen sich mehrere Schlüssel für einen Benutzer verwalten. 
Dafür muss er bei der Startphase von X ausgeführt werden. 
''ssh-add'' kann dem SSH-Agent Schlüssel hinzufügen. 
Ohne Optionen sucht das Programm automatisch nach 
~/.ssh/id_rsa, ~/.ssh/id_dsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ed25519 und ~/.ssh/identity. 

Wichtige Optionen sind:

-l – listet die Fingerabdrücke der verfügbaren Schlüssel auf.
-d – entfernt einen einzelnen (angegebenen) Schlüssel vom Agenten.
-D – entfernt alle Schlüssel vom Agenten.
-s – liest Schlüssel von einer Smartcard.
-e – entfernt Schlüssel der Smartcard.
-x – sperrt den Agenten (mit Passwortschutz).
-X – entsperrt den Agenten.

[[Category:Linux]]

LPIC102/110.3 SSH Authentifizierung mit Schlüsseln

2019-07-29T19:02:08Z

Meikschwalm: /* Authentifizierung der Server mit Schlüsseln */

'''Vorführung presentationsrechner überträgt schlüssel zu meik rechner und hinterlegt seinen privatkey danach profil erstellung in konsole um einfache handhabung zu zeigen'''

===Authentifizierung der Server mit Schlüsseln===
* Server authentifiziert sich am Client mit seinem Hostkey. 
* Ist der Ziel-Host dem Client noch nicht bekannt, erfolgt eine Warnmeldung. 
* In der Meldung erscheint auch der Fingerprint des Hostkeys:

[root@scientific /]# ssh uvm1.nwa-net.de
The authenticity of host
uvm1.nwa-net.de (176.95.26.236)' can't be established.
ECDSA key fingerprint is SHA256:TbVCtl6TJHAHacrTdwh9gqzvx8fB5bzhi1lL/ByFbYE.
ECDSA key fingerprint is MD5:c8:db:4a:6f:99:7a:e9:9d:ca:82:c7:36:99:ac:14:c9.
Are you sure you want to continue connecting (yes/no)?

* Bestätigt man mit yes, wird der Hostkey des Servers in die Datei ''~./ssh/known_hosts'' des Benutzers eingetragen und die Verbindung hergestellt.
* Bei späteren Anmeldungen entfällt entsprechend die Warnmeldung.
* Folgendes Kommando zeigt eine Liste der bekannten Hosts

# ssh-keygen -l -f ~/.ssh/known_hosts
256 SHA256:VOrsAcZc//9EiAATV2DfSN2jHONQBEuJpyrmW+Q3CWQ
user,192.168.178.2 (ECDSA)
256 SHA256:TbVCtl6TJHAHacrTdwh9gqzvx8fB5bzhi1lL/ByFbYE
uvm1.nwa-net.de,176.95.26.236 (ECDSA)

* Ändert sich der Schlüssel eines Zielsystems, erfolgt die Warnmeldung:

$ ssh scientific
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:r+9OEu2EM5ubr0P5wl4lLgUo5n/8/AkX2exIiPqQ9rs.
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /root/.ssh/known_hosts:15
ECDSA host key for scientific has changed and you have requested strict checking.
Host key verification failed.

* Wenn es sich um keine echte man-in-the-middle-attack handelt, entfernt man mithilfe eines Editors den veralteten Schlüssel aus der known_hosts-Datei und baut die Verbindung erneut auf.

==/etc/ssh/ssh_known_hosts==
 
Die Datei macht nichts anderes als die Datei ~/.ssh/known_hosts für jeden Benutzer, nur eben zentralisiert.

===Hostkeys===

OpenSSH erstellt in der Regel automatisch Hostkeys.
Sie dienen der Authentifizierung zwischen Server und Clientcomputer.

ssh_host_dsa_key
ssh_host_dsa_key.pub
ssh_host_ecdsa_key
ssh_host_ecdsa_key.pub
ssh_host_ed25519_key
ssh_host_ed25519_key.pub
ssh_host_rsa_key
ssh_host_rsa_key.pub

Ohne Dateierweiterung = privater Schlüssel. 
Mit Erweiterung .pub = öffentlicher (public) Schlüssel. 
Die Konfigurationsdatei dazu ist sshd_config. 

Erläuterung zu den einzelnen Schlüsseldateien: 

* DSA: veraltet, bekannte Schwächen, wird nicht mehr unterstützt. 
* ECDSA: Momentan Standard bei Linux-Distributionen, kleinere Schlüsselgrößen als etwa RSA, Verdacht die gleichen Schwächen aufzuweisen wie DSA.
* RSA: etablierter Standard, überall unterstützt, existiert seit 1977. 
* Ed25519: ähnelt technisch ECDSA, weist jedoch nicht dieselbe Schwäche auf. 
* Wird von sehr neuen SSH-Versionen unterstützt, empfiehlt sich daher nicht als Standalone-Lösung, wenn man auch ältere Clientsysteme im Einsatz hat. 

''ssh-keygen'' generiert neue Schlüssel. 
Optional die Pfadangabe des Users angeben. 
Option –t legt den Typ des Schlüssels fest. 
Zur Auswahl stehen rsa, dsa, ecdsa und ed25519. 

'''Beispiel:''' 
Erstellen eines neuen Schlüsselpaares für RSA. 
Benutzereingaben fett gedruckt. 
Es wurde keine passphrase verwendet.

# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
/etc/ssh/ssh_host_rsa_key
/etc/ssh/ssh_host_rsa_key already exists.
Overwrite (y/n)? y
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /etc/ssh/ssh_host_rsa_key.
Your public key has been saved in /etc/ssh/ssh_host_rsa_key.pub.
The key fingerprint is:
SHA256:zinmLbZLTBxcCOWN52QBDniQVAE9GfD/MuuQHzk3QQ4 root@scientific

Generierte Datei ssh_host_rsa_key.pub enthält den öffentlichen Schlüssel des Systems. 
Lässt sich an Clients verteilen. 
Datei ssh_host_rsa_key enthält privaten Schlüssel des Servers (geheim halten). 
Folgende Kommandos können vom Clientsystem verwendet werden um den öffentlichen Schlüssel zu importieren:

# scp scientific:/etc/ssh/ssh_host_rsa_key.pub ./
# cat ssh_host_rsa_key.pub >> /etc/ssh/ssh_known_hosts
# rm ssh_host_rsa_key.pub

===Benutzerauthentifizierung mit Schlüsseln===

Hostkeys können auch zur Authentifizierung von Benutzern verwendet werden. 
Verzichtet man auf ein Passwortes, lassen sich ssh oder scp in Skripten z. B. für Backups zu verwenden. 
Generierung der Schlüssel ebenfalls mittels ssh-keygen. 
Schlüssel werden automatisch an der richtigen Stelle abgelegt: 

$ ssh-keygen -t ecdsa
Generating public/private ecdsa key pair.
Enter file in which to save the key (/home/harald/.ssh/id_ecdsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/harald/.ssh/id_ecdsa.
Your public key has been saved in /home/harald/.ssh/id_ecdsa.pub.
The key fingerprint is:
SHA256:Br+8SdXitm/XnUmqVQB1/+aO0HkJKsrbAjzvTwV8FNI user@10.0.0.1

Der Schlüssel wurde ohne passphrase erstellt und muss jetzt auf die Zielsysteme verteilt werden. 

Dafür verwendet man das komfortable Tool ''ssh-copy-id'':

$ ssh-copy-id user
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed:
"/home/harald/.ssh/id_ecdsa.pub"
The authenticity of host 'archangel (192.168.178.2)' can't be established.
ECDSA key fingerprint is SHA256:VOrsAcZc//9EiAATV2DfSN2jHONQBEuJpyrmW+Q3CWQ.
ECDSA key fingerprint is MD5:8d:28:e5:f1:3b:e2:fd:69:cf:28:d9:06:5e:30:f3:30.
Are you sure you want to continue connecting (yes/no)? yes
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s),
to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are
prompted now it is to install the new keys

Der Schlüssel wurde in die Datei ~/.ssh/authorized_keys des Zielsystems (user) eingetragen und muss nun bei weiteren Anmeldungen nicht mehr angegeben werden. 

Die Dateinamen der Benutzerschlüssel und Serverschlüssel sind Prüfungsrelevant. 
Sie befinden sich allesamt im Verzeichnis ~/.ssh eines Benutzers und lauten auf diese Dateinamen:

id_rsa
id_rsa.pub
id_dsa
id_dsa.pub
id_ecdsa
id_ecdsa.pub
id_ed25519
id_ed25519.pub

Die Dateinamen zu den Schlüsseln sind im Unterkapitel Hostkeys beschrieben. 
Für die Authentifizierung wird nur ein Schlüsselpaar benötigt. 
Server und Client Schlüsseltyp müssen natürlich identisch sein.

===Der Authentifizierungsagent===

Der SSH-Agent ist eine weitere Möglichkeit ohne Passwörter Authentifizierungen auszuführen. 
Es lassen sich mehrere Schlüssel für einen Benutzer verwalten. 
Dafür muss er bei der Startphase von X ausgeführt werden. 
''ssh-add'' kann dem SSH-Agent Schlüssel hinzufügen. 
Ohne Optionen sucht das Programm automatisch nach 
~/.ssh/id_rsa, ~/.ssh/id_dsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ed25519 und ~/.ssh/identity. 

Wichtige Optionen sind:

-l – listet die Fingerabdrücke der verfügbaren Schlüssel auf.
-d – entfernt einen einzelnen (angegebenen) Schlüssel vom Agenten.
-D – entfernt alle Schlüssel vom Agenten.
-s – liest Schlüssel von einer Smartcard.
-e – entfernt Schlüssel der Smartcard.
-x – sperrt den Agenten (mit Passwortschutz).
-X – entsperrt den Agenten.

[[Category:Linux]]

LPIC102/110.3 SSH Authentifizierung mit Schlüsseln

2019-07-29T19:01:13Z

Meikschwalm: /* Authentifizierung der Server mit Schlüsseln */

'''Vorführung presentationsrechner überträgt schlüssel zu meik rechner und hinterlegt seinen privatkey danach profil erstellung in konsole um einfache handhabung zu zeigen'''

===Authentifizierung der Server mit Schlüsseln===
* Server authentifiziert sich am Client mit seinem Hostkey. 
* Ist der Ziel-Host dem Client noch nicht bekannt, erfolgt eine Warnmeldung. 
* In der Meldung erscheint auch der Fingerprint des Hostkeys:

[root@scientific /]# ssh uvm1.nwa-net.de
The authenticity of host
uvm1.nwa-net.de (176.95.26.236)' can't be established.
ECDSA key fingerprint is SHA256:TbVCtl6TJHAHacrTdwh9gqzvx8fB5bzhi1lL/ByFbYE.
ECDSA key fingerprint is MD5:c8:db:4a:6f:99:7a:e9:9d:ca:82:c7:36:99:ac:14:c9.
Are you sure you want to continue connecting (yes/no)?

* Bestätigt man mit yes, wird der Hostkey des Servers in die Datei ''~./ssh/known_hosts'' des Benutzers eingetragen und die Verbindung hergestellt.
* Bei späteren Anmeldungen entfällt entsprechend die Warnmeldung.
* Folgendes Kommando zeigt eine Liste der bekannten Hosts

# ssh-keygen -l -f ~/.ssh/known_hosts
256 SHA256:VOrsAcZc//9EiAATV2DfSN2jHONQBEuJpyrmW+Q3CWQ
user,192.168.178.2 (ECDSA)
256 SHA256:TbVCtl6TJHAHacrTdwh9gqzvx8fB5bzhi1lL/ByFbYE
uvm1.nwa-net.de,176.95.26.236 (ECDSA)

Ändert sich der Schlüssel eines Zielsystems, erfolgt die Warnmeldung:

$ ssh scientific
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:r+9OEu2EM5ubr0P5wl4lLgUo5n/8/AkX2exIiPqQ9rs.
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /root/.ssh/known_hosts:15
ECDSA host key for scientific has changed and you have requested strict checking.
Host key verification failed.

Wenn es sich um keine echte man-in-the-middle-attack handelt, entfernt man mithilfe eines Editors den veralteten Schlüssel aus der known_hosts-Datei und baut die Verbindung erneut auf.

==/etc/ssh/ssh_known_hosts==
 
Die Datei macht nichts anderes als die Datei ~/.ssh/known_hosts für jeden Benutzer, nur eben zentralisiert.

===Hostkeys===

OpenSSH erstellt in der Regel automatisch Hostkeys.
Sie dienen der Authentifizierung zwischen Server und Clientcomputer.

ssh_host_dsa_key
ssh_host_dsa_key.pub
ssh_host_ecdsa_key
ssh_host_ecdsa_key.pub
ssh_host_ed25519_key
ssh_host_ed25519_key.pub
ssh_host_rsa_key
ssh_host_rsa_key.pub

Ohne Dateierweiterung = privater Schlüssel. 
Mit Erweiterung .pub = öffentlicher (public) Schlüssel. 
Die Konfigurationsdatei dazu ist sshd_config. 

Erläuterung zu den einzelnen Schlüsseldateien: 

* DSA: veraltet, bekannte Schwächen, wird nicht mehr unterstützt. 
* ECDSA: Momentan Standard bei Linux-Distributionen, kleinere Schlüsselgrößen als etwa RSA, Verdacht die gleichen Schwächen aufzuweisen wie DSA.
* RSA: etablierter Standard, überall unterstützt, existiert seit 1977. 
* Ed25519: ähnelt technisch ECDSA, weist jedoch nicht dieselbe Schwäche auf. 
* Wird von sehr neuen SSH-Versionen unterstützt, empfiehlt sich daher nicht als Standalone-Lösung, wenn man auch ältere Clientsysteme im Einsatz hat. 

''ssh-keygen'' generiert neue Schlüssel. 
Optional die Pfadangabe des Users angeben. 
Option –t legt den Typ des Schlüssels fest. 
Zur Auswahl stehen rsa, dsa, ecdsa und ed25519. 

'''Beispiel:''' 
Erstellen eines neuen Schlüsselpaares für RSA. 
Benutzereingaben fett gedruckt. 
Es wurde keine passphrase verwendet.

# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
/etc/ssh/ssh_host_rsa_key
/etc/ssh/ssh_host_rsa_key already exists.
Overwrite (y/n)? y
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /etc/ssh/ssh_host_rsa_key.
Your public key has been saved in /etc/ssh/ssh_host_rsa_key.pub.
The key fingerprint is:
SHA256:zinmLbZLTBxcCOWN52QBDniQVAE9GfD/MuuQHzk3QQ4 root@scientific

Generierte Datei ssh_host_rsa_key.pub enthält den öffentlichen Schlüssel des Systems. 
Lässt sich an Clients verteilen. 
Datei ssh_host_rsa_key enthält privaten Schlüssel des Servers (geheim halten). 
Folgende Kommandos können vom Clientsystem verwendet werden um den öffentlichen Schlüssel zu importieren:

# scp scientific:/etc/ssh/ssh_host_rsa_key.pub ./
# cat ssh_host_rsa_key.pub >> /etc/ssh/ssh_known_hosts
# rm ssh_host_rsa_key.pub

===Benutzerauthentifizierung mit Schlüsseln===

Hostkeys können auch zur Authentifizierung von Benutzern verwendet werden. 
Verzichtet man auf ein Passwortes, lassen sich ssh oder scp in Skripten z. B. für Backups zu verwenden. 
Generierung der Schlüssel ebenfalls mittels ssh-keygen. 
Schlüssel werden automatisch an der richtigen Stelle abgelegt: 

$ ssh-keygen -t ecdsa
Generating public/private ecdsa key pair.
Enter file in which to save the key (/home/harald/.ssh/id_ecdsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/harald/.ssh/id_ecdsa.
Your public key has been saved in /home/harald/.ssh/id_ecdsa.pub.
The key fingerprint is:
SHA256:Br+8SdXitm/XnUmqVQB1/+aO0HkJKsrbAjzvTwV8FNI user@10.0.0.1

Der Schlüssel wurde ohne passphrase erstellt und muss jetzt auf die Zielsysteme verteilt werden. 

Dafür verwendet man das komfortable Tool ''ssh-copy-id'':

$ ssh-copy-id user
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed:
"/home/harald/.ssh/id_ecdsa.pub"
The authenticity of host 'archangel (192.168.178.2)' can't be established.
ECDSA key fingerprint is SHA256:VOrsAcZc//9EiAATV2DfSN2jHONQBEuJpyrmW+Q3CWQ.
ECDSA key fingerprint is MD5:8d:28:e5:f1:3b:e2:fd:69:cf:28:d9:06:5e:30:f3:30.
Are you sure you want to continue connecting (yes/no)? yes
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s),
to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are
prompted now it is to install the new keys

Der Schlüssel wurde in die Datei ~/.ssh/authorized_keys des Zielsystems (user) eingetragen und muss nun bei weiteren Anmeldungen nicht mehr angegeben werden. 

Die Dateinamen der Benutzerschlüssel und Serverschlüssel sind Prüfungsrelevant. 
Sie befinden sich allesamt im Verzeichnis ~/.ssh eines Benutzers und lauten auf diese Dateinamen:

id_rsa
id_rsa.pub
id_dsa
id_dsa.pub
id_ecdsa
id_ecdsa.pub
id_ed25519
id_ed25519.pub

Die Dateinamen zu den Schlüsseln sind im Unterkapitel Hostkeys beschrieben. 
Für die Authentifizierung wird nur ein Schlüsselpaar benötigt. 
Server und Client Schlüsseltyp müssen natürlich identisch sein.

===Der Authentifizierungsagent===

Der SSH-Agent ist eine weitere Möglichkeit ohne Passwörter Authentifizierungen auszuführen. 
Es lassen sich mehrere Schlüssel für einen Benutzer verwalten. 
Dafür muss er bei der Startphase von X ausgeführt werden. 
''ssh-add'' kann dem SSH-Agent Schlüssel hinzufügen. 
Ohne Optionen sucht das Programm automatisch nach 
~/.ssh/id_rsa, ~/.ssh/id_dsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ed25519 und ~/.ssh/identity. 

Wichtige Optionen sind:

-l – listet die Fingerabdrücke der verfügbaren Schlüssel auf.
-d – entfernt einen einzelnen (angegebenen) Schlüssel vom Agenten.
-D – entfernt alle Schlüssel vom Agenten.
-s – liest Schlüssel von einer Smartcard.
-e – entfernt Schlüssel der Smartcard.
-x – sperrt den Agenten (mit Passwortschutz).
-X – entsperrt den Agenten.

[[Category:Linux]]

LPIC102/110.3 SSH Authentifizierung mit Schlüsseln

2019-07-29T19:00:23Z

Meikschwalm: /* Authentifizierung der Server mit Schlüsseln */

'''Vorführung presentationsrechner überträgt schlüssel zu meik rechner und hinterlegt seinen privatkey danach profil erstellung in konsole um einfache handhabung zu zeigen'''

===Authentifizierung der Server mit Schlüsseln===
* Server authentifiziert sich am Client mit seinem Hostkey. 
* Ist der Ziel-Host dem Client noch nicht bekannt, erfolgt eine Warnmeldung. 
* In der Meldung erscheint auch der Fingerprint des Hostkeys:

[root@scientific /]# ssh uvm1.nwa-net.de
The authenticity of host
uvm1.nwa-net.de (176.95.26.236)' can't be established.
ECDSA key fingerprint is SHA256:TbVCtl6TJHAHacrTdwh9gqzvx8fB5bzhi1lL/ByFbYE.
ECDSA key fingerprint is MD5:c8:db:4a:6f:99:7a:e9:9d:ca:82:c7:36:99:ac:14:c9.
Are you sure you want to continue connecting (yes/no)?

* Bestätigt man mit yes, wird der Hostkey des Servers in die Datei ''~./ssh/known_hosts'' des Benutzers eingetragen und die Verbindung hergestellt.
* Bei späteren Anmeldungen entfällt entsprechend die Warnmeldung.

Folgendes Kommando zeigt eine Liste der bekannten Hosts

# ssh-keygen -l -f ~/.ssh/known_hosts
256 SHA256:VOrsAcZc//9EiAATV2DfSN2jHONQBEuJpyrmW+Q3CWQ
user,192.168.178.2 (ECDSA)
256 SHA256:TbVCtl6TJHAHacrTdwh9gqzvx8fB5bzhi1lL/ByFbYE
uvm1.nwa-net.de,176.95.26.236 (ECDSA)

Ändert sich der Schlüssel eines Zielsystems, erfolgt die Warnmeldung:

$ ssh scientific
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:r+9OEu2EM5ubr0P5wl4lLgUo5n/8/AkX2exIiPqQ9rs.
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /root/.ssh/known_hosts:15
ECDSA host key for scientific has changed and you have requested strict checking.
Host key verification failed.

Wenn es sich um keine echte man-in-the-middle-attack handelt, entfernt man mithilfe eines Editors den veralteten Schlüssel aus der known_hosts-Datei und baut die Verbindung erneut auf.

==/etc/ssh/ssh_known_hosts==
 
Die Datei macht nichts anderes als die Datei ~/.ssh/known_hosts für jeden Benutzer, nur eben zentralisiert.

===Hostkeys===

OpenSSH erstellt in der Regel automatisch Hostkeys.
Sie dienen der Authentifizierung zwischen Server und Clientcomputer.

ssh_host_dsa_key
ssh_host_dsa_key.pub
ssh_host_ecdsa_key
ssh_host_ecdsa_key.pub
ssh_host_ed25519_key
ssh_host_ed25519_key.pub
ssh_host_rsa_key
ssh_host_rsa_key.pub

Ohne Dateierweiterung = privater Schlüssel. 
Mit Erweiterung .pub = öffentlicher (public) Schlüssel. 
Die Konfigurationsdatei dazu ist sshd_config. 

Erläuterung zu den einzelnen Schlüsseldateien: 

* DSA: veraltet, bekannte Schwächen, wird nicht mehr unterstützt. 
* ECDSA: Momentan Standard bei Linux-Distributionen, kleinere Schlüsselgrößen als etwa RSA, Verdacht die gleichen Schwächen aufzuweisen wie DSA.
* RSA: etablierter Standard, überall unterstützt, existiert seit 1977. 
* Ed25519: ähnelt technisch ECDSA, weist jedoch nicht dieselbe Schwäche auf. 
* Wird von sehr neuen SSH-Versionen unterstützt, empfiehlt sich daher nicht als Standalone-Lösung, wenn man auch ältere Clientsysteme im Einsatz hat. 

''ssh-keygen'' generiert neue Schlüssel. 
Optional die Pfadangabe des Users angeben. 
Option –t legt den Typ des Schlüssels fest. 
Zur Auswahl stehen rsa, dsa, ecdsa und ed25519. 

'''Beispiel:''' 
Erstellen eines neuen Schlüsselpaares für RSA. 
Benutzereingaben fett gedruckt. 
Es wurde keine passphrase verwendet.

# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
/etc/ssh/ssh_host_rsa_key
/etc/ssh/ssh_host_rsa_key already exists.
Overwrite (y/n)? y
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /etc/ssh/ssh_host_rsa_key.
Your public key has been saved in /etc/ssh/ssh_host_rsa_key.pub.
The key fingerprint is:
SHA256:zinmLbZLTBxcCOWN52QBDniQVAE9GfD/MuuQHzk3QQ4 root@scientific

Generierte Datei ssh_host_rsa_key.pub enthält den öffentlichen Schlüssel des Systems. 
Lässt sich an Clients verteilen. 
Datei ssh_host_rsa_key enthält privaten Schlüssel des Servers (geheim halten). 
Folgende Kommandos können vom Clientsystem verwendet werden um den öffentlichen Schlüssel zu importieren:

# scp scientific:/etc/ssh/ssh_host_rsa_key.pub ./
# cat ssh_host_rsa_key.pub >> /etc/ssh/ssh_known_hosts
# rm ssh_host_rsa_key.pub

===Benutzerauthentifizierung mit Schlüsseln===

Hostkeys können auch zur Authentifizierung von Benutzern verwendet werden. 
Verzichtet man auf ein Passwortes, lassen sich ssh oder scp in Skripten z. B. für Backups zu verwenden. 
Generierung der Schlüssel ebenfalls mittels ssh-keygen. 
Schlüssel werden automatisch an der richtigen Stelle abgelegt: 

$ ssh-keygen -t ecdsa
Generating public/private ecdsa key pair.
Enter file in which to save the key (/home/harald/.ssh/id_ecdsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/harald/.ssh/id_ecdsa.
Your public key has been saved in /home/harald/.ssh/id_ecdsa.pub.
The key fingerprint is:
SHA256:Br+8SdXitm/XnUmqVQB1/+aO0HkJKsrbAjzvTwV8FNI user@10.0.0.1

Der Schlüssel wurde ohne passphrase erstellt und muss jetzt auf die Zielsysteme verteilt werden. 

Dafür verwendet man das komfortable Tool ''ssh-copy-id'':

$ ssh-copy-id user
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed:
"/home/harald/.ssh/id_ecdsa.pub"
The authenticity of host 'archangel (192.168.178.2)' can't be established.
ECDSA key fingerprint is SHA256:VOrsAcZc//9EiAATV2DfSN2jHONQBEuJpyrmW+Q3CWQ.
ECDSA key fingerprint is MD5:8d:28:e5:f1:3b:e2:fd:69:cf:28:d9:06:5e:30:f3:30.
Are you sure you want to continue connecting (yes/no)? yes
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s),
to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are
prompted now it is to install the new keys

Der Schlüssel wurde in die Datei ~/.ssh/authorized_keys des Zielsystems (user) eingetragen und muss nun bei weiteren Anmeldungen nicht mehr angegeben werden. 

Die Dateinamen der Benutzerschlüssel und Serverschlüssel sind Prüfungsrelevant. 
Sie befinden sich allesamt im Verzeichnis ~/.ssh eines Benutzers und lauten auf diese Dateinamen:

id_rsa
id_rsa.pub
id_dsa
id_dsa.pub
id_ecdsa
id_ecdsa.pub
id_ed25519
id_ed25519.pub

Die Dateinamen zu den Schlüsseln sind im Unterkapitel Hostkeys beschrieben. 
Für die Authentifizierung wird nur ein Schlüsselpaar benötigt. 
Server und Client Schlüsseltyp müssen natürlich identisch sein.

===Der Authentifizierungsagent===

Der SSH-Agent ist eine weitere Möglichkeit ohne Passwörter Authentifizierungen auszuführen. 
Es lassen sich mehrere Schlüssel für einen Benutzer verwalten. 
Dafür muss er bei der Startphase von X ausgeführt werden. 
''ssh-add'' kann dem SSH-Agent Schlüssel hinzufügen. 
Ohne Optionen sucht das Programm automatisch nach 
~/.ssh/id_rsa, ~/.ssh/id_dsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ed25519 und ~/.ssh/identity. 

Wichtige Optionen sind:

-l – listet die Fingerabdrücke der verfügbaren Schlüssel auf.
-d – entfernt einen einzelnen (angegebenen) Schlüssel vom Agenten.
-D – entfernt alle Schlüssel vom Agenten.
-s – liest Schlüssel von einer Smartcard.
-e – entfernt Schlüssel der Smartcard.
-x – sperrt den Agenten (mit Passwortschutz).
-X – entsperrt den Agenten.

[[Category:Linux]]

LPIC102/110.3 SSH Authentifizierung mit Schlüsseln

2019-07-29T18:59:43Z

Meikschwalm: /* Authentifizierung der Server mit Schlüsseln */

'''Vorführung presentationsrechner überträgt schlüssel zu meik rechner und hinterlegt seinen privatkey danach profil erstellung in konsole um einfache handhabung zu zeigen'''

===Authentifizierung der Server mit Schlüsseln===
* Server authentifiziert sich am Client mit seinem Hostkey. 
* Ist der Ziel-Host dem Client noch nicht bekannt, erfolgt eine Warnmeldung. 
* In der Meldung erscheint auch der Fingerprint des Hostkeys:

[root@scientific /]# ssh uvm1.nwa-net.de
The authenticity of host
uvm1.nwa-net.de (176.95.26.236)' can't be established.
ECDSA key fingerprint is SHA256:TbVCtl6TJHAHacrTdwh9gqzvx8fB5bzhi1lL/ByFbYE.
ECDSA key fingerprint is MD5:c8:db:4a:6f:99:7a:e9:9d:ca:82:c7:36:99:ac:14:c9.
Are you sure you want to continue connecting (yes/no)?

* Bestätigt man mit yes, wird der Hostkey des Servers in die Datei ''~./ssh/known_hosts''
* des Benutzers eingetragen und die Verbindung hergestellt.
* Bei späteren Anmeldungen entfällt entsprechend die Warnmeldung.

Folgendes Kommando zeigt eine Liste der bekannten Hosts

# ssh-keygen -l -f ~/.ssh/known_hosts
256 SHA256:VOrsAcZc//9EiAATV2DfSN2jHONQBEuJpyrmW+Q3CWQ
user,192.168.178.2 (ECDSA)
256 SHA256:TbVCtl6TJHAHacrTdwh9gqzvx8fB5bzhi1lL/ByFbYE
uvm1.nwa-net.de,176.95.26.236 (ECDSA)

* Ändert sich der Schlüssel eines Zielsystems, erfolgt die Warnmeldung:

$ ssh scientific
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:r+9OEu2EM5ubr0P5wl4lLgUo5n/8/AkX2exIiPqQ9rs.
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /root/.ssh/known_hosts:15
ECDSA host key for scientific has changed and you have requested strict checking.
Host key verification failed.

* Wenn es sich um keine echte man-in-the-middle-attack handelt, entfernt man mithilfe eines Editors den veralteten Schlüssel aus der known_hosts-Datei und baut die Verbindung erneut auf.

==/etc/ssh/ssh_known_hosts==
 
Die Datei macht nichts anderes als die Datei ~/.ssh/known_hosts für jeden Benutzer, nur eben zentralisiert.

===Hostkeys===

OpenSSH erstellt in der Regel automatisch Hostkeys.
Sie dienen der Authentifizierung zwischen Server und Clientcomputer.

ssh_host_dsa_key
ssh_host_dsa_key.pub
ssh_host_ecdsa_key
ssh_host_ecdsa_key.pub
ssh_host_ed25519_key
ssh_host_ed25519_key.pub
ssh_host_rsa_key
ssh_host_rsa_key.pub

Ohne Dateierweiterung = privater Schlüssel. 
Mit Erweiterung .pub = öffentlicher (public) Schlüssel. 
Die Konfigurationsdatei dazu ist sshd_config. 

Erläuterung zu den einzelnen Schlüsseldateien: 

* DSA: veraltet, bekannte Schwächen, wird nicht mehr unterstützt. 
* ECDSA: Momentan Standard bei Linux-Distributionen, kleinere Schlüsselgrößen als etwa RSA, Verdacht die gleichen Schwächen aufzuweisen wie DSA.
* RSA: etablierter Standard, überall unterstützt, existiert seit 1977. 
* Ed25519: ähnelt technisch ECDSA, weist jedoch nicht dieselbe Schwäche auf. 
* Wird von sehr neuen SSH-Versionen unterstützt, empfiehlt sich daher nicht als Standalone-Lösung, wenn man auch ältere Clientsysteme im Einsatz hat. 

''ssh-keygen'' generiert neue Schlüssel. 
Optional die Pfadangabe des Users angeben. 
Option –t legt den Typ des Schlüssels fest. 
Zur Auswahl stehen rsa, dsa, ecdsa und ed25519. 

'''Beispiel:''' 
Erstellen eines neuen Schlüsselpaares für RSA. 
Benutzereingaben fett gedruckt. 
Es wurde keine passphrase verwendet.

# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
/etc/ssh/ssh_host_rsa_key
/etc/ssh/ssh_host_rsa_key already exists.
Overwrite (y/n)? y
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /etc/ssh/ssh_host_rsa_key.
Your public key has been saved in /etc/ssh/ssh_host_rsa_key.pub.
The key fingerprint is:
SHA256:zinmLbZLTBxcCOWN52QBDniQVAE9GfD/MuuQHzk3QQ4 root@scientific

Generierte Datei ssh_host_rsa_key.pub enthält den öffentlichen Schlüssel des Systems. 
Lässt sich an Clients verteilen. 
Datei ssh_host_rsa_key enthält privaten Schlüssel des Servers (geheim halten). 
Folgende Kommandos können vom Clientsystem verwendet werden um den öffentlichen Schlüssel zu importieren:

# scp scientific:/etc/ssh/ssh_host_rsa_key.pub ./
# cat ssh_host_rsa_key.pub >> /etc/ssh/ssh_known_hosts
# rm ssh_host_rsa_key.pub

===Benutzerauthentifizierung mit Schlüsseln===

Hostkeys können auch zur Authentifizierung von Benutzern verwendet werden. 
Verzichtet man auf ein Passwortes, lassen sich ssh oder scp in Skripten z. B. für Backups zu verwenden. 
Generierung der Schlüssel ebenfalls mittels ssh-keygen. 
Schlüssel werden automatisch an der richtigen Stelle abgelegt: 

$ ssh-keygen -t ecdsa
Generating public/private ecdsa key pair.
Enter file in which to save the key (/home/harald/.ssh/id_ecdsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/harald/.ssh/id_ecdsa.
Your public key has been saved in /home/harald/.ssh/id_ecdsa.pub.
The key fingerprint is:
SHA256:Br+8SdXitm/XnUmqVQB1/+aO0HkJKsrbAjzvTwV8FNI user@10.0.0.1

Der Schlüssel wurde ohne passphrase erstellt und muss jetzt auf die Zielsysteme verteilt werden. 

Dafür verwendet man das komfortable Tool ''ssh-copy-id'':

$ ssh-copy-id user
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed:
"/home/harald/.ssh/id_ecdsa.pub"
The authenticity of host 'archangel (192.168.178.2)' can't be established.
ECDSA key fingerprint is SHA256:VOrsAcZc//9EiAATV2DfSN2jHONQBEuJpyrmW+Q3CWQ.
ECDSA key fingerprint is MD5:8d:28:e5:f1:3b:e2:fd:69:cf:28:d9:06:5e:30:f3:30.
Are you sure you want to continue connecting (yes/no)? yes
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s),
to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are
prompted now it is to install the new keys

Der Schlüssel wurde in die Datei ~/.ssh/authorized_keys des Zielsystems (user) eingetragen und muss nun bei weiteren Anmeldungen nicht mehr angegeben werden. 

Die Dateinamen der Benutzerschlüssel und Serverschlüssel sind Prüfungsrelevant. 
Sie befinden sich allesamt im Verzeichnis ~/.ssh eines Benutzers und lauten auf diese Dateinamen:

id_rsa
id_rsa.pub
id_dsa
id_dsa.pub
id_ecdsa
id_ecdsa.pub
id_ed25519
id_ed25519.pub

Die Dateinamen zu den Schlüsseln sind im Unterkapitel Hostkeys beschrieben. 
Für die Authentifizierung wird nur ein Schlüsselpaar benötigt. 
Server und Client Schlüsseltyp müssen natürlich identisch sein.

===Der Authentifizierungsagent===

Der SSH-Agent ist eine weitere Möglichkeit ohne Passwörter Authentifizierungen auszuführen. 
Es lassen sich mehrere Schlüssel für einen Benutzer verwalten. 
Dafür muss er bei der Startphase von X ausgeführt werden. 
''ssh-add'' kann dem SSH-Agent Schlüssel hinzufügen. 
Ohne Optionen sucht das Programm automatisch nach 
~/.ssh/id_rsa, ~/.ssh/id_dsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ed25519 und ~/.ssh/identity. 

Wichtige Optionen sind:

-l – listet die Fingerabdrücke der verfügbaren Schlüssel auf.
-d – entfernt einen einzelnen (angegebenen) Schlüssel vom Agenten.
-D – entfernt alle Schlüssel vom Agenten.
-s – liest Schlüssel von einer Smartcard.
-e – entfernt Schlüssel der Smartcard.
-x – sperrt den Agenten (mit Passwortschutz).
-X – entsperrt den Agenten.

[[Category:Linux]]

LPIC102/110.3 Schlüsselerstellung mit GnuPG

2019-07-29T11:16:34Z

Meikschwalm: Meikschwalm verschob die Seite Schlüsselerstellung mit GnuPG nach 110.3 Schlüsselerstellung mit GnuPG

===GnuPG===

GNU Privacy Guard, auch kurz als GPG bezeichnet

Auf einfache Weise Daten verschlüsseln oder signieren.
Bietet asymmetrisches Verschlüsselungsverfahren. Bedeutet, ein Schlüsselpaar ist erforderlich.
Der öffentliche Schlüssel ist der Verschlüsselungsschlüssel, der private Schlüssel ist der Entschlüsselungsschlüssel.
Der private Schlüssel wird beim Generieren von Signaturen verwendet.
Das sind zwei gute Gründe, den Schlüssel wie seinen eigenen Augapfel zu schützen.

Zur Sicherheit können Sie den Schlüssel der symmetrischen Verschlüsselung anschließend mit einem asymmetrischen 
Schlüssel verschlüsseln. 
Man spricht dann bei dem verwendeten öffentlichen Schlüssel auch von einem Schlüsselverschlüsselungsschlüssel.

Eine grafische Benutzeroberfläche bietet der GNU Privacy Assistant (GPA)
für GNOME das Programm Seahorse, und für KDE wurde KGpg entwickelt.

Damit Windows-Computer in einem solchen Umfeld nicht zur Sicherheitslücke werden, können diese Gpg4win einsetzen,
das übrigens absolut kompatibel zu den Linux-Versionen ist.

[[Category:Linux]]

LPIC102/110.3 Schlüsselerstellung mit GnuPG

2019-07-29T11:16:03Z

Meikschwalm: Die Seite wurde neu angelegt: „===GnuPG=== GNU Privacy Guard, auch kurz als GPG bezeichnet Auf einfache Weise Daten verschlüsseln oder signieren. Bietet asymmetrisches Verschlüsselungsv…“

LPIC102/110.3 SSH Authentifizierung mit Schlüsseln

2019-07-29T11:11:33Z

Meikschwalm: /* GnuPG */

'''Vorführung presentationsrechner überträgt schlüssel zu meik rechner und hinterlegt seinen privatkey danach profil erstellung in konsole um einfache handhabung zu zeigen'''

===Authentifizierung der Server mit Schlüsseln===
Server authentifiziert sich am Client mit seinem Hostkey. 
Ist der Ziel-Host dem Client noch nicht bekannt, erfolgt eine Warnmeldung. 
In der Meldung erscheint auch der Fingerprint des Hostkeys:

[root@scientific /]# ssh uvm1.nwa-net.de
The authenticity of host
uvm1.nwa-net.de (176.95.26.236)' can't be established.
ECDSA key fingerprint is SHA256:TbVCtl6TJHAHacrTdwh9gqzvx8fB5bzhi1lL/ByFbYE.
ECDSA key fingerprint is MD5:c8:db:4a:6f:99:7a:e9:9d:ca:82:c7:36:99:ac:14:c9.
Are you sure you want to continue connecting (yes/no)?

Bestätigt man mit yes, wird der Hostkey des Servers in die Datei ~./ssh/known_hosts 
des Benutzers eingetragen und die Verbindung hergestellt. 
Bei späteren Anmeldungen entfällt entsprechend die Warnmeldung. 

Folgendes Kommando zeigt eine Liste der bekannten Hosts

# ssh-keygen -l -f ~/.ssh/known_hosts
256 SHA256:VOrsAcZc//9EiAATV2DfSN2jHONQBEuJpyrmW+Q3CWQ
user,192.168.178.2 (ECDSA)
256 SHA256:TbVCtl6TJHAHacrTdwh9gqzvx8fB5bzhi1lL/ByFbYE
uvm1.nwa-net.de,176.95.26.236 (ECDSA)

Ändert sich der Schlüssel eines Zielsystems, erfolgt die Warnmeldung:

$ ssh scientific
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:r+9OEu2EM5ubr0P5wl4lLgUo5n/8/AkX2exIiPqQ9rs.
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /root/.ssh/known_hosts:15
ECDSA host key for scientific has changed and you have requested strict checking.
Host key verification failed.

Wenn es sich um keine echte man-in-the-middle-attack handelt, entfernt man mithilfe eines Editors den veralteten Schlüssel aus der known_hosts-Datei und baut die Verbindung erneut auf.

==/etc/ssh/ssh_known_hosts==
 
Die Datei macht nichts anderes als die Datei ~/.ssh/known_hosts für jeden Benutzer, nur eben zentralisiert.

===Hostkeys===

OpenSSH erstellt in der Regel automatisch Hostkeys.
Sie dienen der Authentifizierung zwischen Server und Clientcomputer.

ssh_host_dsa_key
ssh_host_dsa_key.pub
ssh_host_ecdsa_key
ssh_host_ecdsa_key.pub
ssh_host_ed25519_key
ssh_host_ed25519_key.pub
ssh_host_rsa_key
ssh_host_rsa_key.pub

Ohne Dateierweiterung = privater Schlüssel. 
Mit Erweiterung .pub = öffentlicher (public) Schlüssel. 
Die Konfigurationsdatei dazu ist sshd_config. 

Erläuterung zu den einzelnen Schlüsseldateien: 

* DSA: veraltet, bekannte Schwächen, wird nicht mehr unterstützt. 
* ECDSA: Momentan Standard bei Linux-Distributionen, kleinere Schlüsselgrößen als etwa RSA, Verdacht die gleichen Schwächen aufzuweisen wie DSA.
* RSA: etablierter Standard, überall unterstützt, existiert seit 1977. 
* Ed25519: ähnelt technisch ECDSA, weist jedoch nicht dieselbe Schwäche auf. 
* Wird von sehr neuen SSH-Versionen unterstützt, empfiehlt sich daher nicht als Standalone-Lösung, wenn man auch ältere Clientsysteme im Einsatz hat. 

''ssh-keygen'' generiert neue Schlüssel. 
Optional die Pfadangabe des Users angeben. 
Option –t legt den Typ des Schlüssels fest. 
Zur Auswahl stehen rsa, dsa, ecdsa und ed25519. 

'''Beispiel:''' 
Erstellen eines neuen Schlüsselpaares für RSA. 
Benutzereingaben fett gedruckt. 
Es wurde keine passphrase verwendet.

# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
/etc/ssh/ssh_host_rsa_key
/etc/ssh/ssh_host_rsa_key already exists.
Overwrite (y/n)? y
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /etc/ssh/ssh_host_rsa_key.
Your public key has been saved in /etc/ssh/ssh_host_rsa_key.pub.
The key fingerprint is:
SHA256:zinmLbZLTBxcCOWN52QBDniQVAE9GfD/MuuQHzk3QQ4 root@scientific

Generierte Datei ssh_host_rsa_key.pub enthält den öffentlichen Schlüssel des Systems. 
Lässt sich an Clients verteilen. 
Datei ssh_host_rsa_key enthält privaten Schlüssel des Servers (geheim halten). 
Folgende Kommandos können vom Clientsystem verwendet werden um den öffentlichen Schlüssel zu importieren:

# scp scientific:/etc/ssh/ssh_host_rsa_key.pub ./
# cat ssh_host_rsa_key.pub >> /etc/ssh/ssh_known_hosts
# rm ssh_host_rsa_key.pub

===Benutzerauthentifizierung mit Schlüsseln===

Hostkeys können auch zur Authentifizierung von Benutzern verwendet werden. 
Verzichtet man auf ein Passwortes, lassen sich ssh oder scp in Skripten z. B. für Backups zu verwenden. 
Generierung der Schlüssel ebenfalls mittels ssh-keygen. 
Schlüssel werden automatisch an der richtigen Stelle abgelegt: 

$ ssh-keygen -t ecdsa
Generating public/private ecdsa key pair.
Enter file in which to save the key (/home/harald/.ssh/id_ecdsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/harald/.ssh/id_ecdsa.
Your public key has been saved in /home/harald/.ssh/id_ecdsa.pub.
The key fingerprint is:
SHA256:Br+8SdXitm/XnUmqVQB1/+aO0HkJKsrbAjzvTwV8FNI user@10.0.0.1

Der Schlüssel wurde ohne passphrase erstellt und muss jetzt auf die Zielsysteme verteilt werden. 

Dafür verwendet man das komfortable Tool ''ssh-copy-id'':

$ ssh-copy-id user
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed:
"/home/harald/.ssh/id_ecdsa.pub"
The authenticity of host 'archangel (192.168.178.2)' can't be established.
ECDSA key fingerprint is SHA256:VOrsAcZc//9EiAATV2DfSN2jHONQBEuJpyrmW+Q3CWQ.
ECDSA key fingerprint is MD5:8d:28:e5:f1:3b:e2:fd:69:cf:28:d9:06:5e:30:f3:30.
Are you sure you want to continue connecting (yes/no)? yes
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s),
to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are
prompted now it is to install the new keys

Der Schlüssel wurde in die Datei ~/.ssh/authorized_keys des Zielsystems (user) eingetragen und muss nun bei weiteren Anmeldungen nicht mehr angegeben werden. 

Die Dateinamen der Benutzerschlüssel und Serverschlüssel sind Prüfungsrelevant. 
Sie befinden sich allesamt im Verzeichnis ~/.ssh eines Benutzers und lauten auf diese Dateinamen:

id_rsa
id_rsa.pub
id_dsa
id_dsa.pub
id_ecdsa
id_ecdsa.pub
id_ed25519
id_ed25519.pub

Die Dateinamen zu den Schlüsseln sind im Unterkapitel Hostkeys beschrieben. 
Für die Authentifizierung wird nur ein Schlüsselpaar benötigt. 
Server und Client Schlüsseltyp müssen natürlich identisch sein.

===Der Authentifizierungsagent===

Der SSH-Agent ist eine weitere Möglichkeit ohne Passwörter Authentifizierungen auszuführen. 
Es lassen sich mehrere Schlüssel für einen Benutzer verwalten. 
Dafür muss er bei der Startphase von X ausgeführt werden. 
''ssh-add'' kann dem SSH-Agent Schlüssel hinzufügen. 
Ohne Optionen sucht das Programm automatisch nach 
~/.ssh/id_rsa, ~/.ssh/id_dsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ed25519 und ~/.ssh/identity. 

Wichtige Optionen sind:

-l – listet die Fingerabdrücke der verfügbaren Schlüssel auf.
-d – entfernt einen einzelnen (angegebenen) Schlüssel vom Agenten.
-D – entfernt alle Schlüssel vom Agenten.
-s – liest Schlüssel von einer Smartcard.
-e – entfernt Schlüssel der Smartcard.
-x – sperrt den Agenten (mit Passwortschutz).
-X – entsperrt den Agenten.

[[Category:Linux]]

LPIC102/110.3 SSH Authentifizierung mit Schlüsseln

2019-07-29T11:05:56Z

Meikschwalm: /* Benutzerauthentifizierung mit Schlüsseln */

'''Vorführung presentationsrechner überträgt schlüssel zu meik rechner und hinterlegt seinen privatkey danach profil erstellung in konsole um einfache handhabung zu zeigen'''

===Authentifizierung der Server mit Schlüsseln===
Server authentifiziert sich am Client mit seinem Hostkey. 
Ist der Ziel-Host dem Client noch nicht bekannt, erfolgt eine Warnmeldung. 
In der Meldung erscheint auch der Fingerprint des Hostkeys:

[root@scientific /]# ssh uvm1.nwa-net.de
The authenticity of host
uvm1.nwa-net.de (176.95.26.236)' can't be established.
ECDSA key fingerprint is SHA256:TbVCtl6TJHAHacrTdwh9gqzvx8fB5bzhi1lL/ByFbYE.
ECDSA key fingerprint is MD5:c8:db:4a:6f:99:7a:e9:9d:ca:82:c7:36:99:ac:14:c9.
Are you sure you want to continue connecting (yes/no)?

Bestätigt man mit yes, wird der Hostkey des Servers in die Datei ~./ssh/known_hosts 
des Benutzers eingetragen und die Verbindung hergestellt. 
Bei späteren Anmeldungen entfällt entsprechend die Warnmeldung. 

Folgendes Kommando zeigt eine Liste der bekannten Hosts

# ssh-keygen -l -f ~/.ssh/known_hosts
256 SHA256:VOrsAcZc//9EiAATV2DfSN2jHONQBEuJpyrmW+Q3CWQ
user,192.168.178.2 (ECDSA)
256 SHA256:TbVCtl6TJHAHacrTdwh9gqzvx8fB5bzhi1lL/ByFbYE
uvm1.nwa-net.de,176.95.26.236 (ECDSA)

Ändert sich der Schlüssel eines Zielsystems, erfolgt die Warnmeldung:

$ ssh scientific
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:r+9OEu2EM5ubr0P5wl4lLgUo5n/8/AkX2exIiPqQ9rs.
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /root/.ssh/known_hosts:15
ECDSA host key for scientific has changed and you have requested strict checking.
Host key verification failed.

Wenn es sich um keine echte man-in-the-middle-attack handelt, entfernt man mithilfe eines Editors den veralteten Schlüssel aus der known_hosts-Datei und baut die Verbindung erneut auf.

==/etc/ssh/ssh_known_hosts==
 
Die Datei macht nichts anderes als die Datei ~/.ssh/known_hosts für jeden Benutzer, nur eben zentralisiert.

===Hostkeys===

OpenSSH erstellt in der Regel automatisch Hostkeys.
Sie dienen der Authentifizierung zwischen Server und Clientcomputer.

ssh_host_dsa_key
ssh_host_dsa_key.pub
ssh_host_ecdsa_key
ssh_host_ecdsa_key.pub
ssh_host_ed25519_key
ssh_host_ed25519_key.pub
ssh_host_rsa_key
ssh_host_rsa_key.pub

Ohne Dateierweiterung = privater Schlüssel. 
Mit Erweiterung .pub = öffentlicher (public) Schlüssel. 
Die Konfigurationsdatei dazu ist sshd_config. 

Erläuterung zu den einzelnen Schlüsseldateien: 

* DSA: veraltet, bekannte Schwächen, wird nicht mehr unterstützt. 
* ECDSA: Momentan Standard bei Linux-Distributionen, kleinere Schlüsselgrößen als etwa RSA, Verdacht die gleichen Schwächen aufzuweisen wie DSA.
* RSA: etablierter Standard, überall unterstützt, existiert seit 1977. 
* Ed25519: ähnelt technisch ECDSA, weist jedoch nicht dieselbe Schwäche auf. 
* Wird von sehr neuen SSH-Versionen unterstützt, empfiehlt sich daher nicht als Standalone-Lösung, wenn man auch ältere Clientsysteme im Einsatz hat. 

''ssh-keygen'' generiert neue Schlüssel. 
Optional die Pfadangabe des Users angeben. 
Option –t legt den Typ des Schlüssels fest. 
Zur Auswahl stehen rsa, dsa, ecdsa und ed25519. 

'''Beispiel:''' 
Erstellen eines neuen Schlüsselpaares für RSA. 
Benutzereingaben fett gedruckt. 
Es wurde keine passphrase verwendet.

# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
/etc/ssh/ssh_host_rsa_key
/etc/ssh/ssh_host_rsa_key already exists.
Overwrite (y/n)? y
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /etc/ssh/ssh_host_rsa_key.
Your public key has been saved in /etc/ssh/ssh_host_rsa_key.pub.
The key fingerprint is:
SHA256:zinmLbZLTBxcCOWN52QBDniQVAE9GfD/MuuQHzk3QQ4 root@scientific

Generierte Datei ssh_host_rsa_key.pub enthält den öffentlichen Schlüssel des Systems. 
Lässt sich an Clients verteilen. 
Datei ssh_host_rsa_key enthält privaten Schlüssel des Servers (geheim halten). 
Folgende Kommandos können vom Clientsystem verwendet werden um den öffentlichen Schlüssel zu importieren:

# scp scientific:/etc/ssh/ssh_host_rsa_key.pub ./
# cat ssh_host_rsa_key.pub >> /etc/ssh/ssh_known_hosts
# rm ssh_host_rsa_key.pub

===Benutzerauthentifizierung mit Schlüsseln===

Hostkeys können auch zur Authentifizierung von Benutzern verwendet werden. 
Verzichtet man auf ein Passwortes, lassen sich ssh oder scp in Skripten z. B. für Backups zu verwenden. 
Generierung der Schlüssel ebenfalls mittels ssh-keygen. 
Schlüssel werden automatisch an der richtigen Stelle abgelegt: 

$ ssh-keygen -t ecdsa
Generating public/private ecdsa key pair.
Enter file in which to save the key (/home/harald/.ssh/id_ecdsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/harald/.ssh/id_ecdsa.
Your public key has been saved in /home/harald/.ssh/id_ecdsa.pub.
The key fingerprint is:
SHA256:Br+8SdXitm/XnUmqVQB1/+aO0HkJKsrbAjzvTwV8FNI user@10.0.0.1

Der Schlüssel wurde ohne passphrase erstellt und muss jetzt auf die Zielsysteme verteilt werden. 

Dafür verwendet man das komfortable Tool ''ssh-copy-id'':

$ ssh-copy-id user
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed:
"/home/harald/.ssh/id_ecdsa.pub"
The authenticity of host 'archangel (192.168.178.2)' can't be established.
ECDSA key fingerprint is SHA256:VOrsAcZc//9EiAATV2DfSN2jHONQBEuJpyrmW+Q3CWQ.
ECDSA key fingerprint is MD5:8d:28:e5:f1:3b:e2:fd:69:cf:28:d9:06:5e:30:f3:30.
Are you sure you want to continue connecting (yes/no)? yes
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s),
to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are
prompted now it is to install the new keys

Der Schlüssel wurde in die Datei ~/.ssh/authorized_keys des Zielsystems (user) eingetragen und muss nun bei weiteren Anmeldungen nicht mehr angegeben werden. 

Die Dateinamen der Benutzerschlüssel und Serverschlüssel sind Prüfungsrelevant. 
Sie befinden sich allesamt im Verzeichnis ~/.ssh eines Benutzers und lauten auf diese Dateinamen:

id_rsa
id_rsa.pub
id_dsa
id_dsa.pub
id_ecdsa
id_ecdsa.pub
id_ed25519
id_ed25519.pub

Die Dateinamen zu den Schlüsseln sind im Unterkapitel Hostkeys beschrieben. 
Für die Authentifizierung wird nur ein Schlüsselpaar benötigt. 
Server und Client Schlüsseltyp müssen natürlich identisch sein.

===Der Authentifizierungsagent===

Der SSH-Agent ist eine weitere Möglichkeit ohne Passwörter Authentifizierungen auszuführen. 
Es lassen sich mehrere Schlüssel für einen Benutzer verwalten. 
Dafür muss er bei der Startphase von X ausgeführt werden. 
''ssh-add'' kann dem SSH-Agent Schlüssel hinzufügen. 
Ohne Optionen sucht das Programm automatisch nach 
~/.ssh/id_rsa, ~/.ssh/id_dsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ed25519 und ~/.ssh/identity. 

Wichtige Optionen sind:

-l – listet die Fingerabdrücke der verfügbaren Schlüssel auf.
-d – entfernt einen einzelnen (angegebenen) Schlüssel vom Agenten.
-D – entfernt alle Schlüssel vom Agenten.
-s – liest Schlüssel von einer Smartcard.
-e – entfernt Schlüssel der Smartcard.
-x – sperrt den Agenten (mit Passwortschutz).
-X – entsperrt den Agenten.

===GnuPG===

GNU Privacy Guard, auch kurz als GPG bezeichnet

Auf einfache Weise Daten verschlüsseln oder signieren.
Bietet asymmetrisches Verschlüsselungsverfahren. Bedeutet, ein Schlüsselpaar ist erforderlich.
Der öffentliche Schlüssel ist der Verschlüsselungsschlüssel, der private Schlüssel ist der Entschlüsselungsschlüssel.
Der private Schlüssel wird beim Generieren von Signaturen verwendet.
Das sind zwei gute Gründe, den Schlüssel wie seinen eigenen Augapfel zu schützen.

Zur Sicherheit können Sie den Schlüssel der symmetrischen Verschlüsselung anschließend mit einem asymmetrischen 
Schlüssel verschlüsseln. 
Man spricht dann bei dem verwendeten öffentlichen Schlüssel auch von einem Schlüsselverschlüsselungsschlüssel.

Eine grafische Benutzeroberfläche bietet der GNU Privacy Assistant (GPA)
für GNOME das Programm Seahorse, und für KDE wurde KGpg entwickelt.

Damit Windows-Computer in einem solchen Umfeld nicht zur Sicherheitslücke werden, können diese Gpg4win einsetzen,
das übrigens absolut kompatibel zu den Linux-Versionen ist.

[[Category:Linux]]