fix(ssh): typos

chapters/01-ssh.tex

@@ -5,14 +5,17 @@
 Genau so wie eine Anmeldung am Linux-Rechner über ein Terminal (\textit{tty}),
 ist auch die Anmeldung eines Benutzers über das Netzwerk möglich. Das gleichnamige Programm und Protokoll \acrfull{acr:telnet} wurde durch das gleichnamige Programm und Protokoll \acrfull{acr:ssh} in laufe der Zeit ersetzt.
 
-Beim ersten Implementierung \acrshort{acr:ssh} von wird eine unverschlüsselte
+Bei der ersten Implementierung von \acrshort{acr:ssh} wird eine unverschlüsselte
 Verbindung zwischen den beteiligten Rechnern aufgebaut und die Identifizierung
 des Benutzers erfolgt nur durch dessen Namen und Passwort. Beim der zweiten
 Implementierung von \acrshort{acr:ssh}, wird eine verschlüsselte Verbindung
-aufgebaut, die sowohl das Abhören der Login-Daten, also auch der später
-gesendeten Daten nahezu unmöglich macht. Es wird sowohl ein rechnerspezifischer
-Schlüssel als auch ein benutzerspezifischer Schlüssel verwendet. Zu Testzwecken
-ist natürlich auch eine Verbindung zu dem eigenen Rechner (localhost) möglich.
+aufgebaut, die sowohl das Abhören der Login-Daten, als auch der später
+gesendeten Daten, nahezu unmöglich macht. Es wird sowohl ein rechnerspezifischer
+Schlüssel als auch ein benutzerspezifischer Schlüssel zur Verschlüsselung und
+Idenzifizierung verwendet.
+
+Zu Testzwecken können die nachfolgenden Aufgaben über eine Verbindung zu
+dem lokal laufenden \acrshort{acr:ssh}-Server gelöst werden.
 
 % #>------------------------------------------------------------------------<#
 \subsection{Relevante Befehle für die weiteren Übungen}%
@@ -20,8 +23,8 @@ ist natürlich auch eine Verbindung zu dem eigenen Rechner (localhost) möglich.
 
 \begin{itemize}[label={},itemsep=0pt]
   \item \textit{ssh:} Stellt eine verschlüsselte Verbindung zwischen zwei
-  Rechnern her, über die neben der Shell auch andere Programme der
-  \acrshort{acr:gui} angesprochen werden können.
+  Rechnern her, über die neben der Shell auch andere Programme angesprochen
+  werden können.
   \item \textit{scp:} Ermöglicht das bidirektionale kopieren von Dateien und Verzeichnissen zwischen zwei Rechnern über eine \acrshort{acr:ssh}-Verbindung.
 \end{itemize}
 
@@ -38,10 +41,11 @@ ist natürlich auch eine Verbindung zu dem eigenen Rechner (localhost) möglich.
 
 \begin{itemize}[label={},itemsep=0pt]
   \item \textbf{Aufgabe 2a:} Erkundigen Sie sich nach ihren
-  \acrshort{acr:ssh}-Zugangsdaten der Hochschule Trier.
+  \acrshort{acr:ssh}-Zugangsdaten, um sich am \acrshort{acr:ssh}-Server der
+  Hochschule Trier anmelden zu können.
   \item \textbf{Aufgabe 2b:} Melden Sie sich mit ihren
-  \acrshort{acr:ssh}-Zugangsdaten per \acrshort{acr:ssh} an dem Rechner
-  \textit{ssh.hochschule-trier.de} an.
+  \acrshort{acr:ssh}-Zugangsdaten per \acrshort{acr:ssh} an dem \acrshort{acr:ssh} -Server der
+  Hochschule Trier an.
 \end{itemize}
 
 % #>------------------------------------------------------------------------<#
@@ -60,7 +64,7 @@ einem gefälschten Server zu vermeiden.
 Die akzeptierten öffentlichen Schlüssel des Servers werden zur Abwehr von
 Man-in-the-Middle Attacken in der Datei \textit{known\_hosts} gespeichert. Diese
 befindet sich im Unterverzeichnis \textit{.ssh} des Heimatverzeichnis des
-Benutzers.
+verwendeten Benutzers.
 
 Solange der private Schlüssel nicht abhanden kommt und auf dritten Server
 repliziert und konfiguriert wird, ist bei der aktuellen Protokollversion 2 keine
@@ -76,32 +80,33 @@ mit einer entsprechenden Warnung abgebrochen.
   \textit{\textasciitilde/.ssh} auf ihrer lokalen VM. Was fällt Ihnen in Vergleich zu anderen Verzeichnissen auf?
 \end{itemize}
 
-Bisher melden Sie sich an ihrem virtuellen Server oder den der Hochschule Trier
-mit Benutzername und Passwort an. Die Daten werden zwar verschlüsselt übertragen
-und können daher auch nicht abgehört werden, aber ein Angreifer kann beliebig
-viele Passwörter per Brute-Force-Attacke an ihrem oder dem Server der Hochschule
-Trier ausprobieren. Bei schwachen Passwörtern wird es daher nicht allzu lange
-dauern, bis ein ernsthafter Angreifer erfolg hat. Bei einer frisch in Betrieb
-genommenen virtuellen Maschine in einem Rechenzentrum dauert es meist nur wenige
-Stunden, bis der erste derartige Angriff erfolgt! Daher sollte man so schnell
-wie möglich auf ein besseres Verfahren umstellen.
+Sie haben sich an ihrem lokal laufenden SSH-Server oder den der Hochschule Trier
+mit Benutzername und Passwort angemeldet. Die Daten werden zwar verschlüsselt
+übertragen und können daher auch nicht abgehört werden, aber ein Angreifer kann
+beliebig viele Passwörter per Brute-Force-Attacke an ihrem oder dem Server der
+Hochschule Trier ausprobieren. Bei schwachen Passwörtern wird es daher nicht
+allzu lange dauern, bis ein ernsthafter Angreifer erfolg hat. Bei einer frisch
+in Betrieb genommenen virtuellen Maschine in einem Rechenzentrum dauert es meist
+nur wenige Stunden, bis der erste derartige Angriff erfolgt! Daher sollte man so
+schnell wie möglich auf ein besseres Verfahren umstellen.
 
 Ähnlich wie die Authentifizierung der Rechner kann auch die Authentifizierung
 der Benutzer per Public-Key Verfahren konfiguriert werden. Der Benutzer, der
 sich unter einem entfernten Benutzer anmelden möchte, muss auf seinem lokalen
 Rechner ein Schlüsselpaar generieren und den öffentlichen Schlüssel im
 Heimatverzeichnis des entfernt liegenden Benutzer hinzufügen. Bei einem späteren
-Login wir dann mit Hilfe des privaten Schlüssels des Client festgestellt,
-dass der Anfragende tatsächlich der berechtigte Benutzer ist.
+Login wir dann mit Hilfe des privaten Schlüssels des Client authentifiziert und
+der Login gewährt.
 
 Die Schlüssel werden ebenfalls im Verzeichnis \textit{\textasciitilde/.ssh}
 gespeichert. Ändert man bei der Erzeugung des Schlüsselpaares den dazugehörigen
 Dateinamen, muss dieser bei jeder Verwendung angegeben werden! Alternativ kann
 auch die Konfigurationsdatei \textit{\textasciitilde/.ssh/config} erstellt
 werden, um dort den zugehörigen Schlüssel explizit anzugeben. Das Schlüsselpaar
-kann optional mit einer Passphrase (Passwort) gesichert werden, falls man jedoch
-automatische Logins z.B. für Backups wünscht, sollte man auf diese zusätzliche
-Sicherung verzichten.
+kann optional mit einer Passphrase (Passwort) gesichert werden. Falls man jedoch
+automatische Logins z.B. für Backups benötigt, sollte man auf diese zusätzliche
+Sicherung verzichten, da dies sonst nicht mehr automatisch (non-interactive)
+durch Jobs möglich ist.
 
 \begin{itemize}[label={},itemsep=0pt]
   \item \textbf{Aufgabe 3b:} Generieren Sie für ihren lokalen Benutzer eine
@@ -160,7 +165,7 @@ Server aussperrt, sind "Helping Hands" vom Provider meist nicht billig zu haben.
   \item \textbf{Aufgabe 4e:} Nach dem Speichern dieser Änderungen muss der
   \acrshort{acr:ssh}-Dienst mit \textit{systemctl restart ssh} neu gestartet werden
   \item \textbf{Aufgabe 4f:} Testen Sie die korrekte Funktionsfähigkeit dieser
-  Änderung mir einer zweiten \acrshort{acr:ssh}-Verbindung.
+  Änderung mit einer zweiten \acrshort{acr:ssh}-Verbindung.
 \end{itemize}
 
 % #>------------------------------------------------------------------------<#
@@ -171,7 +176,7 @@ Da Sie nun den Server erfolgreich auf Public-Key-Authentifizierung umgestellt
 haben, kann im nächsten Schritt die \acrshort{acr:ssh}-Client Konfiguration
 angepasst werden. Dazu ist die Datei \textit{\textasciitilde/.ssh/config}
 notwendig. Der \acrshort{acr:ssh}-Client liest die Datei ein und setzt die
-Konfiguration, welcher für den Verbindungsaufbau notwendig ist, rekursiv
+Konfiguration, welcher für den Verbindungsaufbau notwendig ist, rekursiv und
 abhängig von dem DNS-Namen, zusammen.
 
 Möchte man Beispielsweise eine Verbindung zu \textit{verwaltung.example.local}