Linupedia.org - Benutzerbeiträge [de]

SSH Konfiguration

2007-10-23T09:19:19Z

OsunSeyi: /* Troubleshooting */

== SSH KONFIGURATION ==

=== Wie funktioniert SSH? ===

1...................
: Auf dem Server-Rechner (remote) wird ein Host-Key-Paar (RSA) generiert. 
: - ein Verschlüsselungscode (public_key) 
: - ein Entschlüsselungscode (private_key) 
: Der 'public_key' (öffentlich pubizierter Schlüssel) dient als Erkennung 
: für die Klients. 
: Zusätzlich erzeugt der laufende Server-Prozeß ein Server-Key-Paar, daß nur im 
: Memory des Remote-Rechners gehalten und periodisch erneuert wird. Es dient der 
: Verschlüsselung. 

2...................
: Der lokale SSH-Client wendet sich an den SSH-Server auf dem Remote-Rechner, 
: um eine Verbindung aufzunehmen. 
: Der Server schickt dem Client daraufhin sowohl seinen 'public_key' als auch den 
: periodisch erzeugten öffentlichen Serverschlüssel. 

3...................
: Der Klient überprüft nun den erhaltenen 'public key' mit der Liste in 'known_hosts'. 
: Normalerweise wird er sofort nach seinem Passwort gefragt. 

4...................
: Existiert aber in 'known_hosts' noch kein zugehöriger Eintrag, so wird dieser hinzu- 
: gefügt. Dies erfordert eine ausdrücklicher Bestätigung durch den Benutzer. 
: Also wird der 'public_key' nur bei der ersten Kontaktaufname übermittelt, danach ist 
: er dem Klient bekannt. 
: Ändert er sich, wird der Klient die Kontaktaufname verweigern und wieder neu nachfragen. 

5...................
: Ab dann erzeugt der Client eine Zufallszahl und verschlüsselt diese unter Zuhilfename 
: der beiden übergebenen öffentlichen Schlüssel (Hostkey und Serverkey). 
: Diese Zufallszahl dient im weiteren Verlauf als der aktuelle Sitzungsschlüssel. 
: Da sich bei jeder Änderung des bereits verschlüsselt übermittelten Serverkeys auch der 
: aktuelle Sitzungsschlüsse ändert, entsteht eine Art 'doppelte Verschlüsselung'.

6...................
: Nun erst übergibt der Client Userid und Passwort und der Server startet eine Login-Shell 
: bzw. führt das gewünschte Kommando aus. 

Bei der Authentifizierung des Clients werden der Reihe nach verschiedene Verfahren ausprobiert. 
Dabei wird der Client als berechtigt betrachtet, sobald das erste Verfahren folgender Liste 
erfolgreich war: 

1...................
: Autentifikation entsprechend den r-Kommandos; 
: Unsicher und per Default deaktiviert. 

2...................
: Wie Punkt1; zusätzliche RSA-Authentifikation. 

3...................
: RSA-Authentifikation; dazu ist auf dem Remote-Rechner ein Eintrag in 
: ~/.ssh/authorized_keys erforderlich. 

4...................
: Durch Paßwort-Abfrage. 
 
<hr>

=== Dateien Serverseitig ===

* /etc/ssh/sshd_config 
: Der SSHD wird über diese Datei konfiguriert. 
: Meist sind fast alle Zeilen auskommentiert, 
: dies sollte die praktischen Bedürfnisse auch abdecken. 
: [[SSH_Konfiguration#Die_Datei_.2Fetc.2Fssh.2Fsshd_config:|Konfiguration]] 

* /etc/hosts.allow & deny 
: In aktuellen Implementierungen des Ssh-Daemons ist die Auswertung der Dateien 
: /etc/hosts.allow und /etc/hosts.deny zumeist fest verdrahtet: 

tux> strings /usr/sbin/sshd | egrep 'hosts.allow|hosts.deny'
hosts_allow_table
hosts_deny_table
/etc/hosts.allow
/etc/hosts.deny

# Zugang zur Secure Shell (hosts.allow)
sshd: LOCAL 
# oder genauer:
sshd: 192...(Klient-DNS)/255.255.255.0 *.Domäne: ALLOW 
# Alles pauschal verbieten (hosts.deny)
ALL: ALL

* /etc/nologin
: Wenn sie existiert, verweigert sshd jeden Einlogvorgang außer dem von root 
: (sofern root-Eingänge in der Konfigurationsdatei erlaubt waren). 
: Der Inhalt der Datei wird dem Client übermittelt. 

=== Dateien Clientseitig ===

* /etc/ssh/ssh_known_hosts & ~/.ssh/known_hosts 
: enthalten die Public-Keys aller bekannten Rechner. 
: Die globale Datei wird vom Systemverwalter administriert, 
: die userbezogene wird automatisch angelegt und erweitert. 
: enthält die folgenden Felder: 
: Hostnamen Bits Exponent Modulus Kommentar 
: Hostnamen ist eine durch Kommas getrennte Liste von Namen 
: (* und ? dürfen benutzt werden). 
: Wird mit dem vollständigen Hostnamen des Rechners verglichen, der sich anmelden will. 
: Bits, Exponent und Modulus werden direkt den Host-Schlüsseln entnommen, 
: die in den Dateien /etc/ssh/ssh_host_*_key.pub gespeichert sind. 
: Das optionale Kommentarfeld wird nicht ausgewertet. 

* /etc/ssh/ssh.config 
: Client-Einstellungen. 
 
<hr>
=== Schlüssel - passwortfreie Anmeldung ===

Der Befehl 'ssh-keygen' erzeugt und verwaltet die Schlüssel für SSH-Verbindungen. 
Normaluser können sich damit einen Schlüssel erzeugen, der Systemverwalter kann auch den
Host-Schlüssel damit anlegen. Diese Schlüssel sind nicht zwingend für den Gebrauch von SSH erforderlich, bestimmte Server verlangen ihn aber. 
Es stehen zwei Schlüsseltypen ('RSA' und 'DSA') zur Verfügung, erforderlich ist aber nur
einer von beiden. 
Man wird bei der Erstellung nach einem Passwort gefragt, muß aber keines angeben. 
'''Es ist also möglich, über diese Schlüsselpaare eine Authentifizierung ohne Passwort zu steuern.''' 

> ssh-keygen -t rsa
Password:
...
Generating public/private rsa key pair.
... in ~/.ssh/id_dra.pub 
> ssh-keygen -t dsa
Password:
...
Generating public/private dsa key pair.
... in ~/.ssh/id_dsa.pub

Der Inhalt mindestens einer der beiden Dateien 'id_rsa.pub' und 'id_dsa.pub' müssen auf dem
Remote-Rechner in die Datei $HOME/.ssh/authorized_keys eingetragen werden. Verzeichnis als
auch die Datei dürfen nur für den User lesbar und schreibbar sein. 
Die geht manuell oder mit: 

> ssh-copy-id -i /home/tux/.ssh/id_rsa.pub 192...(Server-DNS)
password:
...

In der Serverkonfiguration kann die Passwort-Authentifikation ausgeschaltet werden: 

/etc/ssh/sshd_config: 
# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no

Und gegebenenfalls: 

/etc/ssh/sshd_config: 
- PermitRootLogin yes/no

Der Server muß neu gestartet werden: 

> /etc/init.d/ssh restart

Ein Login erfolgt dann mit: 

> ssh -l user ServerDNS '''bzw:'''
> ssh user@ServerDNS
 
<hr>

=== Die Datei /etc/ssh/sshd_config: ===

* BatchMode yes/no 
: Die Abfrage nach dem Passwort oder der Passphrase wird unterbunden, 
: somit lassen sich z.B. Kommandos in Shellscripts ausführen. 
* Compression yes/no 
: Schaltet die Komprimierung der zu übertragenden Daten ein oder aus. 
* FallBackToRsh yes/no 
: Scheitert der Verbindungsaufbau zum Server (zB. weil dieser nicht aktiv ist), 
: kann eine Verbindung über rsh versucht werden. Default: 'no' 
* HostKey Dateiname 
: Spezifiziert die Datei, in der der Host-Schlüssel des Servers abgelegt ist. 
: Normalerweise ist das die Datei /etc/ssh/ssh_host_key. 
: Diese Datei darf nicht für alle Welt lesbar sein, 
: ansonsten verweigert sich sshd die Datei zu verwenden! 
* IgnoreRhosts yes/no 
: Sollen die Dateien ~/.rhosts und ~/.shosts ignoriert werden? 
* KeyRegenerationInterval Zeit 
: Die Anzahl der Sekunden, nach denen der Server-Schlüssel neu erstellt werden soll. 
: Standardmäßig sollte hier 3600 (eine Stunde) stehen. 
: Steht hier eine 0, so wird der Schlüssel niemals neu erstellt. 
* PermitRootLogin yes/no 
: Erlaubt, daß sich der Systemverwalter über ssh einloggen kann. 
* PasswordAuthentication yes/no 
: Soll eine Abfrage des Passwortes durchgeführt werden? 
: Steht der Wert auf »no«, ist ein Anmelden auf einem entfernten Rechner nur möglich, 
: wenn der eigene öffentliche Schlüssel dort bekannt ist. 
* Port n 
: Die Angabe auf welchem Port sshd laufen soll. Normalerweise ist es Port 22. 
* RhostsAuthentication yes/no 
: Ob bei der Authentifizierung die Dateien rhosts und /etc/hosts.equiv ausreichen, 
: soll auf »no« bleiben. 
* RhostsRSAAuthentication yes/no 
: Erlaubt die Benutzung von rhosts und /etc/hosts.equiv, 
: allerdings nur wenn die RSA-HOST-Authentifizierung erfolgreich war. 
: Default »yes«. 
* RSAAuthentication yes/no 
: Authentifizierung mittels RSA-Verschlüsselung. 
: Steht der Wert auf »yes«, sollte die Datei »~/.ssh/identity« 
: oder ein Authentifizierungsagent existieren. 
* StrictHostKeyChecking yes/no 
: Ein »yes« verschärft die Sicherheit, indem das Anmelden nur auf Rechnern gestattet wird, 
: die in den Datenbanken »/etc/known_hosts« bzw. »~/.ssh/known_hosts« enthalten sind. 
: Steht hier »no« werden neu besuchte Rechner automatisch der privaten Datei hinzugefügt. 
 
<hr>
=== Troubleshooting ===

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! 
: Schonmal auf den Server (mit gleicher IP) zugegriffen ? 
: (Schlüssel hat sich geändert) 

> ssh-keygen -R hostname
/home/tux/.ssh/known_hosts updated.
Original contents retained as /home/tux/.ssh/known_hosts.old

Falls es nicht geht: 
: Inhalt von ~/.ssh/known_hosts komplett löschen oder entsprechend editieren! 

Wenn weiter unten die Zeile kommt: 
'DSA host key for 141.44.198.20 has changed and you have requested strict checking.' 
: versuche es mit Änderung in: 
/etc/ssh/sshd_config 
StrictHostKeyChecking: yes/no/ask (def: ask) 

'''Immer noch Probleme?'''

Ist der ssh-Zugriff überhaupt möglich? 
: Ein beliebtes Problem ist '... key_exchange ... connection closed by foreign host'. 
: Das liegt dann meist daran, daß die Reverse-Auflösung der eigenen IP-Adresse nicht 
: mit dem Namen für den eigenen Host übereinstimmt. 
: Auf der anderen Seite in /etc/hosts.deny die ALL: PARANOID Zeile auskommentieren. 
: Oder DNS in Ordnung bringen! 

Passwort wird verlangt. 
: Meistens ein Problem der Permissions auf der eigenen und/oder der anderen Seite: 
: Das Verzeichnis .ssh/ und die die Datei .ssh/authorized_keys darf nur für den Eigentümer, 
: der auch der "angepeilte" Nutzer sein muß, schreibbar sein! 
: ssh -v ... hilft, diese Art von Problemen zu diagnostizieren.

Die SSH2 verlangt die Keys in ~/.ssh/authorized_keys2. 
: Die SSH2 auf Debian/GNU-Linux ist mögl. gepatcht und sucht die wie gehabt in: 
: ~/.ssh/authorized_keys, U.u. muß aber trotzdem auf SuSE-Systemen eben diese 2 angehängt werden. 

<hr>
:: '''Quellen:'''
::: [http://www.linux-praxis.de/lpic1/lpi102/1.113.7.html Einrichten von Secure Shell (OpenSSH) - LPI-Study Guides]
::: [http://de.linwiki.org/index.php/Linuxfibel_-_Netzwerk_Server_-_Telnet_%26_Co. Thomas Ermer / Michael Meyer: Linuxfibel - Netzwerk Server - Telnet & Co.]
::: [http://www.schlittermann.de/ssh Heiko Schlittermann: SSH ohne Passwort -- eine kurze Anleitung]
::: [http://www.lrz-muenchen.de/services/security/ssh/ssh-4.html Ernst Bötsch: Secure Shell (SSH) für Benutzer]
::: [http://www.jfranken.de/homepages/johannes/vortraege/ssh1_inhalt.de.html Johannes Franken: OpenSSH Grundlagen]

SSH Konfiguration

2007-10-23T09:18:18Z

OsunSeyi: /* Schlüssel - passwortfreie Anmeldung */

== SSH KONFIGURATION ==

=== Wie funktioniert SSH? ===

1...................
: Auf dem Server-Rechner (remote) wird ein Host-Key-Paar (RSA) generiert. 
: - ein Verschlüsselungscode (public_key) 
: - ein Entschlüsselungscode (private_key) 
: Der 'public_key' (öffentlich pubizierter Schlüssel) dient als Erkennung 
: für die Klients. 
: Zusätzlich erzeugt der laufende Server-Prozeß ein Server-Key-Paar, daß nur im 
: Memory des Remote-Rechners gehalten und periodisch erneuert wird. Es dient der 
: Verschlüsselung. 

2...................
: Der lokale SSH-Client wendet sich an den SSH-Server auf dem Remote-Rechner, 
: um eine Verbindung aufzunehmen. 
: Der Server schickt dem Client daraufhin sowohl seinen 'public_key' als auch den 
: periodisch erzeugten öffentlichen Serverschlüssel. 

3...................
: Der Klient überprüft nun den erhaltenen 'public key' mit der Liste in 'known_hosts'. 
: Normalerweise wird er sofort nach seinem Passwort gefragt. 

4...................
: Existiert aber in 'known_hosts' noch kein zugehöriger Eintrag, so wird dieser hinzu- 
: gefügt. Dies erfordert eine ausdrücklicher Bestätigung durch den Benutzer. 
: Also wird der 'public_key' nur bei der ersten Kontaktaufname übermittelt, danach ist 
: er dem Klient bekannt. 
: Ändert er sich, wird der Klient die Kontaktaufname verweigern und wieder neu nachfragen. 

5...................
: Ab dann erzeugt der Client eine Zufallszahl und verschlüsselt diese unter Zuhilfename 
: der beiden übergebenen öffentlichen Schlüssel (Hostkey und Serverkey). 
: Diese Zufallszahl dient im weiteren Verlauf als der aktuelle Sitzungsschlüssel. 
: Da sich bei jeder Änderung des bereits verschlüsselt übermittelten Serverkeys auch der 
: aktuelle Sitzungsschlüsse ändert, entsteht eine Art 'doppelte Verschlüsselung'.

6...................
: Nun erst übergibt der Client Userid und Passwort und der Server startet eine Login-Shell 
: bzw. führt das gewünschte Kommando aus. 

Bei der Authentifizierung des Clients werden der Reihe nach verschiedene Verfahren ausprobiert. 
Dabei wird der Client als berechtigt betrachtet, sobald das erste Verfahren folgender Liste 
erfolgreich war: 

1...................
: Autentifikation entsprechend den r-Kommandos; 
: Unsicher und per Default deaktiviert. 

2...................
: Wie Punkt1; zusätzliche RSA-Authentifikation. 

3...................
: RSA-Authentifikation; dazu ist auf dem Remote-Rechner ein Eintrag in 
: ~/.ssh/authorized_keys erforderlich. 

4...................
: Durch Paßwort-Abfrage. 
 
<hr>

=== Dateien Serverseitig ===

* /etc/ssh/sshd_config 
: Der SSHD wird über diese Datei konfiguriert. 
: Meist sind fast alle Zeilen auskommentiert, 
: dies sollte die praktischen Bedürfnisse auch abdecken. 
: [[SSH_Konfiguration#Die_Datei_.2Fetc.2Fssh.2Fsshd_config:|Konfiguration]] 

* /etc/hosts.allow & deny 
: In aktuellen Implementierungen des Ssh-Daemons ist die Auswertung der Dateien 
: /etc/hosts.allow und /etc/hosts.deny zumeist fest verdrahtet: 

tux> strings /usr/sbin/sshd | egrep 'hosts.allow|hosts.deny'
hosts_allow_table
hosts_deny_table
/etc/hosts.allow
/etc/hosts.deny

# Zugang zur Secure Shell (hosts.allow)
sshd: LOCAL 
# oder genauer:
sshd: 192...(Klient-DNS)/255.255.255.0 *.Domäne: ALLOW 
# Alles pauschal verbieten (hosts.deny)
ALL: ALL

* /etc/nologin
: Wenn sie existiert, verweigert sshd jeden Einlogvorgang außer dem von root 
: (sofern root-Eingänge in der Konfigurationsdatei erlaubt waren). 
: Der Inhalt der Datei wird dem Client übermittelt. 

=== Dateien Clientseitig ===

* /etc/ssh/ssh_known_hosts & ~/.ssh/known_hosts 
: enthalten die Public-Keys aller bekannten Rechner. 
: Die globale Datei wird vom Systemverwalter administriert, 
: die userbezogene wird automatisch angelegt und erweitert. 
: enthält die folgenden Felder: 
: Hostnamen Bits Exponent Modulus Kommentar 
: Hostnamen ist eine durch Kommas getrennte Liste von Namen 
: (* und ? dürfen benutzt werden). 
: Wird mit dem vollständigen Hostnamen des Rechners verglichen, der sich anmelden will. 
: Bits, Exponent und Modulus werden direkt den Host-Schlüsseln entnommen, 
: die in den Dateien /etc/ssh/ssh_host_*_key.pub gespeichert sind. 
: Das optionale Kommentarfeld wird nicht ausgewertet. 

* /etc/ssh/ssh.config 
: Client-Einstellungen. 
 
<hr>
=== Schlüssel - passwortfreie Anmeldung ===

Der Befehl 'ssh-keygen' erzeugt und verwaltet die Schlüssel für SSH-Verbindungen. 
Normaluser können sich damit einen Schlüssel erzeugen, der Systemverwalter kann auch den
Host-Schlüssel damit anlegen. Diese Schlüssel sind nicht zwingend für den Gebrauch von SSH erforderlich, bestimmte Server verlangen ihn aber. 
Es stehen zwei Schlüsseltypen ('RSA' und 'DSA') zur Verfügung, erforderlich ist aber nur
einer von beiden. 
Man wird bei der Erstellung nach einem Passwort gefragt, muß aber keines angeben. 
'''Es ist also möglich, über diese Schlüsselpaare eine Authentifizierung ohne Passwort zu steuern.''' 

> ssh-keygen -t rsa
Password:
...
Generating public/private rsa key pair.
... in ~/.ssh/id_dra.pub 
> ssh-keygen -t dsa
Password:
...
Generating public/private dsa key pair.
... in ~/.ssh/id_dsa.pub

Der Inhalt mindestens einer der beiden Dateien 'id_rsa.pub' und 'id_dsa.pub' müssen auf dem
Remote-Rechner in die Datei $HOME/.ssh/authorized_keys eingetragen werden. Verzeichnis als
auch die Datei dürfen nur für den User lesbar und schreibbar sein. 
Die geht manuell oder mit: 

> ssh-copy-id -i /home/tux/.ssh/id_rsa.pub 192...(Server-DNS)
password:
...

In der Serverkonfiguration kann die Passwort-Authentifikation ausgeschaltet werden: 

/etc/ssh/sshd_config: 
# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no

Und gegebenenfalls: 

/etc/ssh/sshd_config: 
- PermitRootLogin yes/no

Der Server muß neu gestartet werden: 

> /etc/init.d/ssh restart

Ein Login erfolgt dann mit: 

> ssh -l user ServerDNS '''bzw:'''
> ssh user@ServerDNS
 
<hr>

=== Die Datei /etc/ssh/sshd_config: ===

* BatchMode yes/no 
: Die Abfrage nach dem Passwort oder der Passphrase wird unterbunden, 
: somit lassen sich z.B. Kommandos in Shellscripts ausführen. 
* Compression yes/no 
: Schaltet die Komprimierung der zu übertragenden Daten ein oder aus. 
* FallBackToRsh yes/no 
: Scheitert der Verbindungsaufbau zum Server (zB. weil dieser nicht aktiv ist), 
: kann eine Verbindung über rsh versucht werden. Default: 'no' 
* HostKey Dateiname 
: Spezifiziert die Datei, in der der Host-Schlüssel des Servers abgelegt ist. 
: Normalerweise ist das die Datei /etc/ssh/ssh_host_key. 
: Diese Datei darf nicht für alle Welt lesbar sein, 
: ansonsten verweigert sich sshd die Datei zu verwenden! 
* IgnoreRhosts yes/no 
: Sollen die Dateien ~/.rhosts und ~/.shosts ignoriert werden? 
* KeyRegenerationInterval Zeit 
: Die Anzahl der Sekunden, nach denen der Server-Schlüssel neu erstellt werden soll. 
: Standardmäßig sollte hier 3600 (eine Stunde) stehen. 
: Steht hier eine 0, so wird der Schlüssel niemals neu erstellt. 
* PermitRootLogin yes/no 
: Erlaubt, daß sich der Systemverwalter über ssh einloggen kann. 
* PasswordAuthentication yes/no 
: Soll eine Abfrage des Passwortes durchgeführt werden? 
: Steht der Wert auf »no«, ist ein Anmelden auf einem entfernten Rechner nur möglich, 
: wenn der eigene öffentliche Schlüssel dort bekannt ist. 
* Port n 
: Die Angabe auf welchem Port sshd laufen soll. Normalerweise ist es Port 22. 
* RhostsAuthentication yes/no 
: Ob bei der Authentifizierung die Dateien rhosts und /etc/hosts.equiv ausreichen, 
: soll auf »no« bleiben. 
* RhostsRSAAuthentication yes/no 
: Erlaubt die Benutzung von rhosts und /etc/hosts.equiv, 
: allerdings nur wenn die RSA-HOST-Authentifizierung erfolgreich war. 
: Default »yes«. 
* RSAAuthentication yes/no 
: Authentifizierung mittels RSA-Verschlüsselung. 
: Steht der Wert auf »yes«, sollte die Datei »~/.ssh/identity« 
: oder ein Authentifizierungsagent existieren. 
* StrictHostKeyChecking yes/no 
: Ein »yes« verschärft die Sicherheit, indem das Anmelden nur auf Rechnern gestattet wird, 
: die in den Datenbanken »/etc/known_hosts« bzw. »~/.ssh/known_hosts« enthalten sind. 
: Steht hier »no« werden neu besuchte Rechner automatisch der privaten Datei hinzugefügt. 
 
<hr>
=== Troubleshooting ===

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! 
: Schonmal auf den Server (mit gleicher IP) zugegriffen ? 
: (Schlüssel hat sich geändert) 

> ssh-keygen -R hostname
/home/tux/.ssh/known_hosts updated.
Original contents retained as /home/tux/.ssh/known_hosts.old

Falls es nicht geht: 
: Inhalt von ~/.ssh/known_hosts komplett löschen oder entsprechend editieren! 

Wenn weiter unten die Zeile kommt: 
'DSA host key for 141.44.198.20 has changed and you have requested strict checking.' 
: versuche es mit Änderung in: 
/etc/ssh/sshd_config 
StrictHostKeyChecking: yes/no/ask (def: ask) 

'''Immer noch Probleme?'''

Ist der ssh-Zugriff überhaupt möglich? 
: Ein beliebtes Problem ist '... key_exchange ... connection closed by foreign host'. 
: Das liegt dann meist daran, daß die Reverse-Auflösung der eigenen IP-Adresse nicht 
: mit dem Namen für den eigenen Host übereinstimmt. 
: Auf der anderen Seite in /etc/hosts.deny die ALL: PARANOID Zeile auskommentieren. 
: Oder DNS in Ordnung bringen! 

Passwort wird verlangt. 
: Meistens ein Problem der Permissions auf der eigenen und/oder der anderen Seite: 
: Das Verzeichnis .ssh/ und die die Datei .ssh/authorized_keys darf nur für den Eigentümer, 
: der auch der "angepeilte" Nutzer sein muß, schreibbar sein! 
: ssh -v ... hilft, diese Art von Problemen zu diagnostizieren.

Die SSH2 verlangt die Keys in ~/.ssh/authorized_keys2. 
: Die SSH2 auf Debian/GNU-Linux ist mögl. gepatcht und sucht die wie gehabt in: 
: ~/.ssh/authorized_keys, U.u. muß aber trotzdem auf SuSE-Systemen eben diese 2 angehängt werden. 

<hr>
:: Quellen:
::: [http://www.linux-praxis.de/lpic1/lpi102/1.113.7.html Einrichten von Secure Shell (OpenSSH) - LPI-Study Guides]
::: [http://de.linwiki.org/index.php/Linuxfibel_-_Netzwerk_Server_-_Telnet_%26_Co. Thomas Ermer / Michael Meyer: Linuxfibel - Netzwerk Server - Telnet & Co.]
::: [http://www.schlittermann.de/ssh Heiko Schlittermann: SSH ohne Passwort -- eine kurze Anleitung]
::: [http://www.lrz-muenchen.de/services/security/ssh/ssh-4.html Ernst Bötsch: Secure Shell (SSH) für Benutzer]
::: [http://www.jfranken.de/homepages/johannes/vortraege/ssh1_inhalt.de.html Johannes Franken: OpenSSH Grundlagen]

SSH Konfiguration

2007-10-23T09:17:21Z

OsunSeyi: /* Schlüssel - passwortfreie Anmeldung */

== SSH KONFIGURATION ==

=== Wie funktioniert SSH? ===

1...................
: Auf dem Server-Rechner (remote) wird ein Host-Key-Paar (RSA) generiert. 
: - ein Verschlüsselungscode (public_key) 
: - ein Entschlüsselungscode (private_key) 
: Der 'public_key' (öffentlich pubizierter Schlüssel) dient als Erkennung 
: für die Klients. 
: Zusätzlich erzeugt der laufende Server-Prozeß ein Server-Key-Paar, daß nur im 
: Memory des Remote-Rechners gehalten und periodisch erneuert wird. Es dient der 
: Verschlüsselung. 

2...................
: Der lokale SSH-Client wendet sich an den SSH-Server auf dem Remote-Rechner, 
: um eine Verbindung aufzunehmen. 
: Der Server schickt dem Client daraufhin sowohl seinen 'public_key' als auch den 
: periodisch erzeugten öffentlichen Serverschlüssel. 

3...................
: Der Klient überprüft nun den erhaltenen 'public key' mit der Liste in 'known_hosts'. 
: Normalerweise wird er sofort nach seinem Passwort gefragt. 

4...................
: Existiert aber in 'known_hosts' noch kein zugehöriger Eintrag, so wird dieser hinzu- 
: gefügt. Dies erfordert eine ausdrücklicher Bestätigung durch den Benutzer. 
: Also wird der 'public_key' nur bei der ersten Kontaktaufname übermittelt, danach ist 
: er dem Klient bekannt. 
: Ändert er sich, wird der Klient die Kontaktaufname verweigern und wieder neu nachfragen. 

5...................
: Ab dann erzeugt der Client eine Zufallszahl und verschlüsselt diese unter Zuhilfename 
: der beiden übergebenen öffentlichen Schlüssel (Hostkey und Serverkey). 
: Diese Zufallszahl dient im weiteren Verlauf als der aktuelle Sitzungsschlüssel. 
: Da sich bei jeder Änderung des bereits verschlüsselt übermittelten Serverkeys auch der 
: aktuelle Sitzungsschlüsse ändert, entsteht eine Art 'doppelte Verschlüsselung'.

6...................
: Nun erst übergibt der Client Userid und Passwort und der Server startet eine Login-Shell 
: bzw. führt das gewünschte Kommando aus. 

Bei der Authentifizierung des Clients werden der Reihe nach verschiedene Verfahren ausprobiert. 
Dabei wird der Client als berechtigt betrachtet, sobald das erste Verfahren folgender Liste 
erfolgreich war: 

1...................
: Autentifikation entsprechend den r-Kommandos; 
: Unsicher und per Default deaktiviert. 

2...................
: Wie Punkt1; zusätzliche RSA-Authentifikation. 

3...................
: RSA-Authentifikation; dazu ist auf dem Remote-Rechner ein Eintrag in 
: ~/.ssh/authorized_keys erforderlich. 

4...................
: Durch Paßwort-Abfrage. 
 
<hr>

=== Dateien Serverseitig ===

* /etc/ssh/sshd_config 
: Der SSHD wird über diese Datei konfiguriert. 
: Meist sind fast alle Zeilen auskommentiert, 
: dies sollte die praktischen Bedürfnisse auch abdecken. 
: [[SSH_Konfiguration#Die_Datei_.2Fetc.2Fssh.2Fsshd_config:|Konfiguration]] 

* /etc/hosts.allow & deny 
: In aktuellen Implementierungen des Ssh-Daemons ist die Auswertung der Dateien 
: /etc/hosts.allow und /etc/hosts.deny zumeist fest verdrahtet: 

tux> strings /usr/sbin/sshd | egrep 'hosts.allow|hosts.deny'
hosts_allow_table
hosts_deny_table
/etc/hosts.allow
/etc/hosts.deny

# Zugang zur Secure Shell (hosts.allow)
sshd: LOCAL 
# oder genauer:
sshd: 192...(Klient-DNS)/255.255.255.0 *.Domäne: ALLOW 
# Alles pauschal verbieten (hosts.deny)
ALL: ALL

* /etc/nologin
: Wenn sie existiert, verweigert sshd jeden Einlogvorgang außer dem von root 
: (sofern root-Eingänge in der Konfigurationsdatei erlaubt waren). 
: Der Inhalt der Datei wird dem Client übermittelt. 

=== Dateien Clientseitig ===

* /etc/ssh/ssh_known_hosts & ~/.ssh/known_hosts 
: enthalten die Public-Keys aller bekannten Rechner. 
: Die globale Datei wird vom Systemverwalter administriert, 
: die userbezogene wird automatisch angelegt und erweitert. 
: enthält die folgenden Felder: 
: Hostnamen Bits Exponent Modulus Kommentar 
: Hostnamen ist eine durch Kommas getrennte Liste von Namen 
: (* und ? dürfen benutzt werden). 
: Wird mit dem vollständigen Hostnamen des Rechners verglichen, der sich anmelden will. 
: Bits, Exponent und Modulus werden direkt den Host-Schlüsseln entnommen, 
: die in den Dateien /etc/ssh/ssh_host_*_key.pub gespeichert sind. 
: Das optionale Kommentarfeld wird nicht ausgewertet. 

* /etc/ssh/ssh.config 
: Client-Einstellungen. 
 
<hr>
=== Schlüssel - passwortfreie Anmeldung ===

Der Befehl 'ssh-keygen' erzeugt und verwaltet die Schlüssel für SSH-Verbindungen. 
Normaluser können sich damit einen Schlüssel erzeugen, der Systemverwalter kann auch den
Host-Schlüssel damit anlegen. Diese Schlüssel sind nicht zwingend für den Gebrauch von SSH erforderlich, bestimmte Server verlangen ihn aber. 
Es stehen zwei Schlüsseltypen ('RSA' und 'DSA') zur Verfügung, erforderlich ist aber nur
einer von beiden. 
Man wird bei der Erstellung nach einem Passwort gefragt, muß aber keines angeben. 
'''Es ist also möglich, über diese Schlüsselpaare eine Authentifizierung ohne Passwort zu steuern.''' 

> ssh-keygen -t rsa
Password:
...
Generating public/private rsa key pair.
... in ~/.ssh/id_dra.pub 
> ssh-keygen -t dsa
Password:
...
Generating public/private dsa key pair.
... in ~/.ssh/id_dsa.pub

Der Inhalt mindestens einer der beiden Dateien 'id_rsa.pub' und 'id_dsa.pub' müssen auf dem
Remote-Rechner in die Datei $HOME/.ssh/authorized_keys eingetragen werden. Verzeichnis als
auch die Datei dürfen nur für den User lesbar und schreibbar sein. 
Die geht manuell oder mit: 

> ssh-copy-id -i /home/tux/.ssh/id_rsa.pub 192...(Server-DNS)
password:
...

In der Serverkonfiguration kann die Passwort-Authentifikation ausgeschaltet werden: 

/etc/ssh/sshd_config: 
# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no

Und gegebenenfalls: 

/etc/ssh/sshd_config: 
- PermitRootLogin yes/no

Der Server muß neu gestartet werden: 

> /etc/init.d/ssh restart

Ein Login erfolgt dann mit: 

> ssh -l user ServerDNS '''bzw'''
> ssh user@ServerDNS
 
<hr>

=== Die Datei /etc/ssh/sshd_config: ===

* BatchMode yes/no 
: Die Abfrage nach dem Passwort oder der Passphrase wird unterbunden, 
: somit lassen sich z.B. Kommandos in Shellscripts ausführen. 
* Compression yes/no 
: Schaltet die Komprimierung der zu übertragenden Daten ein oder aus. 
* FallBackToRsh yes/no 
: Scheitert der Verbindungsaufbau zum Server (zB. weil dieser nicht aktiv ist), 
: kann eine Verbindung über rsh versucht werden. Default: 'no' 
* HostKey Dateiname 
: Spezifiziert die Datei, in der der Host-Schlüssel des Servers abgelegt ist. 
: Normalerweise ist das die Datei /etc/ssh/ssh_host_key. 
: Diese Datei darf nicht für alle Welt lesbar sein, 
: ansonsten verweigert sich sshd die Datei zu verwenden! 
* IgnoreRhosts yes/no 
: Sollen die Dateien ~/.rhosts und ~/.shosts ignoriert werden? 
* KeyRegenerationInterval Zeit 
: Die Anzahl der Sekunden, nach denen der Server-Schlüssel neu erstellt werden soll. 
: Standardmäßig sollte hier 3600 (eine Stunde) stehen. 
: Steht hier eine 0, so wird der Schlüssel niemals neu erstellt. 
* PermitRootLogin yes/no 
: Erlaubt, daß sich der Systemverwalter über ssh einloggen kann. 
* PasswordAuthentication yes/no 
: Soll eine Abfrage des Passwortes durchgeführt werden? 
: Steht der Wert auf »no«, ist ein Anmelden auf einem entfernten Rechner nur möglich, 
: wenn der eigene öffentliche Schlüssel dort bekannt ist. 
* Port n 
: Die Angabe auf welchem Port sshd laufen soll. Normalerweise ist es Port 22. 
* RhostsAuthentication yes/no 
: Ob bei der Authentifizierung die Dateien rhosts und /etc/hosts.equiv ausreichen, 
: soll auf »no« bleiben. 
* RhostsRSAAuthentication yes/no 
: Erlaubt die Benutzung von rhosts und /etc/hosts.equiv, 
: allerdings nur wenn die RSA-HOST-Authentifizierung erfolgreich war. 
: Default »yes«. 
* RSAAuthentication yes/no 
: Authentifizierung mittels RSA-Verschlüsselung. 
: Steht der Wert auf »yes«, sollte die Datei »~/.ssh/identity« 
: oder ein Authentifizierungsagent existieren. 
* StrictHostKeyChecking yes/no 
: Ein »yes« verschärft die Sicherheit, indem das Anmelden nur auf Rechnern gestattet wird, 
: die in den Datenbanken »/etc/known_hosts« bzw. »~/.ssh/known_hosts« enthalten sind. 
: Steht hier »no« werden neu besuchte Rechner automatisch der privaten Datei hinzugefügt. 
 
<hr>
=== Troubleshooting ===

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! 
: Schonmal auf den Server (mit gleicher IP) zugegriffen ? 
: (Schlüssel hat sich geändert) 

> ssh-keygen -R hostname
/home/tux/.ssh/known_hosts updated.
Original contents retained as /home/tux/.ssh/known_hosts.old

Falls es nicht geht: 
: Inhalt von ~/.ssh/known_hosts komplett löschen oder entsprechend editieren! 

Wenn weiter unten die Zeile kommt: 
'DSA host key for 141.44.198.20 has changed and you have requested strict checking.' 
: versuche es mit Änderung in: 
/etc/ssh/sshd_config 
StrictHostKeyChecking: yes/no/ask (def: ask) 

'''Immer noch Probleme?'''

Ist der ssh-Zugriff überhaupt möglich? 
: Ein beliebtes Problem ist '... key_exchange ... connection closed by foreign host'. 
: Das liegt dann meist daran, daß die Reverse-Auflösung der eigenen IP-Adresse nicht 
: mit dem Namen für den eigenen Host übereinstimmt. 
: Auf der anderen Seite in /etc/hosts.deny die ALL: PARANOID Zeile auskommentieren. 
: Oder DNS in Ordnung bringen! 

Passwort wird verlangt. 
: Meistens ein Problem der Permissions auf der eigenen und/oder der anderen Seite: 
: Das Verzeichnis .ssh/ und die die Datei .ssh/authorized_keys darf nur für den Eigentümer, 
: der auch der "angepeilte" Nutzer sein muß, schreibbar sein! 
: ssh -v ... hilft, diese Art von Problemen zu diagnostizieren.

Die SSH2 verlangt die Keys in ~/.ssh/authorized_keys2. 
: Die SSH2 auf Debian/GNU-Linux ist mögl. gepatcht und sucht die wie gehabt in: 
: ~/.ssh/authorized_keys, U.u. muß aber trotzdem auf SuSE-Systemen eben diese 2 angehängt werden. 

<hr>
:: Quellen:
::: [http://www.linux-praxis.de/lpic1/lpi102/1.113.7.html Einrichten von Secure Shell (OpenSSH) - LPI-Study Guides]
::: [http://de.linwiki.org/index.php/Linuxfibel_-_Netzwerk_Server_-_Telnet_%26_Co. Thomas Ermer / Michael Meyer: Linuxfibel - Netzwerk Server - Telnet & Co.]
::: [http://www.schlittermann.de/ssh Heiko Schlittermann: SSH ohne Passwort -- eine kurze Anleitung]
::: [http://www.lrz-muenchen.de/services/security/ssh/ssh-4.html Ernst Bötsch: Secure Shell (SSH) für Benutzer]
::: [http://www.jfranken.de/homepages/johannes/vortraege/ssh1_inhalt.de.html Johannes Franken: OpenSSH Grundlagen]

SSH Konfiguration

2007-10-23T09:15:18Z

OsunSeyi: /* Schlüssel - passwortfreie Anmeldung */

== SSH KONFIGURATION ==

=== Wie funktioniert SSH? ===

1...................
: Auf dem Server-Rechner (remote) wird ein Host-Key-Paar (RSA) generiert. 
: - ein Verschlüsselungscode (public_key) 
: - ein Entschlüsselungscode (private_key) 
: Der 'public_key' (öffentlich pubizierter Schlüssel) dient als Erkennung 
: für die Klients. 
: Zusätzlich erzeugt der laufende Server-Prozeß ein Server-Key-Paar, daß nur im 
: Memory des Remote-Rechners gehalten und periodisch erneuert wird. Es dient der 
: Verschlüsselung. 

2...................
: Der lokale SSH-Client wendet sich an den SSH-Server auf dem Remote-Rechner, 
: um eine Verbindung aufzunehmen. 
: Der Server schickt dem Client daraufhin sowohl seinen 'public_key' als auch den 
: periodisch erzeugten öffentlichen Serverschlüssel. 

3...................
: Der Klient überprüft nun den erhaltenen 'public key' mit der Liste in 'known_hosts'. 
: Normalerweise wird er sofort nach seinem Passwort gefragt. 

4...................
: Existiert aber in 'known_hosts' noch kein zugehöriger Eintrag, so wird dieser hinzu- 
: gefügt. Dies erfordert eine ausdrücklicher Bestätigung durch den Benutzer. 
: Also wird der 'public_key' nur bei der ersten Kontaktaufname übermittelt, danach ist 
: er dem Klient bekannt. 
: Ändert er sich, wird der Klient die Kontaktaufname verweigern und wieder neu nachfragen. 

5...................
: Ab dann erzeugt der Client eine Zufallszahl und verschlüsselt diese unter Zuhilfename 
: der beiden übergebenen öffentlichen Schlüssel (Hostkey und Serverkey). 
: Diese Zufallszahl dient im weiteren Verlauf als der aktuelle Sitzungsschlüssel. 
: Da sich bei jeder Änderung des bereits verschlüsselt übermittelten Serverkeys auch der 
: aktuelle Sitzungsschlüsse ändert, entsteht eine Art 'doppelte Verschlüsselung'.

6...................
: Nun erst übergibt der Client Userid und Passwort und der Server startet eine Login-Shell 
: bzw. führt das gewünschte Kommando aus. 

Bei der Authentifizierung des Clients werden der Reihe nach verschiedene Verfahren ausprobiert. 
Dabei wird der Client als berechtigt betrachtet, sobald das erste Verfahren folgender Liste 
erfolgreich war: 

1...................
: Autentifikation entsprechend den r-Kommandos; 
: Unsicher und per Default deaktiviert. 

2...................
: Wie Punkt1; zusätzliche RSA-Authentifikation. 

3...................
: RSA-Authentifikation; dazu ist auf dem Remote-Rechner ein Eintrag in 
: ~/.ssh/authorized_keys erforderlich. 

4...................
: Durch Paßwort-Abfrage. 
 
<hr>

=== Dateien Serverseitig ===

* /etc/ssh/sshd_config 
: Der SSHD wird über diese Datei konfiguriert. 
: Meist sind fast alle Zeilen auskommentiert, 
: dies sollte die praktischen Bedürfnisse auch abdecken. 
: [[SSH_Konfiguration#Die_Datei_.2Fetc.2Fssh.2Fsshd_config:|Konfiguration]] 

* /etc/hosts.allow & deny 
: In aktuellen Implementierungen des Ssh-Daemons ist die Auswertung der Dateien 
: /etc/hosts.allow und /etc/hosts.deny zumeist fest verdrahtet: 

tux> strings /usr/sbin/sshd | egrep 'hosts.allow|hosts.deny'
hosts_allow_table
hosts_deny_table
/etc/hosts.allow
/etc/hosts.deny

# Zugang zur Secure Shell (hosts.allow)
sshd: LOCAL 
# oder genauer:
sshd: 192...(Klient-DNS)/255.255.255.0 *.Domäne: ALLOW 
# Alles pauschal verbieten (hosts.deny)
ALL: ALL

* /etc/nologin
: Wenn sie existiert, verweigert sshd jeden Einlogvorgang außer dem von root 
: (sofern root-Eingänge in der Konfigurationsdatei erlaubt waren). 
: Der Inhalt der Datei wird dem Client übermittelt. 

=== Dateien Clientseitig ===

* /etc/ssh/ssh_known_hosts & ~/.ssh/known_hosts 
: enthalten die Public-Keys aller bekannten Rechner. 
: Die globale Datei wird vom Systemverwalter administriert, 
: die userbezogene wird automatisch angelegt und erweitert. 
: enthält die folgenden Felder: 
: Hostnamen Bits Exponent Modulus Kommentar 
: Hostnamen ist eine durch Kommas getrennte Liste von Namen 
: (* und ? dürfen benutzt werden). 
: Wird mit dem vollständigen Hostnamen des Rechners verglichen, der sich anmelden will. 
: Bits, Exponent und Modulus werden direkt den Host-Schlüsseln entnommen, 
: die in den Dateien /etc/ssh/ssh_host_*_key.pub gespeichert sind. 
: Das optionale Kommentarfeld wird nicht ausgewertet. 

* /etc/ssh/ssh.config 
: Client-Einstellungen. 
 
<hr>
=== Schlüssel - passwortfreie Anmeldung ===

Der Befehl 'ssh-keygen' erzeugt und verwaltet die Schlüssel für SSH-Verbindungen. 
Normaluser können sich damit einen Schlüssel erzeugen, der Systemverwalter kann auch den
Host-Schlüssel damit anlegen. Diese Schlüssel sind nicht zwingend für den Gebrauch von SSH erforderlich, bestimmte Server verlangen ihn aber. 
Es stehen zwei Schlüsseltypen ('RSA' und 'DSA') zur Verfügung, erforderlich ist aber nur
einer von beiden. 
Man wird bei der Erstellung nach einem Passwort gefragt, muß aber keines angeben. 
'''Es ist also möglich, über diese Schlüsselpaare eine Authentifizierung ohne Passwort zu steuern.''' 

> ssh-keygen -t rsa
Password:
...
Generating public/private rsa key pair.
... in ~/.ssh/id_dra.pub 
> ssh-keygen -t dsa
Password:
...
Generating public/private dsa key pair.
... in ~/.ssh/id_dsa.pub

Der Inhalt mindestens einer der beiden Dateien 'id_rsa.pub' und 'id_dsa.pub' müssen auf dem
Remote-Rechner in die Datei $HOME/.ssh/authorized_keys eingetragen werden. Verzeichnis als
auch die Datei dürfen nur für den User lesbar und schreibbar sein. 
Die geht manuell oder mit: 

> ssh-copy-id -i /home/tux/.ssh/id_rsa.pub 192...(Server-DNS)
password:
...

In der Serverkonfiguration kann die Passwort-Authentifikation ausgeschaltet werden: 

/etc/ssh/sshd_config: 
# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no

Und gegebenenfalls: 

/etc/ssh/sshd_config: 
- PermitRootLogin yes/no

Der Server muß neu gestartet werden: 

> /etc/init.d/ssh restart

Ein Login erfolgt dann mit: 

> ssh -l user ServerDNS

 
<hr>

=== Die Datei /etc/ssh/sshd_config: ===

* BatchMode yes/no 
: Die Abfrage nach dem Passwort oder der Passphrase wird unterbunden, 
: somit lassen sich z.B. Kommandos in Shellscripts ausführen. 
* Compression yes/no 
: Schaltet die Komprimierung der zu übertragenden Daten ein oder aus. 
* FallBackToRsh yes/no 
: Scheitert der Verbindungsaufbau zum Server (zB. weil dieser nicht aktiv ist), 
: kann eine Verbindung über rsh versucht werden. Default: 'no' 
* HostKey Dateiname 
: Spezifiziert die Datei, in der der Host-Schlüssel des Servers abgelegt ist. 
: Normalerweise ist das die Datei /etc/ssh/ssh_host_key. 
: Diese Datei darf nicht für alle Welt lesbar sein, 
: ansonsten verweigert sich sshd die Datei zu verwenden! 
* IgnoreRhosts yes/no 
: Sollen die Dateien ~/.rhosts und ~/.shosts ignoriert werden? 
* KeyRegenerationInterval Zeit 
: Die Anzahl der Sekunden, nach denen der Server-Schlüssel neu erstellt werden soll. 
: Standardmäßig sollte hier 3600 (eine Stunde) stehen. 
: Steht hier eine 0, so wird der Schlüssel niemals neu erstellt. 
* PermitRootLogin yes/no 
: Erlaubt, daß sich der Systemverwalter über ssh einloggen kann. 
* PasswordAuthentication yes/no 
: Soll eine Abfrage des Passwortes durchgeführt werden? 
: Steht der Wert auf »no«, ist ein Anmelden auf einem entfernten Rechner nur möglich, 
: wenn der eigene öffentliche Schlüssel dort bekannt ist. 
* Port n 
: Die Angabe auf welchem Port sshd laufen soll. Normalerweise ist es Port 22. 
* RhostsAuthentication yes/no 
: Ob bei der Authentifizierung die Dateien rhosts und /etc/hosts.equiv ausreichen, 
: soll auf »no« bleiben. 
* RhostsRSAAuthentication yes/no 
: Erlaubt die Benutzung von rhosts und /etc/hosts.equiv, 
: allerdings nur wenn die RSA-HOST-Authentifizierung erfolgreich war. 
: Default »yes«. 
* RSAAuthentication yes/no 
: Authentifizierung mittels RSA-Verschlüsselung. 
: Steht der Wert auf »yes«, sollte die Datei »~/.ssh/identity« 
: oder ein Authentifizierungsagent existieren. 
* StrictHostKeyChecking yes/no 
: Ein »yes« verschärft die Sicherheit, indem das Anmelden nur auf Rechnern gestattet wird, 
: die in den Datenbanken »/etc/known_hosts« bzw. »~/.ssh/known_hosts« enthalten sind. 
: Steht hier »no« werden neu besuchte Rechner automatisch der privaten Datei hinzugefügt. 
 
<hr>
=== Troubleshooting ===

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! 
: Schonmal auf den Server (mit gleicher IP) zugegriffen ? 
: (Schlüssel hat sich geändert) 

> ssh-keygen -R hostname
/home/tux/.ssh/known_hosts updated.
Original contents retained as /home/tux/.ssh/known_hosts.old

Falls es nicht geht: 
: Inhalt von ~/.ssh/known_hosts komplett löschen oder entsprechend editieren! 

Wenn weiter unten die Zeile kommt: 
'DSA host key for 141.44.198.20 has changed and you have requested strict checking.' 
: versuche es mit Änderung in: 
/etc/ssh/sshd_config 
StrictHostKeyChecking: yes/no/ask (def: ask) 

'''Immer noch Probleme?'''

Ist der ssh-Zugriff überhaupt möglich? 
: Ein beliebtes Problem ist '... key_exchange ... connection closed by foreign host'. 
: Das liegt dann meist daran, daß die Reverse-Auflösung der eigenen IP-Adresse nicht 
: mit dem Namen für den eigenen Host übereinstimmt. 
: Auf der anderen Seite in /etc/hosts.deny die ALL: PARANOID Zeile auskommentieren. 
: Oder DNS in Ordnung bringen! 

Passwort wird verlangt. 
: Meistens ein Problem der Permissions auf der eigenen und/oder der anderen Seite: 
: Das Verzeichnis .ssh/ und die die Datei .ssh/authorized_keys darf nur für den Eigentümer, 
: der auch der "angepeilte" Nutzer sein muß, schreibbar sein! 
: ssh -v ... hilft, diese Art von Problemen zu diagnostizieren.

Die SSH2 verlangt die Keys in ~/.ssh/authorized_keys2. 
: Die SSH2 auf Debian/GNU-Linux ist mögl. gepatcht und sucht die wie gehabt in: 
: ~/.ssh/authorized_keys, U.u. muß aber trotzdem auf SuSE-Systemen eben diese 2 angehängt werden. 

<hr>
:: Quellen:
::: [http://www.linux-praxis.de/lpic1/lpi102/1.113.7.html Einrichten von Secure Shell (OpenSSH) - LPI-Study Guides]
::: [http://de.linwiki.org/index.php/Linuxfibel_-_Netzwerk_Server_-_Telnet_%26_Co. Thomas Ermer / Michael Meyer: Linuxfibel - Netzwerk Server - Telnet & Co.]
::: [http://www.schlittermann.de/ssh Heiko Schlittermann: SSH ohne Passwort -- eine kurze Anleitung]
::: [http://www.lrz-muenchen.de/services/security/ssh/ssh-4.html Ernst Bötsch: Secure Shell (SSH) für Benutzer]
::: [http://www.jfranken.de/homepages/johannes/vortraege/ssh1_inhalt.de.html Johannes Franken: OpenSSH Grundlagen]

SSH Konfiguration

2007-10-23T09:14:12Z

OsunSeyi: /* Schlüssel - passwortfreie Anmeldung */

== SSH KONFIGURATION ==

=== Wie funktioniert SSH? ===

1...................
: Auf dem Server-Rechner (remote) wird ein Host-Key-Paar (RSA) generiert. 
: - ein Verschlüsselungscode (public_key) 
: - ein Entschlüsselungscode (private_key) 
: Der 'public_key' (öffentlich pubizierter Schlüssel) dient als Erkennung 
: für die Klients. 
: Zusätzlich erzeugt der laufende Server-Prozeß ein Server-Key-Paar, daß nur im 
: Memory des Remote-Rechners gehalten und periodisch erneuert wird. Es dient der 
: Verschlüsselung. 

2...................
: Der lokale SSH-Client wendet sich an den SSH-Server auf dem Remote-Rechner, 
: um eine Verbindung aufzunehmen. 
: Der Server schickt dem Client daraufhin sowohl seinen 'public_key' als auch den 
: periodisch erzeugten öffentlichen Serverschlüssel. 

3...................
: Der Klient überprüft nun den erhaltenen 'public key' mit der Liste in 'known_hosts'. 
: Normalerweise wird er sofort nach seinem Passwort gefragt. 

4...................
: Existiert aber in 'known_hosts' noch kein zugehöriger Eintrag, so wird dieser hinzu- 
: gefügt. Dies erfordert eine ausdrücklicher Bestätigung durch den Benutzer. 
: Also wird der 'public_key' nur bei der ersten Kontaktaufname übermittelt, danach ist 
: er dem Klient bekannt. 
: Ändert er sich, wird der Klient die Kontaktaufname verweigern und wieder neu nachfragen. 

5...................
: Ab dann erzeugt der Client eine Zufallszahl und verschlüsselt diese unter Zuhilfename 
: der beiden übergebenen öffentlichen Schlüssel (Hostkey und Serverkey). 
: Diese Zufallszahl dient im weiteren Verlauf als der aktuelle Sitzungsschlüssel. 
: Da sich bei jeder Änderung des bereits verschlüsselt übermittelten Serverkeys auch der 
: aktuelle Sitzungsschlüsse ändert, entsteht eine Art 'doppelte Verschlüsselung'.

6...................
: Nun erst übergibt der Client Userid und Passwort und der Server startet eine Login-Shell 
: bzw. führt das gewünschte Kommando aus. 

Bei der Authentifizierung des Clients werden der Reihe nach verschiedene Verfahren ausprobiert. 
Dabei wird der Client als berechtigt betrachtet, sobald das erste Verfahren folgender Liste 
erfolgreich war: 

1...................
: Autentifikation entsprechend den r-Kommandos; 
: Unsicher und per Default deaktiviert. 

2...................
: Wie Punkt1; zusätzliche RSA-Authentifikation. 

3...................
: RSA-Authentifikation; dazu ist auf dem Remote-Rechner ein Eintrag in 
: ~/.ssh/authorized_keys erforderlich. 

4...................
: Durch Paßwort-Abfrage. 
 
<hr>

=== Dateien Serverseitig ===

* /etc/ssh/sshd_config 
: Der SSHD wird über diese Datei konfiguriert. 
: Meist sind fast alle Zeilen auskommentiert, 
: dies sollte die praktischen Bedürfnisse auch abdecken. 
: [[SSH_Konfiguration#Die_Datei_.2Fetc.2Fssh.2Fsshd_config:|Konfiguration]] 

* /etc/hosts.allow & deny 
: In aktuellen Implementierungen des Ssh-Daemons ist die Auswertung der Dateien 
: /etc/hosts.allow und /etc/hosts.deny zumeist fest verdrahtet: 

tux> strings /usr/sbin/sshd | egrep 'hosts.allow|hosts.deny'
hosts_allow_table
hosts_deny_table
/etc/hosts.allow
/etc/hosts.deny

# Zugang zur Secure Shell (hosts.allow)
sshd: LOCAL 
# oder genauer:
sshd: 192...(Klient-DNS)/255.255.255.0 *.Domäne: ALLOW 
# Alles pauschal verbieten (hosts.deny)
ALL: ALL

* /etc/nologin
: Wenn sie existiert, verweigert sshd jeden Einlogvorgang außer dem von root 
: (sofern root-Eingänge in der Konfigurationsdatei erlaubt waren). 
: Der Inhalt der Datei wird dem Client übermittelt. 

=== Dateien Clientseitig ===

* /etc/ssh/ssh_known_hosts & ~/.ssh/known_hosts 
: enthalten die Public-Keys aller bekannten Rechner. 
: Die globale Datei wird vom Systemverwalter administriert, 
: die userbezogene wird automatisch angelegt und erweitert. 
: enthält die folgenden Felder: 
: Hostnamen Bits Exponent Modulus Kommentar 
: Hostnamen ist eine durch Kommas getrennte Liste von Namen 
: (* und ? dürfen benutzt werden). 
: Wird mit dem vollständigen Hostnamen des Rechners verglichen, der sich anmelden will. 
: Bits, Exponent und Modulus werden direkt den Host-Schlüsseln entnommen, 
: die in den Dateien /etc/ssh/ssh_host_*_key.pub gespeichert sind. 
: Das optionale Kommentarfeld wird nicht ausgewertet. 

* /etc/ssh/ssh.config 
: Client-Einstellungen. 
 
<hr>
=== Schlüssel - passwortfreie Anmeldung ===

Der Befehl 'ssh-keygen' erzeugt und verwaltet die Schlüssel für SSH-Verbindungen. 
Normaluser können sich damit einen Schlüssel erzeugen, der Systemverwalter kann auch den
Host-Schlüssel damit anlegen. Diese Schlüssel sind nicht zwingend für den Gebrauch von SSH erforderlich, bestimmte Server verlangen ihn aber. 
Es stehen zwei Schlüsseltypen ('RSA' und 'DSA') zur Verfügung, erforderlich ist aber nur
einer von beiden. 
Man wird bei der Erstellung nach einem Passwort gefragt, muß aber keines angeben. 
Es ist also möglich, über diese Schlüsselpaare eine Authentifizierung ohne Passwort zu steuern. 

> ssh-keygen -t rsa
Password:
...
Generating public/private rsa key pair.
... in ~/.ssh/id_dra.pub 
> ssh-keygen -t dsa
Password:
...
Generating public/private dsa key pair.
... in ~/.ssh/id_dsa.pub

Der Inhalt mindestens einer der beiden Dateien 'id_rsa.pub' und 'id_dsa.pub' müssen auf dem
Remote-Rechner in die Datei $HOME/.ssh/authorized_keys eingetragen werden. Verzeichnis als
auch die Datei dürfen nur für den User lesbar und schreibbar sein. 
Die geht manuell oder mit: 

> ssh-copy-id -i /home/tux/.ssh/id_rsa.pub 192...(Server-DNS)
password:
...

In der Serverkonfiguration kann die Passwort-Authentifikation ausgeschaltet werden: 

/etc/ssh/sshd_config: 
# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no

Und gegebenenfalls: 

/etc/ssh/sshd_config: 
- PermitRootLogin yes/no

Der Server muß neu gestartet werden: 

> /etc/init.d/ssh restart

Ein Login erfolgt dann mit: 

> ssh -l user ServerDNS

 
<hr>

=== Die Datei /etc/ssh/sshd_config: ===

* BatchMode yes/no 
: Die Abfrage nach dem Passwort oder der Passphrase wird unterbunden, 
: somit lassen sich z.B. Kommandos in Shellscripts ausführen. 
* Compression yes/no 
: Schaltet die Komprimierung der zu übertragenden Daten ein oder aus. 
* FallBackToRsh yes/no 
: Scheitert der Verbindungsaufbau zum Server (zB. weil dieser nicht aktiv ist), 
: kann eine Verbindung über rsh versucht werden. Default: 'no' 
* HostKey Dateiname 
: Spezifiziert die Datei, in der der Host-Schlüssel des Servers abgelegt ist. 
: Normalerweise ist das die Datei /etc/ssh/ssh_host_key. 
: Diese Datei darf nicht für alle Welt lesbar sein, 
: ansonsten verweigert sich sshd die Datei zu verwenden! 
* IgnoreRhosts yes/no 
: Sollen die Dateien ~/.rhosts und ~/.shosts ignoriert werden? 
* KeyRegenerationInterval Zeit 
: Die Anzahl der Sekunden, nach denen der Server-Schlüssel neu erstellt werden soll. 
: Standardmäßig sollte hier 3600 (eine Stunde) stehen. 
: Steht hier eine 0, so wird der Schlüssel niemals neu erstellt. 
* PermitRootLogin yes/no 
: Erlaubt, daß sich der Systemverwalter über ssh einloggen kann. 
* PasswordAuthentication yes/no 
: Soll eine Abfrage des Passwortes durchgeführt werden? 
: Steht der Wert auf »no«, ist ein Anmelden auf einem entfernten Rechner nur möglich, 
: wenn der eigene öffentliche Schlüssel dort bekannt ist. 
* Port n 
: Die Angabe auf welchem Port sshd laufen soll. Normalerweise ist es Port 22. 
* RhostsAuthentication yes/no 
: Ob bei der Authentifizierung die Dateien rhosts und /etc/hosts.equiv ausreichen, 
: soll auf »no« bleiben. 
* RhostsRSAAuthentication yes/no 
: Erlaubt die Benutzung von rhosts und /etc/hosts.equiv, 
: allerdings nur wenn die RSA-HOST-Authentifizierung erfolgreich war. 
: Default »yes«. 
* RSAAuthentication yes/no 
: Authentifizierung mittels RSA-Verschlüsselung. 
: Steht der Wert auf »yes«, sollte die Datei »~/.ssh/identity« 
: oder ein Authentifizierungsagent existieren. 
* StrictHostKeyChecking yes/no 
: Ein »yes« verschärft die Sicherheit, indem das Anmelden nur auf Rechnern gestattet wird, 
: die in den Datenbanken »/etc/known_hosts« bzw. »~/.ssh/known_hosts« enthalten sind. 
: Steht hier »no« werden neu besuchte Rechner automatisch der privaten Datei hinzugefügt. 
 
<hr>
=== Troubleshooting ===

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! 
: Schonmal auf den Server (mit gleicher IP) zugegriffen ? 
: (Schlüssel hat sich geändert) 

> ssh-keygen -R hostname
/home/tux/.ssh/known_hosts updated.
Original contents retained as /home/tux/.ssh/known_hosts.old

Falls es nicht geht: 
: Inhalt von ~/.ssh/known_hosts komplett löschen oder entsprechend editieren! 

Wenn weiter unten die Zeile kommt: 
'DSA host key for 141.44.198.20 has changed and you have requested strict checking.' 
: versuche es mit Änderung in: 
/etc/ssh/sshd_config 
StrictHostKeyChecking: yes/no/ask (def: ask) 

'''Immer noch Probleme?'''

Ist der ssh-Zugriff überhaupt möglich? 
: Ein beliebtes Problem ist '... key_exchange ... connection closed by foreign host'. 
: Das liegt dann meist daran, daß die Reverse-Auflösung der eigenen IP-Adresse nicht 
: mit dem Namen für den eigenen Host übereinstimmt. 
: Auf der anderen Seite in /etc/hosts.deny die ALL: PARANOID Zeile auskommentieren. 
: Oder DNS in Ordnung bringen! 

Passwort wird verlangt. 
: Meistens ein Problem der Permissions auf der eigenen und/oder der anderen Seite: 
: Das Verzeichnis .ssh/ und die die Datei .ssh/authorized_keys darf nur für den Eigentümer, 
: der auch der "angepeilte" Nutzer sein muß, schreibbar sein! 
: ssh -v ... hilft, diese Art von Problemen zu diagnostizieren.

Die SSH2 verlangt die Keys in ~/.ssh/authorized_keys2. 
: Die SSH2 auf Debian/GNU-Linux ist mögl. gepatcht und sucht die wie gehabt in: 
: ~/.ssh/authorized_keys, U.u. muß aber trotzdem auf SuSE-Systemen eben diese 2 angehängt werden. 

<hr>
:: Quellen:
::: [http://www.linux-praxis.de/lpic1/lpi102/1.113.7.html Einrichten von Secure Shell (OpenSSH) - LPI-Study Guides]
::: [http://de.linwiki.org/index.php/Linuxfibel_-_Netzwerk_Server_-_Telnet_%26_Co. Thomas Ermer / Michael Meyer: Linuxfibel - Netzwerk Server - Telnet & Co.]
::: [http://www.schlittermann.de/ssh Heiko Schlittermann: SSH ohne Passwort -- eine kurze Anleitung]
::: [http://www.lrz-muenchen.de/services/security/ssh/ssh-4.html Ernst Bötsch: Secure Shell (SSH) für Benutzer]
::: [http://www.jfranken.de/homepages/johannes/vortraege/ssh1_inhalt.de.html Johannes Franken: OpenSSH Grundlagen]

SSH Konfiguration

2007-10-23T09:12:30Z

OsunSeyi: /* Wie funktioniert SSH? */

== SSH KONFIGURATION ==

=== Wie funktioniert SSH? ===

1...................
: Auf dem Server-Rechner (remote) wird ein Host-Key-Paar (RSA) generiert. 
: - ein Verschlüsselungscode (public_key) 
: - ein Entschlüsselungscode (private_key) 
: Der 'public_key' (öffentlich pubizierter Schlüssel) dient als Erkennung 
: für die Klients. 
: Zusätzlich erzeugt der laufende Server-Prozeß ein Server-Key-Paar, daß nur im 
: Memory des Remote-Rechners gehalten und periodisch erneuert wird. Es dient der 
: Verschlüsselung. 

2...................
: Der lokale SSH-Client wendet sich an den SSH-Server auf dem Remote-Rechner, 
: um eine Verbindung aufzunehmen. 
: Der Server schickt dem Client daraufhin sowohl seinen 'public_key' als auch den 
: periodisch erzeugten öffentlichen Serverschlüssel. 

3...................
: Der Klient überprüft nun den erhaltenen 'public key' mit der Liste in 'known_hosts'. 
: Normalerweise wird er sofort nach seinem Passwort gefragt. 

4...................
: Existiert aber in 'known_hosts' noch kein zugehöriger Eintrag, so wird dieser hinzu- 
: gefügt. Dies erfordert eine ausdrücklicher Bestätigung durch den Benutzer. 
: Also wird der 'public_key' nur bei der ersten Kontaktaufname übermittelt, danach ist 
: er dem Klient bekannt. 
: Ändert er sich, wird der Klient die Kontaktaufname verweigern und wieder neu nachfragen. 

5...................
: Ab dann erzeugt der Client eine Zufallszahl und verschlüsselt diese unter Zuhilfename 
: der beiden übergebenen öffentlichen Schlüssel (Hostkey und Serverkey). 
: Diese Zufallszahl dient im weiteren Verlauf als der aktuelle Sitzungsschlüssel. 
: Da sich bei jeder Änderung des bereits verschlüsselt übermittelten Serverkeys auch der 
: aktuelle Sitzungsschlüsse ändert, entsteht eine Art 'doppelte Verschlüsselung'.

6...................
: Nun erst übergibt der Client Userid und Passwort und der Server startet eine Login-Shell 
: bzw. führt das gewünschte Kommando aus. 

Bei der Authentifizierung des Clients werden der Reihe nach verschiedene Verfahren ausprobiert. 
Dabei wird der Client als berechtigt betrachtet, sobald das erste Verfahren folgender Liste 
erfolgreich war: 

1...................
: Autentifikation entsprechend den r-Kommandos; 
: Unsicher und per Default deaktiviert. 

2...................
: Wie Punkt1; zusätzliche RSA-Authentifikation. 

3...................
: RSA-Authentifikation; dazu ist auf dem Remote-Rechner ein Eintrag in 
: ~/.ssh/authorized_keys erforderlich. 

4...................
: Durch Paßwort-Abfrage. 
 
<hr>

=== Dateien Serverseitig ===

* /etc/ssh/sshd_config 
: Der SSHD wird über diese Datei konfiguriert. 
: Meist sind fast alle Zeilen auskommentiert, 
: dies sollte die praktischen Bedürfnisse auch abdecken. 
: [[SSH_Konfiguration#Die_Datei_.2Fetc.2Fssh.2Fsshd_config:|Konfiguration]] 

* /etc/hosts.allow & deny 
: In aktuellen Implementierungen des Ssh-Daemons ist die Auswertung der Dateien 
: /etc/hosts.allow und /etc/hosts.deny zumeist fest verdrahtet: 

tux> strings /usr/sbin/sshd | egrep 'hosts.allow|hosts.deny'
hosts_allow_table
hosts_deny_table
/etc/hosts.allow
/etc/hosts.deny

# Zugang zur Secure Shell (hosts.allow)
sshd: LOCAL 
# oder genauer:
sshd: 192...(Klient-DNS)/255.255.255.0 *.Domäne: ALLOW 
# Alles pauschal verbieten (hosts.deny)
ALL: ALL

* /etc/nologin
: Wenn sie existiert, verweigert sshd jeden Einlogvorgang außer dem von root 
: (sofern root-Eingänge in der Konfigurationsdatei erlaubt waren). 
: Der Inhalt der Datei wird dem Client übermittelt. 

=== Dateien Clientseitig ===

* /etc/ssh/ssh_known_hosts & ~/.ssh/known_hosts 
: enthalten die Public-Keys aller bekannten Rechner. 
: Die globale Datei wird vom Systemverwalter administriert, 
: die userbezogene wird automatisch angelegt und erweitert. 
: enthält die folgenden Felder: 
: Hostnamen Bits Exponent Modulus Kommentar 
: Hostnamen ist eine durch Kommas getrennte Liste von Namen 
: (* und ? dürfen benutzt werden). 
: Wird mit dem vollständigen Hostnamen des Rechners verglichen, der sich anmelden will. 
: Bits, Exponent und Modulus werden direkt den Host-Schlüsseln entnommen, 
: die in den Dateien /etc/ssh/ssh_host_*_key.pub gespeichert sind. 
: Das optionale Kommentarfeld wird nicht ausgewertet. 

* /etc/ssh/ssh.config 
: Client-Einstellungen. 
 
<hr>
=== Schlüssel - passwortfreie Anmeldung ===

Der Befehl 'ssh-keygen' erzeugt und verwaltet die Schlüssel für SSH-Verbindungen. 
Normaluser können sich damit einen Schlüssel erzeugen, der Systemverwalter kann auch den
Host-Schlüssel damit anlegen. 
Diese Schlüssel sind nicht zwingend für den Gebrauch von SSH erforderlich, bestimmte Server
verlangen ihn aber. 
Es stehen zwei Schlüsseltypen ('RSA' und 'DSA') zur Verfügung, erforderlich ist aber nur
einer von beiden. 
Man wird bei der Erstellung nach einem Passwort gefragt, muß aber keines angeben. 
Es ist also möglich, über diese Schlüsselpaare eine Authentifizierung ohne Passwort zu steuern. 

> ssh-keygen -t rsa
Password:
...
Generating public/private rsa key pair.
... in ~/.ssh/id_dra.pub 
> ssh-keygen -t dsa
Password:
...
Generating public/private dsa key pair.
... in ~/.ssh/id_dsa.pub

Der Inhalt mindestens einer der beiden Dateien 'id_rsa.pub' und 'id_dsa.pub' müssen auf dem
Remote-Rechner in die Datei $HOME/.ssh/authorized_keys eingetragen werden. Verzeichnis als
auch die Datei dürfen nur für den User lesbar und schreibbar sein. 
Die geht manuell oder mit: 

> ssh-copy-id -i /home/tux/.ssh/id_rsa.pub 192...(Server-DNS)
password:
...

In der Serverkonfiguration kann die Passwort-Authentifikation ausgeschaltet werden: 

/etc/ssh/sshd_config: 
# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no

Und gegebenenfalls: 

/etc/ssh/sshd_config: 
- PermitRootLogin yes/no

Der Server muß neu gestartet werden: 

> /etc/init.d/ssh restart

Ein Login erfolgt dann mit: 

> ssh -l user ServerDNS

 
<hr>

=== Die Datei /etc/ssh/sshd_config: ===

* BatchMode yes/no 
: Die Abfrage nach dem Passwort oder der Passphrase wird unterbunden, 
: somit lassen sich z.B. Kommandos in Shellscripts ausführen. 
* Compression yes/no 
: Schaltet die Komprimierung der zu übertragenden Daten ein oder aus. 
* FallBackToRsh yes/no 
: Scheitert der Verbindungsaufbau zum Server (zB. weil dieser nicht aktiv ist), 
: kann eine Verbindung über rsh versucht werden. Default: 'no' 
* HostKey Dateiname 
: Spezifiziert die Datei, in der der Host-Schlüssel des Servers abgelegt ist. 
: Normalerweise ist das die Datei /etc/ssh/ssh_host_key. 
: Diese Datei darf nicht für alle Welt lesbar sein, 
: ansonsten verweigert sich sshd die Datei zu verwenden! 
* IgnoreRhosts yes/no 
: Sollen die Dateien ~/.rhosts und ~/.shosts ignoriert werden? 
* KeyRegenerationInterval Zeit 
: Die Anzahl der Sekunden, nach denen der Server-Schlüssel neu erstellt werden soll. 
: Standardmäßig sollte hier 3600 (eine Stunde) stehen. 
: Steht hier eine 0, so wird der Schlüssel niemals neu erstellt. 
* PermitRootLogin yes/no 
: Erlaubt, daß sich der Systemverwalter über ssh einloggen kann. 
* PasswordAuthentication yes/no 
: Soll eine Abfrage des Passwortes durchgeführt werden? 
: Steht der Wert auf »no«, ist ein Anmelden auf einem entfernten Rechner nur möglich, 
: wenn der eigene öffentliche Schlüssel dort bekannt ist. 
* Port n 
: Die Angabe auf welchem Port sshd laufen soll. Normalerweise ist es Port 22. 
* RhostsAuthentication yes/no 
: Ob bei der Authentifizierung die Dateien rhosts und /etc/hosts.equiv ausreichen, 
: soll auf »no« bleiben. 
* RhostsRSAAuthentication yes/no 
: Erlaubt die Benutzung von rhosts und /etc/hosts.equiv, 
: allerdings nur wenn die RSA-HOST-Authentifizierung erfolgreich war. 
: Default »yes«. 
* RSAAuthentication yes/no 
: Authentifizierung mittels RSA-Verschlüsselung. 
: Steht der Wert auf »yes«, sollte die Datei »~/.ssh/identity« 
: oder ein Authentifizierungsagent existieren. 
* StrictHostKeyChecking yes/no 
: Ein »yes« verschärft die Sicherheit, indem das Anmelden nur auf Rechnern gestattet wird, 
: die in den Datenbanken »/etc/known_hosts« bzw. »~/.ssh/known_hosts« enthalten sind. 
: Steht hier »no« werden neu besuchte Rechner automatisch der privaten Datei hinzugefügt. 
 
<hr>
=== Troubleshooting ===

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! 
: Schonmal auf den Server (mit gleicher IP) zugegriffen ? 
: (Schlüssel hat sich geändert) 

> ssh-keygen -R hostname
/home/tux/.ssh/known_hosts updated.
Original contents retained as /home/tux/.ssh/known_hosts.old

Falls es nicht geht: 
: Inhalt von ~/.ssh/known_hosts komplett löschen oder entsprechend editieren! 

Wenn weiter unten die Zeile kommt: 
'DSA host key for 141.44.198.20 has changed and you have requested strict checking.' 
: versuche es mit Änderung in: 
/etc/ssh/sshd_config 
StrictHostKeyChecking: yes/no/ask (def: ask) 

'''Immer noch Probleme?'''

Ist der ssh-Zugriff überhaupt möglich? 
: Ein beliebtes Problem ist '... key_exchange ... connection closed by foreign host'. 
: Das liegt dann meist daran, daß die Reverse-Auflösung der eigenen IP-Adresse nicht 
: mit dem Namen für den eigenen Host übereinstimmt. 
: Auf der anderen Seite in /etc/hosts.deny die ALL: PARANOID Zeile auskommentieren. 
: Oder DNS in Ordnung bringen! 

Passwort wird verlangt. 
: Meistens ein Problem der Permissions auf der eigenen und/oder der anderen Seite: 
: Das Verzeichnis .ssh/ und die die Datei .ssh/authorized_keys darf nur für den Eigentümer, 
: der auch der "angepeilte" Nutzer sein muß, schreibbar sein! 
: ssh -v ... hilft, diese Art von Problemen zu diagnostizieren.

Die SSH2 verlangt die Keys in ~/.ssh/authorized_keys2. 
: Die SSH2 auf Debian/GNU-Linux ist mögl. gepatcht und sucht die wie gehabt in: 
: ~/.ssh/authorized_keys, U.u. muß aber trotzdem auf SuSE-Systemen eben diese 2 angehängt werden. 

<hr>
:: Quellen:
::: [http://www.linux-praxis.de/lpic1/lpi102/1.113.7.html Einrichten von Secure Shell (OpenSSH) - LPI-Study Guides]
::: [http://de.linwiki.org/index.php/Linuxfibel_-_Netzwerk_Server_-_Telnet_%26_Co. Thomas Ermer / Michael Meyer: Linuxfibel - Netzwerk Server - Telnet & Co.]
::: [http://www.schlittermann.de/ssh Heiko Schlittermann: SSH ohne Passwort -- eine kurze Anleitung]
::: [http://www.lrz-muenchen.de/services/security/ssh/ssh-4.html Ernst Bötsch: Secure Shell (SSH) für Benutzer]
::: [http://www.jfranken.de/homepages/johannes/vortraege/ssh1_inhalt.de.html Johannes Franken: OpenSSH Grundlagen]

SSH Konfiguration

2007-10-22T13:29:13Z

OsunSeyi: /* Immer noch Probleme? */

== SSH KONFIGURATION ==

=== Wie funktioniert SSH? ===

1...................
: Auf dem Server-Rechner (remote) wird ein Host-Key-Paar (RSA) generiert. 
: - ein Verschlüsselungscode (public_key) 
: - ein Entschlüsselungscode (private_key) 
: Der 'public_key' (öffentlich pubizierter Schlüssel) dient als Erkennung 
: für die Klients. 
: Zusätzlich erzeugt der laufende Server-Prozeß ein Server-Key-Paar, daß nur im 
: Memory des Remote-Rechners gehalten und periodisch erneuert wird. Es dient der 
: Verschlüsselung. 

2...................
: Der lokale SSH-Client wendet sich an den SSH-Server auf dem Remote-Rechner, 
: um eine Verbindung aufzunehmen. 
: Der Server schickt dem Client daraufhin sowohl seinen 'public_key' als auch den 
: periodisch erzeugten öffentlichen Serverschlüssel. 

3...................
: Der Klient überprüft nun den erhaltenen 'public key' mit der Liste in 'known_hosts'. 
: Normalerweise wird er sofort nach seinem Passwort gefragt. 

4...................
: Existiert aber in 'known_hosts' noch kein zugehöriger Eintrag, so wird dieser hinzu- 
: gefügt. Dies erfordert eine ausdrücklicher Bestätigung durch den Benutzer. 
: Also wird der 'public_key' nur bei der ersten Kontaktaufname übermittelt, danach ist 
: er dem Klient bekannt. 
: Ändert er sich, wird der Klient die Kontaktaufname verweigern und wieder neu nachfragen. 

5...................
: Ab dann erzeugt der Client eine Zufallszahl und verschlüsselt diese unter Zuhilfename 
: der beiden übergebenen öffentlichen Schlüssel (Hostkey und Serverkey). 
: Diese Zufallszahl dient im weiteren Verlauf als der aktuelle Sitzungsschlüssel. 

6...................
: Nun erst übergibt der Client Userid und Passwort und der Server startet eine Login-Shell 
: bzw. führt das gewünschte Kommando aus. 

Bei der Authentifizierung des Clients werden der Reihe nach verschiedene Verfahren ausprobiert. 
Dabei wird der Client als berechtigt betrachtet, sobald das erste Verfahren folgender Liste 
erfolgreich war: 

1...................
: Autentifikation entsprechend den r-Kommandos; 
: Unsicher und per Default deaktiviert. 

2...................
: Wie Punkt1; zusätzliche RSA-Authentifikation. 

3...................
: RSA-Authentifikation; dazu ist auf dem Remote-Rechner ein Eintrag in 
: ~/.ssh/authorized_keys erforderlich. 

4...................
: Durch Paßwort-Abfrage. 
 
<hr>

=== Dateien Serverseitig ===

* /etc/ssh/sshd_config 
: Der SSHD wird über diese Datei konfiguriert. 
: Meist sind fast alle Zeilen auskommentiert, 
: dies sollte die praktischen Bedürfnisse auch abdecken. 
: [[SSH_Konfiguration#Die_Datei_.2Fetc.2Fssh.2Fsshd_config:|Konfiguration]] 

* /etc/hosts.allow & deny 
: In aktuellen Implementierungen des Ssh-Daemons ist die Auswertung der Dateien 
: /etc/hosts.allow und /etc/hosts.deny zumeist fest verdrahtet: 

tux> strings /usr/sbin/sshd | egrep 'hosts.allow|hosts.deny'
hosts_allow_table
hosts_deny_table
/etc/hosts.allow
/etc/hosts.deny

# Zugang zur Secure Shell (hosts.allow)
sshd: LOCAL 
# oder genauer:
sshd: 192...(Klient-DNS)/255.255.255.0 *.Domäne: ALLOW 
# Alles pauschal verbieten (hosts.deny)
ALL: ALL

* /etc/nologin
: Wenn sie existiert, verweigert sshd jeden Einlogvorgang außer dem von root 
: (sofern root-Eingänge in der Konfigurationsdatei erlaubt waren). 
: Der Inhalt der Datei wird dem Client übermittelt. 

=== Dateien Clientseitig ===

* /etc/ssh/ssh_known_hosts & ~/.ssh/known_hosts 
: enthalten die Public-Keys aller bekannten Rechner. 
: Die globale Datei wird vom Systemverwalter administriert, 
: die userbezogene wird automatisch angelegt und erweitert. 
: enthält die folgenden Felder: 
: Hostnamen Bits Exponent Modulus Kommentar 
: Hostnamen ist eine durch Kommas getrennte Liste von Namen 
: (* und ? dürfen benutzt werden). 
: Wird mit dem vollständigen Hostnamen des Rechners verglichen, der sich anmelden will. 
: Bits, Exponent und Modulus werden direkt den Host-Schlüsseln entnommen, 
: die in den Dateien /etc/ssh/ssh_host_*_key.pub gespeichert sind. 
: Das optionale Kommentarfeld wird nicht ausgewertet. 

* /etc/ssh/ssh.config 
: Client-Einstellungen. 
 
<hr>
=== Schlüssel - passwortfreie Anmeldung ===

Der Befehl 'ssh-keygen' erzeugt und verwaltet die Schlüssel für SSH-Verbindungen. 
Normaluser können sich damit einen Schlüssel erzeugen, der Systemverwalter kann auch den
Host-Schlüssel damit anlegen. 
Diese Schlüssel sind nicht zwingend für den Gebrauch von SSH erforderlich, bestimmte Server
verlangen ihn aber. 
Es stehen zwei Schlüsseltypen ('RSA' und 'DSA') zur Verfügung, erforderlich ist aber nur
einer von beiden. 
Man wird bei der Erstellung nach einem Passwort gefragt, muß aber keines angeben. 
Es ist also möglich, über diese Schlüsselpaare eine Authentifizierung ohne Passwort zu steuern. 

> ssh-keygen -t rsa
Password:
...
Generating public/private rsa key pair.
... in ~/.ssh/id_dra.pub 
> ssh-keygen -t dsa
Password:
...
Generating public/private dsa key pair.
... in ~/.ssh/id_dsa.pub

Der Inhalt mindestens einer der beiden Dateien 'id_rsa.pub' und 'id_dsa.pub' müssen auf dem
Remote-Rechner in die Datei $HOME/.ssh/authorized_keys eingetragen werden. Verzeichnis als
auch die Datei dürfen nur für den User lesbar und schreibbar sein. 
Die geht manuell oder mit: 

> ssh-copy-id -i /home/tux/.ssh/id_rsa.pub 192...(Server-DNS)
password:
...

In der Serverkonfiguration kann die Passwort-Authentifikation ausgeschaltet werden: 

/etc/ssh/sshd_config: 
# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no

Und gegebenenfalls: 

/etc/ssh/sshd_config: 
- PermitRootLogin yes/no

Der Server muß neu gestartet werden: 

> /etc/init.d/ssh restart

Ein Login erfolgt dann mit: 

> ssh -l user ServerDNS

 
<hr>

=== Die Datei /etc/ssh/sshd_config: ===

* BatchMode yes/no 
: Die Abfrage nach dem Passwort oder der Passphrase wird unterbunden, 
: somit lassen sich z.B. Kommandos in Shellscripts ausführen. 
* Compression yes/no 
: Schaltet die Komprimierung der zu übertragenden Daten ein oder aus. 
* FallBackToRsh yes/no 
: Scheitert der Verbindungsaufbau zum Server (zB. weil dieser nicht aktiv ist), 
: kann eine Verbindung über rsh versucht werden. Default: 'no' 
* HostKey Dateiname 
: Spezifiziert die Datei, in der der Host-Schlüssel des Servers abgelegt ist. 
: Normalerweise ist das die Datei /etc/ssh/ssh_host_key. 
: Diese Datei darf nicht für alle Welt lesbar sein, 
: ansonsten verweigert sich sshd die Datei zu verwenden! 
* IgnoreRhosts yes/no 
: Sollen die Dateien ~/.rhosts und ~/.shosts ignoriert werden? 
* KeyRegenerationInterval Zeit 
: Die Anzahl der Sekunden, nach denen der Server-Schlüssel neu erstellt werden soll. 
: Standardmäßig sollte hier 3600 (eine Stunde) stehen. 
: Steht hier eine 0, so wird der Schlüssel niemals neu erstellt. 
* PermitRootLogin yes/no 
: Erlaubt, daß sich der Systemverwalter über ssh einloggen kann. 
* PasswordAuthentication yes/no 
: Soll eine Abfrage des Passwortes durchgeführt werden? 
: Steht der Wert auf »no«, ist ein Anmelden auf einem entfernten Rechner nur möglich, 
: wenn der eigene öffentliche Schlüssel dort bekannt ist. 
* Port n 
: Die Angabe auf welchem Port sshd laufen soll. Normalerweise ist es Port 22. 
* RhostsAuthentication yes/no 
: Ob bei der Authentifizierung die Dateien rhosts und /etc/hosts.equiv ausreichen, 
: soll auf »no« bleiben. 
* RhostsRSAAuthentication yes/no 
: Erlaubt die Benutzung von rhosts und /etc/hosts.equiv, 
: allerdings nur wenn die RSA-HOST-Authentifizierung erfolgreich war. 
: Default »yes«. 
* RSAAuthentication yes/no 
: Authentifizierung mittels RSA-Verschlüsselung. 
: Steht der Wert auf »yes«, sollte die Datei »~/.ssh/identity« 
: oder ein Authentifizierungsagent existieren. 
* StrictHostKeyChecking yes/no 
: Ein »yes« verschärft die Sicherheit, indem das Anmelden nur auf Rechnern gestattet wird, 
: die in den Datenbanken »/etc/known_hosts« bzw. »~/.ssh/known_hosts« enthalten sind. 
: Steht hier »no« werden neu besuchte Rechner automatisch der privaten Datei hinzugefügt. 
 
<hr>
=== Troubleshooting ===

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! 
: Schonmal auf den Server (mit gleicher IP) zugegriffen ? 
: (Schlüssel hat sich geändert) 

> ssh-keygen -R hostname
/home/tux/.ssh/known_hosts updated.
Original contents retained as /home/tux/.ssh/known_hosts.old

Falls es nicht geht: 
: Inhalt von ~/.ssh/known_hosts komplett löschen oder entsprechend editieren! 

Wenn weiter unten die Zeile kommt: 
'DSA host key for 141.44.198.20 has changed and you have requested strict checking.' 
: versuche es mit Änderung in: 
/etc/ssh/sshd_config 
StrictHostKeyChecking: yes/no/ask (def: ask) 

'''Immer noch Probleme?'''

Ist der ssh-Zugriff überhaupt möglich? 
: Ein beliebtes Problem ist '... key_exchange ... connection closed by foreign host'. 
: Das liegt dann meist daran, daß die Reverse-Auflösung der eigenen IP-Adresse nicht 
: mit dem Namen für den eigenen Host übereinstimmt. 
: Auf der anderen Seite in /etc/hosts.deny die ALL: PARANOID Zeile auskommentieren. 
: Oder DNS in Ordnung bringen! 

Passwort wird verlangt. 
: Meistens ein Problem der Permissions auf der eigenen und/oder der anderen Seite: 
: Das Verzeichnis .ssh/ und die die Datei .ssh/authorized_keys darf nur für den Eigentümer, 
: der auch der "angepeilte" Nutzer sein muß, schreibbar sein! 
: ssh -v ... hilft, diese Art von Problemen zu diagnostizieren.

Die SSH2 verlangt die Keys in ~/.ssh/authorized_keys2. 
: Die SSH2 auf Debian/GNU-Linux ist mögl. gepatcht und sucht die wie gehabt in: 
: ~/.ssh/authorized_keys, U.u. muß aber trotzdem auf SuSE-Systemen eben diese 2 angehängt werden. 

<hr>
:: Quellen:
::: [http://www.linux-praxis.de/lpic1/lpi102/1.113.7.html Einrichten von Secure Shell (OpenSSH) - LPI-Study Guides]
::: [http://de.linwiki.org/index.php/Linuxfibel_-_Netzwerk_Server_-_Telnet_%26_Co. Thomas Ermer / Michael Meyer: Linuxfibel - Netzwerk Server - Telnet & Co.]
::: [http://www.schlittermann.de/ssh Heiko Schlittermann: SSH ohne Passwort -- eine kurze Anleitung]
::: [http://www.lrz-muenchen.de/services/security/ssh/ssh-4.html Ernst Bötsch: Secure Shell (SSH) für Benutzer]
::: [http://www.jfranken.de/homepages/johannes/vortraege/ssh1_inhalt.de.html Johannes Franken: OpenSSH Grundlagen]

SSH Konfiguration

2007-10-22T13:26:43Z

OsunSeyi: /* Schlüssel - passwortfreie Anmeldung */

== SSH KONFIGURATION ==

=== Wie funktioniert SSH? ===

1...................
: Auf dem Server-Rechner (remote) wird ein Host-Key-Paar (RSA) generiert. 
: - ein Verschlüsselungscode (public_key) 
: - ein Entschlüsselungscode (private_key) 
: Der 'public_key' (öffentlich pubizierter Schlüssel) dient als Erkennung 
: für die Klients. 
: Zusätzlich erzeugt der laufende Server-Prozeß ein Server-Key-Paar, daß nur im 
: Memory des Remote-Rechners gehalten und periodisch erneuert wird. Es dient der 
: Verschlüsselung. 

2...................
: Der lokale SSH-Client wendet sich an den SSH-Server auf dem Remote-Rechner, 
: um eine Verbindung aufzunehmen. 
: Der Server schickt dem Client daraufhin sowohl seinen 'public_key' als auch den 
: periodisch erzeugten öffentlichen Serverschlüssel. 

3...................
: Der Klient überprüft nun den erhaltenen 'public key' mit der Liste in 'known_hosts'. 
: Normalerweise wird er sofort nach seinem Passwort gefragt. 

4...................
: Existiert aber in 'known_hosts' noch kein zugehöriger Eintrag, so wird dieser hinzu- 
: gefügt. Dies erfordert eine ausdrücklicher Bestätigung durch den Benutzer. 
: Also wird der 'public_key' nur bei der ersten Kontaktaufname übermittelt, danach ist 
: er dem Klient bekannt. 
: Ändert er sich, wird der Klient die Kontaktaufname verweigern und wieder neu nachfragen. 

5...................
: Ab dann erzeugt der Client eine Zufallszahl und verschlüsselt diese unter Zuhilfename 
: der beiden übergebenen öffentlichen Schlüssel (Hostkey und Serverkey). 
: Diese Zufallszahl dient im weiteren Verlauf als der aktuelle Sitzungsschlüssel. 

6...................
: Nun erst übergibt der Client Userid und Passwort und der Server startet eine Login-Shell 
: bzw. führt das gewünschte Kommando aus. 

Bei der Authentifizierung des Clients werden der Reihe nach verschiedene Verfahren ausprobiert. 
Dabei wird der Client als berechtigt betrachtet, sobald das erste Verfahren folgender Liste 
erfolgreich war: 

1...................
: Autentifikation entsprechend den r-Kommandos; 
: Unsicher und per Default deaktiviert. 

2...................
: Wie Punkt1; zusätzliche RSA-Authentifikation. 

3...................
: RSA-Authentifikation; dazu ist auf dem Remote-Rechner ein Eintrag in 
: ~/.ssh/authorized_keys erforderlich. 

4...................
: Durch Paßwort-Abfrage. 
 
<hr>

=== Dateien Serverseitig ===

* /etc/ssh/sshd_config 
: Der SSHD wird über diese Datei konfiguriert. 
: Meist sind fast alle Zeilen auskommentiert, 
: dies sollte die praktischen Bedürfnisse auch abdecken. 
: [[SSH_Konfiguration#Die_Datei_.2Fetc.2Fssh.2Fsshd_config:|Konfiguration]] 

* /etc/hosts.allow & deny 
: In aktuellen Implementierungen des Ssh-Daemons ist die Auswertung der Dateien 
: /etc/hosts.allow und /etc/hosts.deny zumeist fest verdrahtet: 

tux> strings /usr/sbin/sshd | egrep 'hosts.allow|hosts.deny'
hosts_allow_table
hosts_deny_table
/etc/hosts.allow
/etc/hosts.deny

# Zugang zur Secure Shell (hosts.allow)
sshd: LOCAL 
# oder genauer:
sshd: 192...(Klient-DNS)/255.255.255.0 *.Domäne: ALLOW 
# Alles pauschal verbieten (hosts.deny)
ALL: ALL

* /etc/nologin
: Wenn sie existiert, verweigert sshd jeden Einlogvorgang außer dem von root 
: (sofern root-Eingänge in der Konfigurationsdatei erlaubt waren). 
: Der Inhalt der Datei wird dem Client übermittelt. 

=== Dateien Clientseitig ===

* /etc/ssh/ssh_known_hosts & ~/.ssh/known_hosts 
: enthalten die Public-Keys aller bekannten Rechner. 
: Die globale Datei wird vom Systemverwalter administriert, 
: die userbezogene wird automatisch angelegt und erweitert. 
: enthält die folgenden Felder: 
: Hostnamen Bits Exponent Modulus Kommentar 
: Hostnamen ist eine durch Kommas getrennte Liste von Namen 
: (* und ? dürfen benutzt werden). 
: Wird mit dem vollständigen Hostnamen des Rechners verglichen, der sich anmelden will. 
: Bits, Exponent und Modulus werden direkt den Host-Schlüsseln entnommen, 
: die in den Dateien /etc/ssh/ssh_host_*_key.pub gespeichert sind. 
: Das optionale Kommentarfeld wird nicht ausgewertet. 

* /etc/ssh/ssh.config 
: Client-Einstellungen. 
 
<hr>
=== Schlüssel - passwortfreie Anmeldung ===

Der Befehl 'ssh-keygen' erzeugt und verwaltet die Schlüssel für SSH-Verbindungen. 
Normaluser können sich damit einen Schlüssel erzeugen, der Systemverwalter kann auch den
Host-Schlüssel damit anlegen. 
Diese Schlüssel sind nicht zwingend für den Gebrauch von SSH erforderlich, bestimmte Server
verlangen ihn aber. 
Es stehen zwei Schlüsseltypen ('RSA' und 'DSA') zur Verfügung, erforderlich ist aber nur
einer von beiden. 
Man wird bei der Erstellung nach einem Passwort gefragt, muß aber keines angeben. 
Es ist also möglich, über diese Schlüsselpaare eine Authentifizierung ohne Passwort zu steuern. 

> ssh-keygen -t rsa
Password:
...
Generating public/private rsa key pair.
... in ~/.ssh/id_dra.pub 
> ssh-keygen -t dsa
Password:
...
Generating public/private dsa key pair.
... in ~/.ssh/id_dsa.pub

Der Inhalt mindestens einer der beiden Dateien 'id_rsa.pub' und 'id_dsa.pub' müssen auf dem
Remote-Rechner in die Datei $HOME/.ssh/authorized_keys eingetragen werden. Verzeichnis als
auch die Datei dürfen nur für den User lesbar und schreibbar sein. 
Die geht manuell oder mit: 

> ssh-copy-id -i /home/tux/.ssh/id_rsa.pub 192...(Server-DNS)
password:
...

In der Serverkonfiguration kann die Passwort-Authentifikation ausgeschaltet werden: 

/etc/ssh/sshd_config: 
# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no

Und gegebenenfalls: 

/etc/ssh/sshd_config: 
- PermitRootLogin yes/no

Der Server muß neu gestartet werden: 

> /etc/init.d/ssh restart

Ein Login erfolgt dann mit: 

> ssh -l user ServerDNS

 
<hr>

=== Die Datei /etc/ssh/sshd_config: ===

* BatchMode yes/no 
: Die Abfrage nach dem Passwort oder der Passphrase wird unterbunden, 
: somit lassen sich z.B. Kommandos in Shellscripts ausführen. 
* Compression yes/no 
: Schaltet die Komprimierung der zu übertragenden Daten ein oder aus. 
* FallBackToRsh yes/no 
: Scheitert der Verbindungsaufbau zum Server (zB. weil dieser nicht aktiv ist), 
: kann eine Verbindung über rsh versucht werden. Default: 'no' 
* HostKey Dateiname 
: Spezifiziert die Datei, in der der Host-Schlüssel des Servers abgelegt ist. 
: Normalerweise ist das die Datei /etc/ssh/ssh_host_key. 
: Diese Datei darf nicht für alle Welt lesbar sein, 
: ansonsten verweigert sich sshd die Datei zu verwenden! 
* IgnoreRhosts yes/no 
: Sollen die Dateien ~/.rhosts und ~/.shosts ignoriert werden? 
* KeyRegenerationInterval Zeit 
: Die Anzahl der Sekunden, nach denen der Server-Schlüssel neu erstellt werden soll. 
: Standardmäßig sollte hier 3600 (eine Stunde) stehen. 
: Steht hier eine 0, so wird der Schlüssel niemals neu erstellt. 
* PermitRootLogin yes/no 
: Erlaubt, daß sich der Systemverwalter über ssh einloggen kann. 
* PasswordAuthentication yes/no 
: Soll eine Abfrage des Passwortes durchgeführt werden? 
: Steht der Wert auf »no«, ist ein Anmelden auf einem entfernten Rechner nur möglich, 
: wenn der eigene öffentliche Schlüssel dort bekannt ist. 
* Port n 
: Die Angabe auf welchem Port sshd laufen soll. Normalerweise ist es Port 22. 
* RhostsAuthentication yes/no 
: Ob bei der Authentifizierung die Dateien rhosts und /etc/hosts.equiv ausreichen, 
: soll auf »no« bleiben. 
* RhostsRSAAuthentication yes/no 
: Erlaubt die Benutzung von rhosts und /etc/hosts.equiv, 
: allerdings nur wenn die RSA-HOST-Authentifizierung erfolgreich war. 
: Default »yes«. 
* RSAAuthentication yes/no 
: Authentifizierung mittels RSA-Verschlüsselung. 
: Steht der Wert auf »yes«, sollte die Datei »~/.ssh/identity« 
: oder ein Authentifizierungsagent existieren. 
* StrictHostKeyChecking yes/no 
: Ein »yes« verschärft die Sicherheit, indem das Anmelden nur auf Rechnern gestattet wird, 
: die in den Datenbanken »/etc/known_hosts« bzw. »~/.ssh/known_hosts« enthalten sind. 
: Steht hier »no« werden neu besuchte Rechner automatisch der privaten Datei hinzugefügt. 
 
<hr>
=== Troubleshooting ===

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! 
: Schonmal auf den Server (mit gleicher IP) zugegriffen ? 
: (Schlüssel hat sich geändert) 

> ssh-keygen -R hostname
/home/tux/.ssh/known_hosts updated.
Original contents retained as /home/tux/.ssh/known_hosts.old

Falls es nicht geht: 
: Inhalt von ~/.ssh/known_hosts komplett löschen oder entsprechend editieren! 

Wenn weiter unten die Zeile kommt: 
'DSA host key for 141.44.198.20 has changed and you have requested strict checking.' 
: versuche es mit Änderung in: 
/etc/ssh/sshd_config 
StrictHostKeyChecking: yes/no/ask (def: ask) 

=== Immer noch Probleme? ===

Ist der ssh-Zugriff überhaupt möglich? 
: Ein beliebtes Problem ist '... key_exchange ... connection closed by foreign host'. 
: Das liegt dann meist daran, daß die Reverse-Auflösung der eigenen IP-Adresse nicht 
: mit dem Namen für den eigenen Host übereinstimmt. 
: Auf der anderen Seite in /etc/hosts.deny die ALL: PARANOID Zeile auskommentieren. 
: Oder DNS in Ordnung bringen! 

Passwort wird verlangt. 
: Meistens ein Problem der Permissions auf der eigenen und/oder der anderen Seite: 
: Das Verzeichnis .ssh/ und die die Datei .ssh/authorized_keys darf nur für den Eigentümer, 
: der auch der "angepeilte" Nutzer sein muß, schreibbar sein! 
: ssh -v ... hilft, diese Art von Problemen zu diagnostizieren.

Die SSH2 verlangt die Keys in ~/.ssh/authorized_keys2. 
: Die SSH2 auf Debian/GNU-Linux ist mögl. gepatcht und sucht die wie gehabt in: 
: ~/.ssh/authorized_keys, U.u. muß aber trotzdem auf SuSE-Systemen eben diese 2 angehängt werden. 

<hr>
:: Quellen:
::: [http://www.linux-praxis.de/lpic1/lpi102/1.113.7.html Einrichten von Secure Shell (OpenSSH) - LPI-Study Guides]
::: [http://de.linwiki.org/index.php/Linuxfibel_-_Netzwerk_Server_-_Telnet_%26_Co. Thomas Ermer / Michael Meyer: Linuxfibel - Netzwerk Server - Telnet & Co.]
::: [http://www.schlittermann.de/ssh Heiko Schlittermann: SSH ohne Passwort -- eine kurze Anleitung]
::: [http://www.lrz-muenchen.de/services/security/ssh/ssh-4.html Ernst Bötsch: Secure Shell (SSH) für Benutzer]
::: [http://www.jfranken.de/homepages/johannes/vortraege/ssh1_inhalt.de.html Johannes Franken: OpenSSH Grundlagen]

SSH Konfiguration

2007-10-22T13:20:18Z

OsunSeyi: /* Wie funktioniert SSH? */

== SSH KONFIGURATION ==

=== Wie funktioniert SSH? ===

1...................
: Auf dem Server-Rechner (remote) wird ein Host-Key-Paar (RSA) generiert. 
: - ein Verschlüsselungscode (public_key) 
: - ein Entschlüsselungscode (private_key) 
: Der 'public_key' (öffentlich pubizierter Schlüssel) dient als Erkennung 
: für die Klients. 
: Zusätzlich erzeugt der laufende Server-Prozeß ein Server-Key-Paar, daß nur im 
: Memory des Remote-Rechners gehalten und periodisch erneuert wird. Es dient der 
: Verschlüsselung. 

2...................
: Der lokale SSH-Client wendet sich an den SSH-Server auf dem Remote-Rechner, 
: um eine Verbindung aufzunehmen. 
: Der Server schickt dem Client daraufhin sowohl seinen 'public_key' als auch den 
: periodisch erzeugten öffentlichen Serverschlüssel. 

3...................
: Der Klient überprüft nun den erhaltenen 'public key' mit der Liste in 'known_hosts'. 
: Normalerweise wird er sofort nach seinem Passwort gefragt. 

4...................
: Existiert aber in 'known_hosts' noch kein zugehöriger Eintrag, so wird dieser hinzu- 
: gefügt. Dies erfordert eine ausdrücklicher Bestätigung durch den Benutzer. 
: Also wird der 'public_key' nur bei der ersten Kontaktaufname übermittelt, danach ist 
: er dem Klient bekannt. 
: Ändert er sich, wird der Klient die Kontaktaufname verweigern und wieder neu nachfragen. 

5...................
: Ab dann erzeugt der Client eine Zufallszahl und verschlüsselt diese unter Zuhilfename 
: der beiden übergebenen öffentlichen Schlüssel (Hostkey und Serverkey). 
: Diese Zufallszahl dient im weiteren Verlauf als der aktuelle Sitzungsschlüssel. 

6...................
: Nun erst übergibt der Client Userid und Passwort und der Server startet eine Login-Shell 
: bzw. führt das gewünschte Kommando aus. 

Bei der Authentifizierung des Clients werden der Reihe nach verschiedene Verfahren ausprobiert. 
Dabei wird der Client als berechtigt betrachtet, sobald das erste Verfahren folgender Liste 
erfolgreich war: 

1...................
: Autentifikation entsprechend den r-Kommandos; 
: Unsicher und per Default deaktiviert. 

2...................
: Wie Punkt1; zusätzliche RSA-Authentifikation. 

3...................
: RSA-Authentifikation; dazu ist auf dem Remote-Rechner ein Eintrag in 
: ~/.ssh/authorized_keys erforderlich. 

4...................
: Durch Paßwort-Abfrage. 
 
<hr>

=== Dateien Serverseitig ===

* /etc/ssh/sshd_config 
: Der SSHD wird über diese Datei konfiguriert. 
: Meist sind fast alle Zeilen auskommentiert, 
: dies sollte die praktischen Bedürfnisse auch abdecken. 
: [[SSH_Konfiguration#Die_Datei_.2Fetc.2Fssh.2Fsshd_config:|Konfiguration]] 

* /etc/hosts.allow & deny 
: In aktuellen Implementierungen des Ssh-Daemons ist die Auswertung der Dateien 
: /etc/hosts.allow und /etc/hosts.deny zumeist fest verdrahtet: 

tux> strings /usr/sbin/sshd | egrep 'hosts.allow|hosts.deny'
hosts_allow_table
hosts_deny_table
/etc/hosts.allow
/etc/hosts.deny

# Zugang zur Secure Shell (hosts.allow)
sshd: LOCAL 
# oder genauer:
sshd: 192...(Klient-DNS)/255.255.255.0 *.Domäne: ALLOW 
# Alles pauschal verbieten (hosts.deny)
ALL: ALL

* /etc/nologin
: Wenn sie existiert, verweigert sshd jeden Einlogvorgang außer dem von root 
: (sofern root-Eingänge in der Konfigurationsdatei erlaubt waren). 
: Der Inhalt der Datei wird dem Client übermittelt. 

=== Dateien Clientseitig ===

* /etc/ssh/ssh_known_hosts & ~/.ssh/known_hosts 
: enthalten die Public-Keys aller bekannten Rechner. 
: Die globale Datei wird vom Systemverwalter administriert, 
: die userbezogene wird automatisch angelegt und erweitert. 
: enthält die folgenden Felder: 
: Hostnamen Bits Exponent Modulus Kommentar 
: Hostnamen ist eine durch Kommas getrennte Liste von Namen 
: (* und ? dürfen benutzt werden). 
: Wird mit dem vollständigen Hostnamen des Rechners verglichen, der sich anmelden will. 
: Bits, Exponent und Modulus werden direkt den Host-Schlüsseln entnommen, 
: die in den Dateien /etc/ssh/ssh_host_*_key.pub gespeichert sind. 
: Das optionale Kommentarfeld wird nicht ausgewertet. 

* /etc/ssh/ssh.config 
: Client-Einstellungen. 
 
<hr>
=== Schlüssel - passwortfreie Anmeldung ===

Der Befehl 'ssh-keygen' erzeugt und verwaltet die Schlüssel für SSH-Verbindungen. 
Normaluser können sich damit einen Schlüssel erzeugen, der Systemverwalter kann auch den
Host-Schlüssel damit anlegen. 
Diese Schlüssel sind nicht zwingend für den Gebrauch von SSH erforderlich, bestimmte Server
verlangen ihn aber. 
Es stehen zwei Schlüsseltypen ('RSA' und 'DSA') zur Verfügung, erforderlich ist aber nur
einer von beiden. 
Man wird bei der Erstellung nach einem Passwort gefragt, muß aber keines angeben. 
Es ist also möglich, über diese Schlüsselpaare eine Authentifizierung ohne Passwort zu steuern. 

> ssh-keygen -t rsa
Password:
...
Generating public/private rsa key pair.
... in ~/.ssh/id_dra.pub 
> ssh-keygen -t dsa
Password:
...
Generating public/private dsa key pair.
... in ~/.ssh/id_dsa.pub

Der Inhalt mindestens einer der beiden Dateien 'id_rsa.pub' und 'id_dsa.pub' müssen auf dem
Remote-Rechner in die Datei $HOME/.ssh/authorized_keys eingetragen werden. Verzeichnis als
auch die Datei dürfen nur für den User lesbar und schreibbar sein. 
Die geht manuell oder mit: 

> ssh-copy-id -i /home/tux/.ssh/id_rsa.pub 192...(Server-DNS)
password:
...

In der Serverkonfiguration kann die Passwort-Authentifikation ausgeschaltet werden: 

/etc/ssh/sshd_config: 
# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no

Und gegebenenfalls: 

/etc/ssh/sshd_config: 
- PermitRootLogin yes/no

Der Server muß neu gestartet werden: 

> /etc/init.d/ssh restart
 
<hr>
=== Die Datei /etc/ssh/sshd_config: ===

* BatchMode yes/no 
: Die Abfrage nach dem Passwort oder der Passphrase wird unterbunden, 
: somit lassen sich z.B. Kommandos in Shellscripts ausführen. 
* Compression yes/no 
: Schaltet die Komprimierung der zu übertragenden Daten ein oder aus. 
* FallBackToRsh yes/no 
: Scheitert der Verbindungsaufbau zum Server (zB. weil dieser nicht aktiv ist), 
: kann eine Verbindung über rsh versucht werden. Default: 'no' 
* HostKey Dateiname 
: Spezifiziert die Datei, in der der Host-Schlüssel des Servers abgelegt ist. 
: Normalerweise ist das die Datei /etc/ssh/ssh_host_key. 
: Diese Datei darf nicht für alle Welt lesbar sein, 
: ansonsten verweigert sich sshd die Datei zu verwenden! 
* IgnoreRhosts yes/no 
: Sollen die Dateien ~/.rhosts und ~/.shosts ignoriert werden? 
* KeyRegenerationInterval Zeit 
: Die Anzahl der Sekunden, nach denen der Server-Schlüssel neu erstellt werden soll. 
: Standardmäßig sollte hier 3600 (eine Stunde) stehen. 
: Steht hier eine 0, so wird der Schlüssel niemals neu erstellt. 
* PermitRootLogin yes/no 
: Erlaubt, daß sich der Systemverwalter über ssh einloggen kann. 
* PasswordAuthentication yes/no 
: Soll eine Abfrage des Passwortes durchgeführt werden? 
: Steht der Wert auf »no«, ist ein Anmelden auf einem entfernten Rechner nur möglich, 
: wenn der eigene öffentliche Schlüssel dort bekannt ist. 
* Port n 
: Die Angabe auf welchem Port sshd laufen soll. Normalerweise ist es Port 22. 
* RhostsAuthentication yes/no 
: Ob bei der Authentifizierung die Dateien rhosts und /etc/hosts.equiv ausreichen, 
: soll auf »no« bleiben. 
* RhostsRSAAuthentication yes/no 
: Erlaubt die Benutzung von rhosts und /etc/hosts.equiv, 
: allerdings nur wenn die RSA-HOST-Authentifizierung erfolgreich war. 
: Default »yes«. 
* RSAAuthentication yes/no 
: Authentifizierung mittels RSA-Verschlüsselung. 
: Steht der Wert auf »yes«, sollte die Datei »~/.ssh/identity« 
: oder ein Authentifizierungsagent existieren. 
* StrictHostKeyChecking yes/no 
: Ein »yes« verschärft die Sicherheit, indem das Anmelden nur auf Rechnern gestattet wird, 
: die in den Datenbanken »/etc/known_hosts« bzw. »~/.ssh/known_hosts« enthalten sind. 
: Steht hier »no« werden neu besuchte Rechner automatisch der privaten Datei hinzugefügt. 
 
<hr>
=== Troubleshooting ===

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! 
: Schonmal auf den Server (mit gleicher IP) zugegriffen ? 
: (Schlüssel hat sich geändert) 

> ssh-keygen -R hostname
/home/tux/.ssh/known_hosts updated.
Original contents retained as /home/tux/.ssh/known_hosts.old

Falls es nicht geht: 
: Inhalt von ~/.ssh/known_hosts komplett löschen oder entsprechend editieren! 

Wenn weiter unten die Zeile kommt: 
'DSA host key for 141.44.198.20 has changed and you have requested strict checking.' 
: versuche es mit Änderung in: 
/etc/ssh/sshd_config 
StrictHostKeyChecking: yes/no/ask (def: ask) 

=== Immer noch Probleme? ===

Ist der ssh-Zugriff überhaupt möglich? 
: Ein beliebtes Problem ist '... key_exchange ... connection closed by foreign host'. 
: Das liegt dann meist daran, daß die Reverse-Auflösung der eigenen IP-Adresse nicht 
: mit dem Namen für den eigenen Host übereinstimmt. 
: Auf der anderen Seite in /etc/hosts.deny die ALL: PARANOID Zeile auskommentieren. 
: Oder DNS in Ordnung bringen! 

Passwort wird verlangt. 
: Meistens ein Problem der Permissions auf der eigenen und/oder der anderen Seite: 
: Das Verzeichnis .ssh/ und die die Datei .ssh/authorized_keys darf nur für den Eigentümer, 
: der auch der "angepeilte" Nutzer sein muß, schreibbar sein! 
: ssh -v ... hilft, diese Art von Problemen zu diagnostizieren.

Die SSH2 verlangt die Keys in ~/.ssh/authorized_keys2. 
: Die SSH2 auf Debian/GNU-Linux ist mögl. gepatcht und sucht die wie gehabt in: 
: ~/.ssh/authorized_keys, U.u. muß aber trotzdem auf SuSE-Systemen eben diese 2 angehängt werden. 

<hr>
:: Quellen:
::: [http://www.linux-praxis.de/lpic1/lpi102/1.113.7.html Einrichten von Secure Shell (OpenSSH) - LPI-Study Guides]
::: [http://de.linwiki.org/index.php/Linuxfibel_-_Netzwerk_Server_-_Telnet_%26_Co. Thomas Ermer / Michael Meyer: Linuxfibel - Netzwerk Server - Telnet & Co.]
::: [http://www.schlittermann.de/ssh Heiko Schlittermann: SSH ohne Passwort -- eine kurze Anleitung]
::: [http://www.lrz-muenchen.de/services/security/ssh/ssh-4.html Ernst Bötsch: Secure Shell (SSH) für Benutzer]
::: [http://www.jfranken.de/homepages/johannes/vortraege/ssh1_inhalt.de.html Johannes Franken: OpenSSH Grundlagen]

SSH Konfiguration

2007-10-22T11:38:17Z

OsunSeyi: /* Dateien Serverseitig */

== SSH KONFIGURATION ==

=== Wie funktioniert SSH? ===

1.
: Auf dem Server-Rechner (remote) wird ein Host-Key-Paar (RSA) generiert. 
: - ein Verschlüsselungscode (public_key) 
: - ein Entschlüsselungscode (private_key) 
: Der 'public_key' (öffentlich pubizierter Schlüssel) dient als Erkennung 
: für die Klients. 
: Zusätzlich erzeugt der laufende Server-Prozeß ein Server-Key-Paar, daß nur im 
: Memory des Remote-Rechners gehalten und periodisch erneuert wird. Es dient der 
: Verschlüsselung. 

2.
: Der lokale SSH-Client wendet sich an den SSH-Server auf dem Remote-Rechner, 
: um eine Verbindung aufzunehmen. 
: Der Server schickt dem Client daraufhin sowohl seinen 'public_key' als auch den 
: periodisch erzeugten öffentlichen Serverschlüssel. 

3.
: Der Klient überprüft nun den erhaltenen 'public key' mit der Liste in 'known_hosts'. 
: Normalerweise wird er sofort nach seinem Passwort gefragt. 

4.
: Existiert aber in 'known_hosts' noch kein zugehöriger Eintrag, so wird dieser hinzu- 
: gefügt. Dies erfordert eine ausdrücklicher Bestätigung durch den Benutzer. 
: Also wird der 'public_key' nur bei der ersten Kontaktaufname übermittelt, danach ist 
: er dem Klient bekannt. 
: Ändert er sich, wird der Klient die Kontaktaufname verweigern und wieder neu nachfragen. 

5.
: Ab dann erzeugt der Client eine Zufallszahl und verschlüsselt diese unter Zuhilfename 
: der beiden übergebenen öffentlichen Schlüssel (Hostkey und Serverkey). 
: Diese Zufallszahl dient im weiteren Verlauf als der aktuelle Sitzungsschlüssel. 

6.
: Nun erst übergibt der Client Userid und Passwort und der Server startet eine Login-Shell 
: bzw. führt das gewünschte Kommando aus. 

Bei der Authentifizierung des Clients werden der Reihe nach verschiedene Verfahren ausprobiert. 
Dabei wird der Client als berechtigt betrachtet, sobald das erste Verfahren folgender Liste 
erfolgreich war: 

1.
: Autentifikation entsprechend den r-Kommandos; 
: Unsicher und per Default deaktiviert. 

2.
: Wie Punkt1; zusätzliche RSA-Authentifikation. 

3.
: RSA-Authentifikation; dazu ist auf dem Remote-Rechner ein Eintrag in 
: ~/.ssh/authorized_keys erforderlich. 

4.
: Durch Paßwort-Abfrage. 
 
<hr>

=== Dateien Serverseitig ===

* /etc/ssh/sshd_config 
: Der SSHD wird über diese Datei konfiguriert. 
: Meist sind fast alle Zeilen auskommentiert, 
: dies sollte die praktischen Bedürfnisse auch abdecken. 
: [[SSH_Konfiguration#Die_Datei_.2Fetc.2Fssh.2Fsshd_config:|Konfiguration]] 

* /etc/hosts.allow & deny 
: In aktuellen Implementierungen des Ssh-Daemons ist die Auswertung der Dateien 
: /etc/hosts.allow und /etc/hosts.deny zumeist fest verdrahtet: 

tux> strings /usr/sbin/sshd | egrep 'hosts.allow|hosts.deny'
hosts_allow_table
hosts_deny_table
/etc/hosts.allow
/etc/hosts.deny

# Zugang zur Secure Shell (hosts.allow)
sshd: LOCAL 
# oder genauer:
sshd: 192...(Klient-DNS)/255.255.255.0 *.Domäne: ALLOW 
# Alles pauschal verbieten (hosts.deny)
ALL: ALL

* /etc/nologin
: Wenn sie existiert, verweigert sshd jeden Einlogvorgang außer dem von root 
: (sofern root-Eingänge in der Konfigurationsdatei erlaubt waren). 
: Der Inhalt der Datei wird dem Client übermittelt. 

=== Dateien Clientseitig ===

* /etc/ssh/ssh_known_hosts & ~/.ssh/known_hosts 
: enthalten die Public-Keys aller bekannten Rechner. 
: Die globale Datei wird vom Systemverwalter administriert, 
: die userbezogene wird automatisch angelegt und erweitert. 
: enthält die folgenden Felder: 
: Hostnamen Bits Exponent Modulus Kommentar 
: Hostnamen ist eine durch Kommas getrennte Liste von Namen 
: (* und ? dürfen benutzt werden). 
: Wird mit dem vollständigen Hostnamen des Rechners verglichen, der sich anmelden will. 
: Bits, Exponent und Modulus werden direkt den Host-Schlüsseln entnommen, 
: die in den Dateien /etc/ssh/ssh_host_*_key.pub gespeichert sind. 
: Das optionale Kommentarfeld wird nicht ausgewertet. 

* /etc/ssh/ssh.config 
: Client-Einstellungen. 
 
<hr>
=== Schlüssel - passwortfreie Anmeldung ===

Der Befehl 'ssh-keygen' erzeugt und verwaltet die Schlüssel für SSH-Verbindungen. 
Normaluser können sich damit einen Schlüssel erzeugen, der Systemverwalter kann auch den
Host-Schlüssel damit anlegen. 
Diese Schlüssel sind nicht zwingend für den Gebrauch von SSH erforderlich, bestimmte Server
verlangen ihn aber. 
Es stehen zwei Schlüsseltypen ('RSA' und 'DSA') zur Verfügung, erforderlich ist aber nur
einer von beiden. 
Man wird bei der Erstellung nach einem Passwort gefragt, muß aber keines angeben. 
Es ist also möglich, über diese Schlüsselpaare eine Authentifizierung ohne Passwort zu steuern. 

> ssh-keygen -t rsa
Password:
...
Generating public/private rsa key pair.
... in ~/.ssh/id_dra.pub 
> ssh-keygen -t dsa
Password:
...
Generating public/private dsa key pair.
... in ~/.ssh/id_dsa.pub

Der Inhalt mindestens einer der beiden Dateien 'id_rsa.pub' und 'id_dsa.pub' müssen auf dem
Remote-Rechner in die Datei $HOME/.ssh/authorized_keys eingetragen werden. Verzeichnis als
auch die Datei dürfen nur für den User lesbar und schreibbar sein. 
Die geht manuell oder mit: 

> ssh-copy-id -i /home/tux/.ssh/id_rsa.pub 192...(Server-DNS)
password:
...

In der Serverkonfiguration kann die Passwort-Authentifikation ausgeschaltet werden: 

/etc/ssh/sshd_config: 
# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no

Und gegebenenfalls: 

/etc/ssh/sshd_config: 
- PermitRootLogin yes/no

Der Server muß neu gestartet werden: 

> /etc/init.d/ssh restart
 
<hr>
=== Die Datei /etc/ssh/sshd_config: ===

* BatchMode yes/no 
: Die Abfrage nach dem Passwort oder der Passphrase wird unterbunden, 
: somit lassen sich z.B. Kommandos in Shellscripts ausführen. 
* Compression yes/no 
: Schaltet die Komprimierung der zu übertragenden Daten ein oder aus. 
* FallBackToRsh yes/no 
: Scheitert der Verbindungsaufbau zum Server (zB. weil dieser nicht aktiv ist), 
: kann eine Verbindung über rsh versucht werden. Default: 'no' 
* HostKey Dateiname 
: Spezifiziert die Datei, in der der Host-Schlüssel des Servers abgelegt ist. 
: Normalerweise ist das die Datei /etc/ssh/ssh_host_key. 
: Diese Datei darf nicht für alle Welt lesbar sein, 
: ansonsten verweigert sich sshd die Datei zu verwenden! 
* IgnoreRhosts yes/no 
: Sollen die Dateien ~/.rhosts und ~/.shosts ignoriert werden? 
* KeyRegenerationInterval Zeit 
: Die Anzahl der Sekunden, nach denen der Server-Schlüssel neu erstellt werden soll. 
: Standardmäßig sollte hier 3600 (eine Stunde) stehen. 
: Steht hier eine 0, so wird der Schlüssel niemals neu erstellt. 
* PermitRootLogin yes/no 
: Erlaubt, daß sich der Systemverwalter über ssh einloggen kann. 
* PasswordAuthentication yes/no 
: Soll eine Abfrage des Passwortes durchgeführt werden? 
: Steht der Wert auf »no«, ist ein Anmelden auf einem entfernten Rechner nur möglich, 
: wenn der eigene öffentliche Schlüssel dort bekannt ist. 
* Port n 
: Die Angabe auf welchem Port sshd laufen soll. Normalerweise ist es Port 22. 
* RhostsAuthentication yes/no 
: Ob bei der Authentifizierung die Dateien rhosts und /etc/hosts.equiv ausreichen, 
: soll auf »no« bleiben. 
* RhostsRSAAuthentication yes/no 
: Erlaubt die Benutzung von rhosts und /etc/hosts.equiv, 
: allerdings nur wenn die RSA-HOST-Authentifizierung erfolgreich war. 
: Default »yes«. 
* RSAAuthentication yes/no 
: Authentifizierung mittels RSA-Verschlüsselung. 
: Steht der Wert auf »yes«, sollte die Datei »~/.ssh/identity« 
: oder ein Authentifizierungsagent existieren. 
* StrictHostKeyChecking yes/no 
: Ein »yes« verschärft die Sicherheit, indem das Anmelden nur auf Rechnern gestattet wird, 
: die in den Datenbanken »/etc/known_hosts« bzw. »~/.ssh/known_hosts« enthalten sind. 
: Steht hier »no« werden neu besuchte Rechner automatisch der privaten Datei hinzugefügt. 
 
<hr>
=== Troubleshooting ===

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! 
: Schonmal auf den Server (mit gleicher IP) zugegriffen ? 
: (Schlüssel hat sich geändert) 

> ssh-keygen -R hostname
/home/tux/.ssh/known_hosts updated.
Original contents retained as /home/tux/.ssh/known_hosts.old

Falls es nicht geht: 
: Inhalt von ~/.ssh/known_hosts komplett löschen oder entsprechend editieren! 

Wenn weiter unten die Zeile kommt: 
'DSA host key for 141.44.198.20 has changed and you have requested strict checking.' 
: versuche es mit Änderung in: 
/etc/ssh/sshd_config 
StrictHostKeyChecking: yes/no/ask (def: ask) 

=== Immer noch Probleme? ===

Ist der ssh-Zugriff überhaupt möglich? 
: Ein beliebtes Problem ist '... key_exchange ... connection closed by foreign host'. 
: Das liegt dann meist daran, daß die Reverse-Auflösung der eigenen IP-Adresse nicht 
: mit dem Namen für den eigenen Host übereinstimmt. 
: Auf der anderen Seite in /etc/hosts.deny die ALL: PARANOID Zeile auskommentieren. 
: Oder DNS in Ordnung bringen! 

Passwort wird verlangt. 
: Meistens ein Problem der Permissions auf der eigenen und/oder der anderen Seite: 
: Das Verzeichnis .ssh/ und die die Datei .ssh/authorized_keys darf nur für den Eigentümer, 
: der auch der "angepeilte" Nutzer sein muß, schreibbar sein! 
: ssh -v ... hilft, diese Art von Problemen zu diagnostizieren.

Die SSH2 verlangt die Keys in ~/.ssh/authorized_keys2. 
: Die SSH2 auf Debian/GNU-Linux ist mögl. gepatcht und sucht die wie gehabt in: 
: ~/.ssh/authorized_keys, U.u. muß aber trotzdem auf SuSE-Systemen eben diese 2 angehängt werden. 

<hr>
:: Quellen:
::: [http://www.linux-praxis.de/lpic1/lpi102/1.113.7.html Einrichten von Secure Shell (OpenSSH) - LPI-Study Guides]
::: [http://de.linwiki.org/index.php/Linuxfibel_-_Netzwerk_Server_-_Telnet_%26_Co. Thomas Ermer / Michael Meyer: Linuxfibel - Netzwerk Server - Telnet & Co.]
::: [http://www.schlittermann.de/ssh Heiko Schlittermann: SSH ohne Passwort -- eine kurze Anleitung]
::: [http://www.lrz-muenchen.de/services/security/ssh/ssh-4.html Ernst Bötsch: Secure Shell (SSH) für Benutzer]
::: [http://www.jfranken.de/homepages/johannes/vortraege/ssh1_inhalt.de.html Johannes Franken: OpenSSH Grundlagen]

SSH Konfiguration

2007-10-22T11:32:04Z

OsunSeyi: /* Dateien Serverseitig */

== SSH KONFIGURATION ==

=== Wie funktioniert SSH? ===

1.
: Auf dem Server-Rechner (remote) wird ein Host-Key-Paar (RSA) generiert. 
: - ein Verschlüsselungscode (public_key) 
: - ein Entschlüsselungscode (private_key) 
: Der 'public_key' (öffentlich pubizierter Schlüssel) dient als Erkennung 
: für die Klients. 
: Zusätzlich erzeugt der laufende Server-Prozeß ein Server-Key-Paar, daß nur im 
: Memory des Remote-Rechners gehalten und periodisch erneuert wird. Es dient der 
: Verschlüsselung. 

2.
: Der lokale SSH-Client wendet sich an den SSH-Server auf dem Remote-Rechner, 
: um eine Verbindung aufzunehmen. 
: Der Server schickt dem Client daraufhin sowohl seinen 'public_key' als auch den 
: periodisch erzeugten öffentlichen Serverschlüssel. 

3.
: Der Klient überprüft nun den erhaltenen 'public key' mit der Liste in 'known_hosts'. 
: Normalerweise wird er sofort nach seinem Passwort gefragt. 

4.
: Existiert aber in 'known_hosts' noch kein zugehöriger Eintrag, so wird dieser hinzu- 
: gefügt. Dies erfordert eine ausdrücklicher Bestätigung durch den Benutzer. 
: Also wird der 'public_key' nur bei der ersten Kontaktaufname übermittelt, danach ist 
: er dem Klient bekannt. 
: Ändert er sich, wird der Klient die Kontaktaufname verweigern und wieder neu nachfragen. 

5.
: Ab dann erzeugt der Client eine Zufallszahl und verschlüsselt diese unter Zuhilfename 
: der beiden übergebenen öffentlichen Schlüssel (Hostkey und Serverkey). 
: Diese Zufallszahl dient im weiteren Verlauf als der aktuelle Sitzungsschlüssel. 

6.
: Nun erst übergibt der Client Userid und Passwort und der Server startet eine Login-Shell 
: bzw. führt das gewünschte Kommando aus. 

Bei der Authentifizierung des Clients werden der Reihe nach verschiedene Verfahren ausprobiert. 
Dabei wird der Client als berechtigt betrachtet, sobald das erste Verfahren folgender Liste 
erfolgreich war: 

1.
: Autentifikation entsprechend den r-Kommandos; 
: Unsicher und per Default deaktiviert. 

2.
: Wie Punkt1; zusätzliche RSA-Authentifikation. 

3.
: RSA-Authentifikation; dazu ist auf dem Remote-Rechner ein Eintrag in 
: ~/.ssh/authorized_keys erforderlich. 

4.
: Durch Paßwort-Abfrage. 
 
<hr>

=== Dateien Serverseitig ===

* /etc/ssh/sshd_config 
: Der SSHD wird über diese Datei konfiguriert. 
: Meist sind fast alle Zeilen auskommentiert, 
: dies sollte die praktischen Bedürfnisse auch abdecken. 
: [# Die Datei /etc/ssh/sshd_config:|Konfiguration] 

* /etc/hosts.allow & deny 
: In aktuellen Implementierungen des Ssh-Daemons ist die Auswertung der Dateien 
: /etc/hosts.allow und /etc/hosts.deny zumeist fest verdrahtet: 

tux> strings /usr/sbin/sshd | egrep 'hosts.allow|hosts.deny'
hosts_allow_table
hosts_deny_table
/etc/hosts.allow
/etc/hosts.deny

# Zugang zur Secure Shell (hosts.allow)
sshd: LOCAL 
# oder genauer:
sshd: 192...(Klient-DNS)/255.255.255.0 *.Domäne: ALLOW 
# Alles pauschal verbieten (hosts.deny)
ALL: ALL

* /etc/nologin
: Wenn sie existiert, verweigert sshd jeden Einlogvorgang außer dem von root 
: (sofern root-Eingänge in der Konfigurationsdatei erlaubt waren). 
: Der Inhalt der Datei wird dem Client übermittelt. 

=== Dateien Clientseitig ===

* /etc/ssh/ssh_known_hosts & ~/.ssh/known_hosts 
: enthalten die Public-Keys aller bekannten Rechner. 
: Die globale Datei wird vom Systemverwalter administriert, 
: die userbezogene wird automatisch angelegt und erweitert. 
: enthält die folgenden Felder: 
: Hostnamen Bits Exponent Modulus Kommentar 
: Hostnamen ist eine durch Kommas getrennte Liste von Namen 
: (* und ? dürfen benutzt werden). 
: Wird mit dem vollständigen Hostnamen des Rechners verglichen, der sich anmelden will. 
: Bits, Exponent und Modulus werden direkt den Host-Schlüsseln entnommen, 
: die in den Dateien /etc/ssh/ssh_host_*_key.pub gespeichert sind. 
: Das optionale Kommentarfeld wird nicht ausgewertet. 

* /etc/ssh/ssh.config 
: Client-Einstellungen. 
 
<hr>
=== Schlüssel - passwortfreie Anmeldung ===

Der Befehl 'ssh-keygen' erzeugt und verwaltet die Schlüssel für SSH-Verbindungen. 
Normaluser können sich damit einen Schlüssel erzeugen, der Systemverwalter kann auch den
Host-Schlüssel damit anlegen. 
Diese Schlüssel sind nicht zwingend für den Gebrauch von SSH erforderlich, bestimmte Server
verlangen ihn aber. 
Es stehen zwei Schlüsseltypen ('RSA' und 'DSA') zur Verfügung, erforderlich ist aber nur
einer von beiden. 
Man wird bei der Erstellung nach einem Passwort gefragt, muß aber keines angeben. 
Es ist also möglich, über diese Schlüsselpaare eine Authentifizierung ohne Passwort zu steuern. 

> ssh-keygen -t rsa
Password:
...
Generating public/private rsa key pair.
... in ~/.ssh/id_dra.pub 
> ssh-keygen -t dsa
Password:
...
Generating public/private dsa key pair.
... in ~/.ssh/id_dsa.pub

Der Inhalt mindestens einer der beiden Dateien 'id_rsa.pub' und 'id_dsa.pub' müssen auf dem
Remote-Rechner in die Datei $HOME/.ssh/authorized_keys eingetragen werden. Verzeichnis als
auch die Datei dürfen nur für den User lesbar und schreibbar sein. 
Die geht manuell oder mit: 

> ssh-copy-id -i /home/tux/.ssh/id_rsa.pub 192...(Server-DNS)
password:
...

In der Serverkonfiguration kann die Passwort-Authentifikation ausgeschaltet werden: 

/etc/ssh/sshd_config: 
# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no

Und gegebenenfalls: 

/etc/ssh/sshd_config: 
- PermitRootLogin yes/no

Der Server muß neu gestartet werden: 

> /etc/init.d/ssh restart
 
<hr>
=== Die Datei /etc/ssh/sshd_config: ===

* BatchMode yes/no 
: Die Abfrage nach dem Passwort oder der Passphrase wird unterbunden, 
: somit lassen sich z.B. Kommandos in Shellscripts ausführen. 
* Compression yes/no 
: Schaltet die Komprimierung der zu übertragenden Daten ein oder aus. 
* FallBackToRsh yes/no 
: Scheitert der Verbindungsaufbau zum Server (zB. weil dieser nicht aktiv ist), 
: kann eine Verbindung über rsh versucht werden. Default: 'no' 
* HostKey Dateiname 
: Spezifiziert die Datei, in der der Host-Schlüssel des Servers abgelegt ist. 
: Normalerweise ist das die Datei /etc/ssh/ssh_host_key. 
: Diese Datei darf nicht für alle Welt lesbar sein, 
: ansonsten verweigert sich sshd die Datei zu verwenden! 
* IgnoreRhosts yes/no 
: Sollen die Dateien ~/.rhosts und ~/.shosts ignoriert werden? 
* KeyRegenerationInterval Zeit 
: Die Anzahl der Sekunden, nach denen der Server-Schlüssel neu erstellt werden soll. 
: Standardmäßig sollte hier 3600 (eine Stunde) stehen. 
: Steht hier eine 0, so wird der Schlüssel niemals neu erstellt. 
* PermitRootLogin yes/no 
: Erlaubt, daß sich der Systemverwalter über ssh einloggen kann. 
* PasswordAuthentication yes/no 
: Soll eine Abfrage des Passwortes durchgeführt werden? 
: Steht der Wert auf »no«, ist ein Anmelden auf einem entfernten Rechner nur möglich, 
: wenn der eigene öffentliche Schlüssel dort bekannt ist. 
* Port n 
: Die Angabe auf welchem Port sshd laufen soll. Normalerweise ist es Port 22. 
* RhostsAuthentication yes/no 
: Ob bei der Authentifizierung die Dateien rhosts und /etc/hosts.equiv ausreichen, 
: soll auf »no« bleiben. 
* RhostsRSAAuthentication yes/no 
: Erlaubt die Benutzung von rhosts und /etc/hosts.equiv, 
: allerdings nur wenn die RSA-HOST-Authentifizierung erfolgreich war. 
: Default »yes«. 
* RSAAuthentication yes/no 
: Authentifizierung mittels RSA-Verschlüsselung. 
: Steht der Wert auf »yes«, sollte die Datei »~/.ssh/identity« 
: oder ein Authentifizierungsagent existieren. 
* StrictHostKeyChecking yes/no 
: Ein »yes« verschärft die Sicherheit, indem das Anmelden nur auf Rechnern gestattet wird, 
: die in den Datenbanken »/etc/known_hosts« bzw. »~/.ssh/known_hosts« enthalten sind. 
: Steht hier »no« werden neu besuchte Rechner automatisch der privaten Datei hinzugefügt. 
 
<hr>
=== Troubleshooting ===

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! 
: Schonmal auf den Server (mit gleicher IP) zugegriffen ? 
: (Schlüssel hat sich geändert) 

> ssh-keygen -R hostname
/home/tux/.ssh/known_hosts updated.
Original contents retained as /home/tux/.ssh/known_hosts.old

Falls es nicht geht: 
: Inhalt von ~/.ssh/known_hosts komplett löschen oder entsprechend editieren! 

Wenn weiter unten die Zeile kommt: 
'DSA host key for 141.44.198.20 has changed and you have requested strict checking.' 
: versuche es mit Änderung in: 
/etc/ssh/sshd_config 
StrictHostKeyChecking: yes/no/ask (def: ask) 

=== Immer noch Probleme? ===

Ist der ssh-Zugriff überhaupt möglich? 
: Ein beliebtes Problem ist '... key_exchange ... connection closed by foreign host'. 
: Das liegt dann meist daran, daß die Reverse-Auflösung der eigenen IP-Adresse nicht 
: mit dem Namen für den eigenen Host übereinstimmt. 
: Auf der anderen Seite in /etc/hosts.deny die ALL: PARANOID Zeile auskommentieren. 
: Oder DNS in Ordnung bringen! 

Passwort wird verlangt. 
: Meistens ein Problem der Permissions auf der eigenen und/oder der anderen Seite: 
: Das Verzeichnis .ssh/ und die die Datei .ssh/authorized_keys darf nur für den Eigentümer, 
: der auch der "angepeilte" Nutzer sein muß, schreibbar sein! 
: ssh -v ... hilft, diese Art von Problemen zu diagnostizieren.

Die SSH2 verlangt die Keys in ~/.ssh/authorized_keys2. 
: Die SSH2 auf Debian/GNU-Linux ist mögl. gepatcht und sucht die wie gehabt in: 
: ~/.ssh/authorized_keys, U.u. muß aber trotzdem auf SuSE-Systemen eben diese 2 angehängt werden. 

<hr>
:: Quellen:
::: [http://www.linux-praxis.de/lpic1/lpi102/1.113.7.html Einrichten von Secure Shell (OpenSSH) - LPI-Study Guides]
::: [http://de.linwiki.org/index.php/Linuxfibel_-_Netzwerk_Server_-_Telnet_%26_Co. Thomas Ermer / Michael Meyer: Linuxfibel - Netzwerk Server - Telnet & Co.]
::: [http://www.schlittermann.de/ssh Heiko Schlittermann: SSH ohne Passwort -- eine kurze Anleitung]
::: [http://www.lrz-muenchen.de/services/security/ssh/ssh-4.html Ernst Bötsch: Secure Shell (SSH) für Benutzer]
::: [http://www.jfranken.de/homepages/johannes/vortraege/ssh1_inhalt.de.html Johannes Franken: OpenSSH Grundlagen]

SSH Konfiguration

2007-10-22T11:27:43Z

OsunSeyi: /* Wie funktioniert SSH? */

== SSH KONFIGURATION ==

=== Wie funktioniert SSH? ===

1.
: Auf dem Server-Rechner (remote) wird ein Host-Key-Paar (RSA) generiert. 
: - ein Verschlüsselungscode (public_key) 
: - ein Entschlüsselungscode (private_key) 
: Der 'public_key' (öffentlich pubizierter Schlüssel) dient als Erkennung 
: für die Klients. 
: Zusätzlich erzeugt der laufende Server-Prozeß ein Server-Key-Paar, daß nur im 
: Memory des Remote-Rechners gehalten und periodisch erneuert wird. Es dient der 
: Verschlüsselung. 

2.
: Der lokale SSH-Client wendet sich an den SSH-Server auf dem Remote-Rechner, 
: um eine Verbindung aufzunehmen. 
: Der Server schickt dem Client daraufhin sowohl seinen 'public_key' als auch den 
: periodisch erzeugten öffentlichen Serverschlüssel. 

3.
: Der Klient überprüft nun den erhaltenen 'public key' mit der Liste in 'known_hosts'. 
: Normalerweise wird er sofort nach seinem Passwort gefragt. 

4.
: Existiert aber in 'known_hosts' noch kein zugehöriger Eintrag, so wird dieser hinzu- 
: gefügt. Dies erfordert eine ausdrücklicher Bestätigung durch den Benutzer. 
: Also wird der 'public_key' nur bei der ersten Kontaktaufname übermittelt, danach ist 
: er dem Klient bekannt. 
: Ändert er sich, wird der Klient die Kontaktaufname verweigern und wieder neu nachfragen. 

5.
: Ab dann erzeugt der Client eine Zufallszahl und verschlüsselt diese unter Zuhilfename 
: der beiden übergebenen öffentlichen Schlüssel (Hostkey und Serverkey). 
: Diese Zufallszahl dient im weiteren Verlauf als der aktuelle Sitzungsschlüssel. 

6.
: Nun erst übergibt der Client Userid und Passwort und der Server startet eine Login-Shell 
: bzw. führt das gewünschte Kommando aus. 

Bei der Authentifizierung des Clients werden der Reihe nach verschiedene Verfahren ausprobiert. 
Dabei wird der Client als berechtigt betrachtet, sobald das erste Verfahren folgender Liste 
erfolgreich war: 

1.
: Autentifikation entsprechend den r-Kommandos; 
: Unsicher und per Default deaktiviert. 

2.
: Wie Punkt1; zusätzliche RSA-Authentifikation. 

3.
: RSA-Authentifikation; dazu ist auf dem Remote-Rechner ein Eintrag in 
: ~/.ssh/authorized_keys erforderlich. 

4.
: Durch Paßwort-Abfrage. 
 
<hr>

=== Dateien Serverseitig ===

* /etc/ssh/sshd_config 
: Der SSHD wird über diese Datei konfiguriert. 
: Meist sind fast alle Zeilen auskommentiert, 
: dies sollte die praktischen Bedürfnisse auch abdecken. 
: Konfiguration 

* /etc/hosts.allow & deny 
: In aktuellen Implementierungen des Ssh-Daemons ist die Auswertung der Dateien 
: /etc/hosts.allow und /etc/hosts.deny zumeist fest verdrahtet: 

tux> strings /usr/sbin/sshd | egrep 'hosts.allow|hosts.deny'
hosts_allow_table
hosts_deny_table
/etc/hosts.allow
/etc/hosts.deny

# Zugang zur Secure Shell (hosts.allow)
sshd: LOCAL 
# oder genauer:
sshd: 192...(Klient-DNS)/255.255.255.0 *.Domäne: ALLOW 
# Alles pauschal verbieten (hosts.deny)
ALL: ALL

* /etc/nologin
: Wenn sie existiert, verweigert sshd jeden Einlogvorgang außer dem von root 
: (sofern root-Eingänge in der Konfigurationsdatei erlaubt waren). 
: Der Inhalt der Datei wird dem Client übermittelt. 

=== Dateien Clientseitig ===

* /etc/ssh/ssh_known_hosts & ~/.ssh/known_hosts 
: enthalten die Public-Keys aller bekannten Rechner. 
: Die globale Datei wird vom Systemverwalter administriert, 
: die userbezogene wird automatisch angelegt und erweitert. 
: enthält die folgenden Felder: 
: Hostnamen Bits Exponent Modulus Kommentar 
: Hostnamen ist eine durch Kommas getrennte Liste von Namen 
: (* und ? dürfen benutzt werden). 
: Wird mit dem vollständigen Hostnamen des Rechners verglichen, der sich anmelden will. 
: Bits, Exponent und Modulus werden direkt den Host-Schlüsseln entnommen, 
: die in den Dateien /etc/ssh/ssh_host_*_key.pub gespeichert sind. 
: Das optionale Kommentarfeld wird nicht ausgewertet. 

* /etc/ssh/ssh.config 
: Client-Einstellungen. 
 
<hr>
=== Schlüssel - passwortfreie Anmeldung ===

Der Befehl 'ssh-keygen' erzeugt und verwaltet die Schlüssel für SSH-Verbindungen. 
Normaluser können sich damit einen Schlüssel erzeugen, der Systemverwalter kann auch den
Host-Schlüssel damit anlegen. 
Diese Schlüssel sind nicht zwingend für den Gebrauch von SSH erforderlich, bestimmte Server
verlangen ihn aber. 
Es stehen zwei Schlüsseltypen ('RSA' und 'DSA') zur Verfügung, erforderlich ist aber nur
einer von beiden. 
Man wird bei der Erstellung nach einem Passwort gefragt, muß aber keines angeben. 
Es ist also möglich, über diese Schlüsselpaare eine Authentifizierung ohne Passwort zu steuern. 

> ssh-keygen -t rsa
Password:
...
Generating public/private rsa key pair.
... in ~/.ssh/id_dra.pub 
> ssh-keygen -t dsa
Password:
...
Generating public/private dsa key pair.
... in ~/.ssh/id_dsa.pub

Der Inhalt mindestens einer der beiden Dateien 'id_rsa.pub' und 'id_dsa.pub' müssen auf dem
Remote-Rechner in die Datei $HOME/.ssh/authorized_keys eingetragen werden. Verzeichnis als
auch die Datei dürfen nur für den User lesbar und schreibbar sein. 
Die geht manuell oder mit: 

> ssh-copy-id -i /home/tux/.ssh/id_rsa.pub 192...(Server-DNS)
password:
...

In der Serverkonfiguration kann die Passwort-Authentifikation ausgeschaltet werden: 

/etc/ssh/sshd_config: 
# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no

Und gegebenenfalls: 

/etc/ssh/sshd_config: 
- PermitRootLogin yes/no

Der Server muß neu gestartet werden: 

> /etc/init.d/ssh restart
 
<hr>
=== Die Datei /etc/ssh/sshd_config: ===

* BatchMode yes/no 
: Die Abfrage nach dem Passwort oder der Passphrase wird unterbunden, 
: somit lassen sich z.B. Kommandos in Shellscripts ausführen. 
* Compression yes/no 
: Schaltet die Komprimierung der zu übertragenden Daten ein oder aus. 
* FallBackToRsh yes/no 
: Scheitert der Verbindungsaufbau zum Server (zB. weil dieser nicht aktiv ist), 
: kann eine Verbindung über rsh versucht werden. Default: 'no' 
* HostKey Dateiname 
: Spezifiziert die Datei, in der der Host-Schlüssel des Servers abgelegt ist. 
: Normalerweise ist das die Datei /etc/ssh/ssh_host_key. 
: Diese Datei darf nicht für alle Welt lesbar sein, 
: ansonsten verweigert sich sshd die Datei zu verwenden! 
* IgnoreRhosts yes/no 
: Sollen die Dateien ~/.rhosts und ~/.shosts ignoriert werden? 
* KeyRegenerationInterval Zeit 
: Die Anzahl der Sekunden, nach denen der Server-Schlüssel neu erstellt werden soll. 
: Standardmäßig sollte hier 3600 (eine Stunde) stehen. 
: Steht hier eine 0, so wird der Schlüssel niemals neu erstellt. 
* PermitRootLogin yes/no 
: Erlaubt, daß sich der Systemverwalter über ssh einloggen kann. 
* PasswordAuthentication yes/no 
: Soll eine Abfrage des Passwortes durchgeführt werden? 
: Steht der Wert auf »no«, ist ein Anmelden auf einem entfernten Rechner nur möglich, 
: wenn der eigene öffentliche Schlüssel dort bekannt ist. 
* Port n 
: Die Angabe auf welchem Port sshd laufen soll. Normalerweise ist es Port 22. 
* RhostsAuthentication yes/no 
: Ob bei der Authentifizierung die Dateien rhosts und /etc/hosts.equiv ausreichen, 
: soll auf »no« bleiben. 
* RhostsRSAAuthentication yes/no 
: Erlaubt die Benutzung von rhosts und /etc/hosts.equiv, 
: allerdings nur wenn die RSA-HOST-Authentifizierung erfolgreich war. 
: Default »yes«. 
* RSAAuthentication yes/no 
: Authentifizierung mittels RSA-Verschlüsselung. 
: Steht der Wert auf »yes«, sollte die Datei »~/.ssh/identity« 
: oder ein Authentifizierungsagent existieren. 
* StrictHostKeyChecking yes/no 
: Ein »yes« verschärft die Sicherheit, indem das Anmelden nur auf Rechnern gestattet wird, 
: die in den Datenbanken »/etc/known_hosts« bzw. »~/.ssh/known_hosts« enthalten sind. 
: Steht hier »no« werden neu besuchte Rechner automatisch der privaten Datei hinzugefügt. 
 
<hr>
=== Troubleshooting ===

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! 
: Schonmal auf den Server (mit gleicher IP) zugegriffen ? 
: (Schlüssel hat sich geändert) 

> ssh-keygen -R hostname
/home/tux/.ssh/known_hosts updated.
Original contents retained as /home/tux/.ssh/known_hosts.old

Falls es nicht geht: 
: Inhalt von ~/.ssh/known_hosts komplett löschen oder entsprechend editieren! 

Wenn weiter unten die Zeile kommt: 
'DSA host key for 141.44.198.20 has changed and you have requested strict checking.' 
: versuche es mit Änderung in: 
/etc/ssh/sshd_config 
StrictHostKeyChecking: yes/no/ask (def: ask) 

=== Immer noch Probleme? ===

Ist der ssh-Zugriff überhaupt möglich? 
: Ein beliebtes Problem ist '... key_exchange ... connection closed by foreign host'. 
: Das liegt dann meist daran, daß die Reverse-Auflösung der eigenen IP-Adresse nicht 
: mit dem Namen für den eigenen Host übereinstimmt. 
: Auf der anderen Seite in /etc/hosts.deny die ALL: PARANOID Zeile auskommentieren. 
: Oder DNS in Ordnung bringen! 

Passwort wird verlangt. 
: Meistens ein Problem der Permissions auf der eigenen und/oder der anderen Seite: 
: Das Verzeichnis .ssh/ und die die Datei .ssh/authorized_keys darf nur für den Eigentümer, 
: der auch der "angepeilte" Nutzer sein muß, schreibbar sein! 
: ssh -v ... hilft, diese Art von Problemen zu diagnostizieren.

Die SSH2 verlangt die Keys in ~/.ssh/authorized_keys2. 
: Die SSH2 auf Debian/GNU-Linux ist mögl. gepatcht und sucht die wie gehabt in: 
: ~/.ssh/authorized_keys, U.u. muß aber trotzdem auf SuSE-Systemen eben diese 2 angehängt werden. 

<hr>
:: Quellen:
::: [http://www.linux-praxis.de/lpic1/lpi102/1.113.7.html Einrichten von Secure Shell (OpenSSH) - LPI-Study Guides]
::: [http://de.linwiki.org/index.php/Linuxfibel_-_Netzwerk_Server_-_Telnet_%26_Co. Thomas Ermer / Michael Meyer: Linuxfibel - Netzwerk Server - Telnet & Co.]
::: [http://www.schlittermann.de/ssh Heiko Schlittermann: SSH ohne Passwort -- eine kurze Anleitung]
::: [http://www.lrz-muenchen.de/services/security/ssh/ssh-4.html Ernst Bötsch: Secure Shell (SSH) für Benutzer]
::: [http://www.jfranken.de/homepages/johannes/vortraege/ssh1_inhalt.de.html Johannes Franken: OpenSSH Grundlagen]

Linupedia.org:Hilfe/SSH Konfiguration

2007-10-22T09:32:25Z

OsunSeyi:

Ich bitte um entschuldiung,
die hier vorher vorhandene Seite wurde von mir versehentlich geschreddert.
OsunSeyi

Linupedia.org:Hilfe/SSH Konfiguration

2007-10-22T09:31:47Z

OsunSeyi:

Ich bitte um entschuldiung,
die hier vorher vorhandene Seite wurde von mir versehentlich geschreddert.

SSH Konfiguration

2007-10-22T09:23:34Z

OsunSeyi: hat LinuxClub:Hilfe/SSH Konfiguration nach SSH Konfiguration verschoben

== SSH KONFIGURATION ==

=== Wie funktioniert SSH? ===

1.
: Auf dem Server-Rechner (remote) wird ein Host-Key-Paar (RSA) generiert. 
: - ein Verschlüsselungscode (public_key) 
: - ein Entschlüsselungscode (private_key) 
: Der 'public_key' (öffentlich pubizierter Schlüssel) dient als Erkennung 
: für die Klients. 
: Zusätzlich erzeugt der laufende Server-Prozeß ein Server-Key-Paar, daß nur im 
: Memory des Remote-Rechners gehalten und periodisch erneuert wird. Es dient der 
: Verschlüsselung. 

2.
: Der lokale SSH-Client wendet sich an den SSH-Server auf dem Remote-Rechner, 
: um eine Verbindung aufzunehmen. 
: Der Server schickt dem Client daraufhin sowohl seinen 'public_key' als auch den 
: periodisch erzeugten öffentlichen Serverschlüssel. 

3.
: Der Klient überprüft nun den erhaltenen 'public key' mit der Liste in 'known_hosts'. 
: Normalerweise wird er sofort nach seinem Passwort gefragt. 

4.
: Existiert aber in 'known_hosts' noch kein zugehöriger Eintrag, so wird dieser hinzu- 
: gefügt. Dies erfordert eine ausdrücklicher Bestätigung durch den Benutzer. 
: Also wird der 'public_key' nur bei der ersten Kontaktaufname übermittelt, danach ist 
: er bekannt. 
: Ändert er sich, wird der Klient die Kontaktaufname verweigern und wieder neu nachfragen. 

5.
: Ab dann erzeugt der Client eine Zufallszahl und verschlüsselt diese unter Zuhilfename 
: der beiden übergebenen öffentlichen Schlüssel (Hostkey und Serverkey). 
: Diese Zufallszahl dient im weiteren Verlauf als der aktuelle Sitzungsschlüssel. 

6.
: Nun erst übergibt der Client Userid und Passwort und der Server startet eine Login-Shell 
: bzw. führt das gewünschte Kommando aus. 

Bei der Authentifizierung des Clients werden der Reihe nach verschiedene Verfahren ausprobiert. 
Dabei wird der Client als berechtigt betrachtet, sobald das erste Verfahren folgender Liste 
erfolgreich war: 

1.
: Autentifikation entsprechend den r-Kommandos; 
: Unsicher und per Default deaktiviert. 

2.
: Wie Punkt1; zusätzliche RSA-Authentifikation. 

3.
: RSA-Authentifikation; dazu ist auf dem Remote-Rechner ein Eintrag in 
: ~/.ssh/authorized_keys erforderlich. 

4.
: Durch Paßwort-Abfrage. 
 
<hr>
=== Dateien Serverseitig ===

* /etc/ssh/sshd_config 
: Der SSHD wird über diese Datei konfiguriert. 
: Meist sind fast alle Zeilen auskommentiert, 
: dies sollte die praktischen Bedürfnisse auch abdecken. 
: Konfiguration 

* /etc/hosts.allow & deny 
: In aktuellen Implementierungen des Ssh-Daemons ist die Auswertung der Dateien 
: /etc/hosts.allow und /etc/hosts.deny zumeist fest verdrahtet: 

tux> strings /usr/sbin/sshd | egrep 'hosts.allow|hosts.deny'
hosts_allow_table
hosts_deny_table
/etc/hosts.allow
/etc/hosts.deny

# Zugang zur Secure Shell (hosts.allow)
sshd: LOCAL 
# oder genauer:
sshd: 192...(Klient-DNS)/255.255.255.0 *.Domäne: ALLOW 
# Alles pauschal verbieten (hosts.deny)
ALL: ALL

* /etc/nologin
: Wenn sie existiert, verweigert sshd jeden Einlogvorgang außer dem von root 
: (sofern root-Eingänge in der Konfigurationsdatei erlaubt waren). 
: Der Inhalt der Datei wird dem Client übermittelt. 

=== Dateien Clientseitig ===

* /etc/ssh/ssh_known_hosts & ~/.ssh/known_hosts 
: enthalten die Public-Keys aller bekannten Rechner. 
: Die globale Datei wird vom Systemverwalter administriert, 
: die userbezogene wird automatisch angelegt und erweitert. 
: enthält die folgenden Felder: 
: Hostnamen Bits Exponent Modulus Kommentar 
: Hostnamen ist eine durch Kommas getrennte Liste von Namen 
: (* und ? dürfen benutzt werden). 
: Wird mit dem vollständigen Hostnamen des Rechners verglichen, der sich anmelden will. 
: Bits, Exponent und Modulus werden direkt den Host-Schlüsseln entnommen, 
: die in den Dateien /etc/ssh/ssh_host_*_key.pub gespeichert sind. 
: Das optionale Kommentarfeld wird nicht ausgewertet. 

* /etc/ssh/ssh.config 
: Client-Einstellungen. 
 
<hr>
=== Schlüssel - passwortfreie Anmeldung ===

Der Befehl 'ssh-keygen' erzeugt und verwaltet die Schlüssel für SSH-Verbindungen. 
Normaluser können sich damit einen Schlüssel erzeugen, der Systemverwalter kann auch den
Host-Schlüssel damit anlegen. 
Diese Schlüssel sind nicht zwingend für den Gebrauch von SSH erforderlich, bestimmte Server
verlangen ihn aber. 
Es stehen zwei Schlüsseltypen ('RSA' und 'DSA') zur Verfügung, erforderlich ist aber nur
einer von beiden. 
Man wird bei der Erstellung nach einem Passwort gefragt, muß aber keines angeben. 
Es ist also möglich, über diese Schlüsselpaare eine Authentifizierung ohne Passwort zu steuern. 

> ssh-keygen -t rsa
Password:
...
Generating public/private rsa key pair.
... in ~/.ssh/id_dra.pub 
> ssh-keygen -t dsa
Password:
...
Generating public/private dsa key pair.
... in ~/.ssh/id_dsa.pub

Der Inhalt mindestens einer der beiden Dateien 'id_rsa.pub' und 'id_dsa.pub' müssen auf dem
Remote-Rechner in die Datei $HOME/.ssh/authorized_keys eingetragen werden. Verzeichnis als
auch die Datei dürfen nur für den User lesbar und schreibbar sein. 
Die geht manuell oder mit: 

> ssh-copy-id -i /home/tux/.ssh/id_rsa.pub 192...(Server-DNS)
password:
...

In der Serverkonfiguration kann die Passwort-Authentifikation ausgeschaltet werden: 

/etc/ssh/sshd_config: 
# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no

Und gegebenenfalls: 

/etc/ssh/sshd_config: 
- PermitRootLogin yes/no

Der Server muß neu gestartet werden: 

> /etc/init.d/ssh restart
 
<hr>
=== Die Datei /etc/ssh/sshd_config: ===

* BatchMode yes/no 
: Die Abfrage nach dem Passwort oder der Passphrase wird unterbunden, 
: somit lassen sich z.B. Kommandos in Shellscripts ausführen. 
* Compression yes/no 
: Schaltet die Komprimierung der zu übertragenden Daten ein oder aus. 
* FallBackToRsh yes/no 
: Scheitert der Verbindungsaufbau zum Server (zB. weil dieser nicht aktiv ist), 
: kann eine Verbindung über rsh versucht werden. Default: 'no' 
* HostKey Dateiname 
: Spezifiziert die Datei, in der der Host-Schlüssel des Servers abgelegt ist. 
: Normalerweise ist das die Datei /etc/ssh/ssh_host_key. 
: Diese Datei darf nicht für alle Welt lesbar sein, 
: ansonsten verweigert sich sshd die Datei zu verwenden! 
* IgnoreRhosts yes/no 
: Sollen die Dateien ~/.rhosts und ~/.shosts ignoriert werden? 
* KeyRegenerationInterval Zeit 
: Die Anzahl der Sekunden, nach denen der Server-Schlüssel neu erstellt werden soll. 
: Standardmäßig sollte hier 3600 (eine Stunde) stehen. 
: Steht hier eine 0, so wird der Schlüssel niemals neu erstellt. 
* PermitRootLogin yes/no 
: Erlaubt, daß sich der Systemverwalter über ssh einloggen kann. 
* PasswordAuthentication yes/no 
: Soll eine Abfrage des Passwortes durchgeführt werden? 
: Steht der Wert auf »no«, ist ein Anmelden auf einem entfernten Rechner nur möglich, 
: wenn der eigene öffentliche Schlüssel dort bekannt ist. 
* Port n 
: Die Angabe auf welchem Port sshd laufen soll. Normalerweise ist es Port 22. 
* RhostsAuthentication yes/no 
: Ob bei der Authentifizierung die Dateien rhosts und /etc/hosts.equiv ausreichen, 
: soll auf »no« bleiben. 
* RhostsRSAAuthentication yes/no 
: Erlaubt die Benutzung von rhosts und /etc/hosts.equiv, 
: allerdings nur wenn die RSA-HOST-Authentifizierung erfolgreich war. 
: Default »yes«. 
* RSAAuthentication yes/no 
: Authentifizierung mittels RSA-Verschlüsselung. 
: Steht der Wert auf »yes«, sollte die Datei »~/.ssh/identity« 
: oder ein Authentifizierungsagent existieren. 
* StrictHostKeyChecking yes/no 
: Ein »yes« verschärft die Sicherheit, indem das Anmelden nur auf Rechnern gestattet wird, 
: die in den Datenbanken »/etc/known_hosts« bzw. »~/.ssh/known_hosts« enthalten sind. 
: Steht hier »no« werden neu besuchte Rechner automatisch der privaten Datei hinzugefügt. 
 
<hr>
=== Troubleshooting ===

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! 
: Schonmal auf den Server (mit gleicher IP) zugegriffen ? 
: (Schlüssel hat sich geändert) 

> ssh-keygen -R hostname
/home/tux/.ssh/known_hosts updated.
Original contents retained as /home/tux/.ssh/known_hosts.old

Falls es nicht geht: 
: Inhalt von ~/.ssh/known_hosts komplett löschen oder entsprechend editieren! 

Wenn weiter unten die Zeile kommt: 
'DSA host key for 141.44.198.20 has changed and you have requested strict checking.' 
: versuche es mit Änderung in: 
/etc/ssh/sshd_config 
StrictHostKeyChecking: yes/no/ask (def: ask) 

=== Immer noch Probleme? ===

Ist der ssh-Zugriff überhaupt möglich? 
: Ein beliebtes Problem ist '... key_exchange ... connection closed by foreign host'. 
: Das liegt dann meist daran, daß die Reverse-Auflösung der eigenen IP-Adresse nicht 
: mit dem Namen für den eigenen Host übereinstimmt. 
: Auf der anderen Seite in /etc/hosts.deny die ALL: PARANOID Zeile auskommentieren. 
: Oder DNS in Ordnung bringen! 

Passwort wird verlangt. 
: Meistens ein Problem der Permissions auf der eigenen und/oder der anderen Seite: 
: Das Verzeichnis .ssh/ und die die Datei .ssh/authorized_keys darf nur für den Eigentümer, 
: der auch der "angepeilte" Nutzer sein muß, schreibbar sein! 
: ssh -v ... hilft, diese Art von Problemen zu diagnostizieren.

Die SSH2 verlangt die Keys in ~/.ssh/authorized_keys2. 
: Die SSH2 auf Debian/GNU-Linux ist mögl. gepatcht und sucht die wie gehabt in: 
: ~/.ssh/authorized_keys, U.u. muß aber trotzdem auf SuSE-Systemen eben diese 2 angehängt werden. 

<hr>
:: Quellen:
::: [http://www.linux-praxis.de/lpic1/lpi102/1.113.7.html Einrichten von Secure Shell (OpenSSH) - LPI-Study Guides]
::: [http://de.linwiki.org/index.php/Linuxfibel_-_Netzwerk_Server_-_Telnet_%26_Co. Thomas Ermer / Michael Meyer: Linuxfibel - Netzwerk Server - Telnet & Co.]
::: [http://www.schlittermann.de/ssh Heiko Schlittermann: SSH ohne Passwort -- eine kurze Anleitung]
::: [http://www.lrz-muenchen.de/services/security/ssh/ssh-4.html Ernst Bötsch: Secure Shell (SSH) für Benutzer]
::: [http://www.jfranken.de/homepages/johannes/vortraege/ssh1_inhalt.de.html Johannes Franken: OpenSSH Grundlagen]

Linupedia.org:Hilfe/SSH Konfiguration

2007-10-22T09:23:34Z

OsunSeyi: hat LinuxClub:Hilfe/SSH Konfiguration nach SSH Konfiguration verschoben

#REDIRECT [[SSH Konfiguration]]

SSH Konfiguration

2007-10-22T09:22:06Z

OsunSeyi: hat LinuxClub:Hilfe/Schnelleinstieg nach LinuxClub:Hilfe/SSH Konfiguration verschoben

== SSH KONFIGURATION ==

=== Wie funktioniert SSH? ===

1.
: Auf dem Server-Rechner (remote) wird ein Host-Key-Paar (RSA) generiert. 
: - ein Verschlüsselungscode (public_key) 
: - ein Entschlüsselungscode (private_key) 
: Der 'public_key' (öffentlich pubizierter Schlüssel) dient als Erkennung 
: für die Klients. 
: Zusätzlich erzeugt der laufende Server-Prozeß ein Server-Key-Paar, daß nur im 
: Memory des Remote-Rechners gehalten und periodisch erneuert wird. Es dient der 
: Verschlüsselung. 

2.
: Der lokale SSH-Client wendet sich an den SSH-Server auf dem Remote-Rechner, 
: um eine Verbindung aufzunehmen. 
: Der Server schickt dem Client daraufhin sowohl seinen 'public_key' als auch den 
: periodisch erzeugten öffentlichen Serverschlüssel. 

3.
: Der Klient überprüft nun den erhaltenen 'public key' mit der Liste in 'known_hosts'. 
: Normalerweise wird er sofort nach seinem Passwort gefragt. 

4.
: Existiert aber in 'known_hosts' noch kein zugehöriger Eintrag, so wird dieser hinzu- 
: gefügt. Dies erfordert eine ausdrücklicher Bestätigung durch den Benutzer. 
: Also wird der 'public_key' nur bei der ersten Kontaktaufname übermittelt, danach ist 
: er bekannt. 
: Ändert er sich, wird der Klient die Kontaktaufname verweigern und wieder neu nachfragen. 

5.
: Ab dann erzeugt der Client eine Zufallszahl und verschlüsselt diese unter Zuhilfename 
: der beiden übergebenen öffentlichen Schlüssel (Hostkey und Serverkey). 
: Diese Zufallszahl dient im weiteren Verlauf als der aktuelle Sitzungsschlüssel. 

6.
: Nun erst übergibt der Client Userid und Passwort und der Server startet eine Login-Shell 
: bzw. führt das gewünschte Kommando aus. 

Bei der Authentifizierung des Clients werden der Reihe nach verschiedene Verfahren ausprobiert. 
Dabei wird der Client als berechtigt betrachtet, sobald das erste Verfahren folgender Liste 
erfolgreich war: 

1.
: Autentifikation entsprechend den r-Kommandos; 
: Unsicher und per Default deaktiviert. 

2.
: Wie Punkt1; zusätzliche RSA-Authentifikation. 

3.
: RSA-Authentifikation; dazu ist auf dem Remote-Rechner ein Eintrag in 
: ~/.ssh/authorized_keys erforderlich. 

4.
: Durch Paßwort-Abfrage. 
 
<hr>
=== Dateien Serverseitig ===

* /etc/ssh/sshd_config 
: Der SSHD wird über diese Datei konfiguriert. 
: Meist sind fast alle Zeilen auskommentiert, 
: dies sollte die praktischen Bedürfnisse auch abdecken. 
: Konfiguration 

* /etc/hosts.allow & deny 
: In aktuellen Implementierungen des Ssh-Daemons ist die Auswertung der Dateien 
: /etc/hosts.allow und /etc/hosts.deny zumeist fest verdrahtet: 

tux> strings /usr/sbin/sshd | egrep 'hosts.allow|hosts.deny'
hosts_allow_table
hosts_deny_table
/etc/hosts.allow
/etc/hosts.deny

# Zugang zur Secure Shell (hosts.allow)
sshd: LOCAL 
# oder genauer:
sshd: 192...(Klient-DNS)/255.255.255.0 *.Domäne: ALLOW 
# Alles pauschal verbieten (hosts.deny)
ALL: ALL

* /etc/nologin
: Wenn sie existiert, verweigert sshd jeden Einlogvorgang außer dem von root 
: (sofern root-Eingänge in der Konfigurationsdatei erlaubt waren). 
: Der Inhalt der Datei wird dem Client übermittelt. 

=== Dateien Clientseitig ===

* /etc/ssh/ssh_known_hosts & ~/.ssh/known_hosts 
: enthalten die Public-Keys aller bekannten Rechner. 
: Die globale Datei wird vom Systemverwalter administriert, 
: die userbezogene wird automatisch angelegt und erweitert. 
: enthält die folgenden Felder: 
: Hostnamen Bits Exponent Modulus Kommentar 
: Hostnamen ist eine durch Kommas getrennte Liste von Namen 
: (* und ? dürfen benutzt werden). 
: Wird mit dem vollständigen Hostnamen des Rechners verglichen, der sich anmelden will. 
: Bits, Exponent und Modulus werden direkt den Host-Schlüsseln entnommen, 
: die in den Dateien /etc/ssh/ssh_host_*_key.pub gespeichert sind. 
: Das optionale Kommentarfeld wird nicht ausgewertet. 

* /etc/ssh/ssh.config 
: Client-Einstellungen. 
 
<hr>
=== Schlüssel - passwortfreie Anmeldung ===

Der Befehl 'ssh-keygen' erzeugt und verwaltet die Schlüssel für SSH-Verbindungen. 
Normaluser können sich damit einen Schlüssel erzeugen, der Systemverwalter kann auch den
Host-Schlüssel damit anlegen. 
Diese Schlüssel sind nicht zwingend für den Gebrauch von SSH erforderlich, bestimmte Server
verlangen ihn aber. 
Es stehen zwei Schlüsseltypen ('RSA' und 'DSA') zur Verfügung, erforderlich ist aber nur
einer von beiden. 
Man wird bei der Erstellung nach einem Passwort gefragt, muß aber keines angeben. 
Es ist also möglich, über diese Schlüsselpaare eine Authentifizierung ohne Passwort zu steuern. 

> ssh-keygen -t rsa
Password:
...
Generating public/private rsa key pair.
... in ~/.ssh/id_dra.pub 
> ssh-keygen -t dsa
Password:
...
Generating public/private dsa key pair.
... in ~/.ssh/id_dsa.pub

Der Inhalt mindestens einer der beiden Dateien 'id_rsa.pub' und 'id_dsa.pub' müssen auf dem
Remote-Rechner in die Datei $HOME/.ssh/authorized_keys eingetragen werden. Verzeichnis als
auch die Datei dürfen nur für den User lesbar und schreibbar sein. 
Die geht manuell oder mit: 

> ssh-copy-id -i /home/tux/.ssh/id_rsa.pub 192...(Server-DNS)
password:
...

In der Serverkonfiguration kann die Passwort-Authentifikation ausgeschaltet werden: 

/etc/ssh/sshd_config: 
# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no

Und gegebenenfalls: 

/etc/ssh/sshd_config: 
- PermitRootLogin yes/no

Der Server muß neu gestartet werden: 

> /etc/init.d/ssh restart
 
<hr>
=== Die Datei /etc/ssh/sshd_config: ===

* BatchMode yes/no 
: Die Abfrage nach dem Passwort oder der Passphrase wird unterbunden, 
: somit lassen sich z.B. Kommandos in Shellscripts ausführen. 
* Compression yes/no 
: Schaltet die Komprimierung der zu übertragenden Daten ein oder aus. 
* FallBackToRsh yes/no 
: Scheitert der Verbindungsaufbau zum Server (zB. weil dieser nicht aktiv ist), 
: kann eine Verbindung über rsh versucht werden. Default: 'no' 
* HostKey Dateiname 
: Spezifiziert die Datei, in der der Host-Schlüssel des Servers abgelegt ist. 
: Normalerweise ist das die Datei /etc/ssh/ssh_host_key. 
: Diese Datei darf nicht für alle Welt lesbar sein, 
: ansonsten verweigert sich sshd die Datei zu verwenden! 
* IgnoreRhosts yes/no 
: Sollen die Dateien ~/.rhosts und ~/.shosts ignoriert werden? 
* KeyRegenerationInterval Zeit 
: Die Anzahl der Sekunden, nach denen der Server-Schlüssel neu erstellt werden soll. 
: Standardmäßig sollte hier 3600 (eine Stunde) stehen. 
: Steht hier eine 0, so wird der Schlüssel niemals neu erstellt. 
* PermitRootLogin yes/no 
: Erlaubt, daß sich der Systemverwalter über ssh einloggen kann. 
* PasswordAuthentication yes/no 
: Soll eine Abfrage des Passwortes durchgeführt werden? 
: Steht der Wert auf »no«, ist ein Anmelden auf einem entfernten Rechner nur möglich, 
: wenn der eigene öffentliche Schlüssel dort bekannt ist. 
* Port n 
: Die Angabe auf welchem Port sshd laufen soll. Normalerweise ist es Port 22. 
* RhostsAuthentication yes/no 
: Ob bei der Authentifizierung die Dateien rhosts und /etc/hosts.equiv ausreichen, 
: soll auf »no« bleiben. 
* RhostsRSAAuthentication yes/no 
: Erlaubt die Benutzung von rhosts und /etc/hosts.equiv, 
: allerdings nur wenn die RSA-HOST-Authentifizierung erfolgreich war. 
: Default »yes«. 
* RSAAuthentication yes/no 
: Authentifizierung mittels RSA-Verschlüsselung. 
: Steht der Wert auf »yes«, sollte die Datei »~/.ssh/identity« 
: oder ein Authentifizierungsagent existieren. 
* StrictHostKeyChecking yes/no 
: Ein »yes« verschärft die Sicherheit, indem das Anmelden nur auf Rechnern gestattet wird, 
: die in den Datenbanken »/etc/known_hosts« bzw. »~/.ssh/known_hosts« enthalten sind. 
: Steht hier »no« werden neu besuchte Rechner automatisch der privaten Datei hinzugefügt. 
 
<hr>
=== Troubleshooting ===

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! 
: Schonmal auf den Server (mit gleicher IP) zugegriffen ? 
: (Schlüssel hat sich geändert) 

> ssh-keygen -R hostname
/home/tux/.ssh/known_hosts updated.
Original contents retained as /home/tux/.ssh/known_hosts.old

Falls es nicht geht: 
: Inhalt von ~/.ssh/known_hosts komplett löschen oder entsprechend editieren! 

Wenn weiter unten die Zeile kommt: 
'DSA host key for 141.44.198.20 has changed and you have requested strict checking.' 
: versuche es mit Änderung in: 
/etc/ssh/sshd_config 
StrictHostKeyChecking: yes/no/ask (def: ask) 

=== Immer noch Probleme? ===

Ist der ssh-Zugriff überhaupt möglich? 
: Ein beliebtes Problem ist '... key_exchange ... connection closed by foreign host'. 
: Das liegt dann meist daran, daß die Reverse-Auflösung der eigenen IP-Adresse nicht 
: mit dem Namen für den eigenen Host übereinstimmt. 
: Auf der anderen Seite in /etc/hosts.deny die ALL: PARANOID Zeile auskommentieren. 
: Oder DNS in Ordnung bringen! 

Passwort wird verlangt. 
: Meistens ein Problem der Permissions auf der eigenen und/oder der anderen Seite: 
: Das Verzeichnis .ssh/ und die die Datei .ssh/authorized_keys darf nur für den Eigentümer, 
: der auch der "angepeilte" Nutzer sein muß, schreibbar sein! 
: ssh -v ... hilft, diese Art von Problemen zu diagnostizieren.

Die SSH2 verlangt die Keys in ~/.ssh/authorized_keys2. 
: Die SSH2 auf Debian/GNU-Linux ist mögl. gepatcht und sucht die wie gehabt in: 
: ~/.ssh/authorized_keys, U.u. muß aber trotzdem auf SuSE-Systemen eben diese 2 angehängt werden. 

<hr>
:: Quellen:
::: [http://www.linux-praxis.de/lpic1/lpi102/1.113.7.html Einrichten von Secure Shell (OpenSSH) - LPI-Study Guides]
::: [http://de.linwiki.org/index.php/Linuxfibel_-_Netzwerk_Server_-_Telnet_%26_Co. Thomas Ermer / Michael Meyer: Linuxfibel - Netzwerk Server - Telnet & Co.]
::: [http://www.schlittermann.de/ssh Heiko Schlittermann: SSH ohne Passwort -- eine kurze Anleitung]
::: [http://www.lrz-muenchen.de/services/security/ssh/ssh-4.html Ernst Bötsch: Secure Shell (SSH) für Benutzer]
::: [http://www.jfranken.de/homepages/johannes/vortraege/ssh1_inhalt.de.html Johannes Franken: OpenSSH Grundlagen]

SSH Konfiguration

2007-10-22T09:16:17Z

OsunSeyi:

== SSH KONFIGURATION ==

=== Wie funktioniert SSH? ===

1.
: Auf dem Server-Rechner (remote) wird ein Host-Key-Paar (RSA) generiert. 
: - ein Verschlüsselungscode (public_key) 
: - ein Entschlüsselungscode (private_key) 
: Der 'public_key' (öffentlich pubizierter Schlüssel) dient als Erkennung 
: für die Klients. 
: Zusätzlich erzeugt der laufende Server-Prozeß ein Server-Key-Paar, daß nur im 
: Memory des Remote-Rechners gehalten und periodisch erneuert wird. Es dient der 
: Verschlüsselung. 

2.
: Der lokale SSH-Client wendet sich an den SSH-Server auf dem Remote-Rechner, 
: um eine Verbindung aufzunehmen. 
: Der Server schickt dem Client daraufhin sowohl seinen 'public_key' als auch den 
: periodisch erzeugten öffentlichen Serverschlüssel. 

3.
: Der Klient überprüft nun den erhaltenen 'public key' mit der Liste in 'known_hosts'. 
: Normalerweise wird er sofort nach seinem Passwort gefragt. 

4.
: Existiert aber in 'known_hosts' noch kein zugehöriger Eintrag, so wird dieser hinzu- 
: gefügt. Dies erfordert eine ausdrücklicher Bestätigung durch den Benutzer. 
: Also wird der 'public_key' nur bei der ersten Kontaktaufname übermittelt, danach ist 
: er bekannt. 
: Ändert er sich, wird der Klient die Kontaktaufname verweigern und wieder neu nachfragen. 

5.
: Ab dann erzeugt der Client eine Zufallszahl und verschlüsselt diese unter Zuhilfename 
: der beiden übergebenen öffentlichen Schlüssel (Hostkey und Serverkey). 
: Diese Zufallszahl dient im weiteren Verlauf als der aktuelle Sitzungsschlüssel. 

6.
: Nun erst übergibt der Client Userid und Passwort und der Server startet eine Login-Shell 
: bzw. führt das gewünschte Kommando aus. 

Bei der Authentifizierung des Clients werden der Reihe nach verschiedene Verfahren ausprobiert. 
Dabei wird der Client als berechtigt betrachtet, sobald das erste Verfahren folgender Liste 
erfolgreich war: 

1.
: Autentifikation entsprechend den r-Kommandos; 
: Unsicher und per Default deaktiviert. 

2.
: Wie Punkt1; zusätzliche RSA-Authentifikation. 

3.
: RSA-Authentifikation; dazu ist auf dem Remote-Rechner ein Eintrag in 
: ~/.ssh/authorized_keys erforderlich. 

4.
: Durch Paßwort-Abfrage. 
 
<hr>
=== Dateien Serverseitig ===

* /etc/ssh/sshd_config 
: Der SSHD wird über diese Datei konfiguriert. 
: Meist sind fast alle Zeilen auskommentiert, 
: dies sollte die praktischen Bedürfnisse auch abdecken. 
: Konfiguration 

* /etc/hosts.allow & deny 
: In aktuellen Implementierungen des Ssh-Daemons ist die Auswertung der Dateien 
: /etc/hosts.allow und /etc/hosts.deny zumeist fest verdrahtet: 

tux> strings /usr/sbin/sshd | egrep 'hosts.allow|hosts.deny'
hosts_allow_table
hosts_deny_table
/etc/hosts.allow
/etc/hosts.deny

# Zugang zur Secure Shell (hosts.allow)
sshd: LOCAL 
# oder genauer:
sshd: 192...(Klient-DNS)/255.255.255.0 *.Domäne: ALLOW 
# Alles pauschal verbieten (hosts.deny)
ALL: ALL

* /etc/nologin
: Wenn sie existiert, verweigert sshd jeden Einlogvorgang außer dem von root 
: (sofern root-Eingänge in der Konfigurationsdatei erlaubt waren). 
: Der Inhalt der Datei wird dem Client übermittelt. 

=== Dateien Clientseitig ===

* /etc/ssh/ssh_known_hosts & ~/.ssh/known_hosts 
: enthalten die Public-Keys aller bekannten Rechner. 
: Die globale Datei wird vom Systemverwalter administriert, 
: die userbezogene wird automatisch angelegt und erweitert. 
: enthält die folgenden Felder: 
: Hostnamen Bits Exponent Modulus Kommentar 
: Hostnamen ist eine durch Kommas getrennte Liste von Namen 
: (* und ? dürfen benutzt werden). 
: Wird mit dem vollständigen Hostnamen des Rechners verglichen, der sich anmelden will. 
: Bits, Exponent und Modulus werden direkt den Host-Schlüsseln entnommen, 
: die in den Dateien /etc/ssh/ssh_host_*_key.pub gespeichert sind. 
: Das optionale Kommentarfeld wird nicht ausgewertet. 

* /etc/ssh/ssh.config 
: Client-Einstellungen. 
 
<hr>
=== Schlüssel - passwortfreie Anmeldung ===

Der Befehl 'ssh-keygen' erzeugt und verwaltet die Schlüssel für SSH-Verbindungen. 
Normaluser können sich damit einen Schlüssel erzeugen, der Systemverwalter kann auch den
Host-Schlüssel damit anlegen. 
Diese Schlüssel sind nicht zwingend für den Gebrauch von SSH erforderlich, bestimmte Server
verlangen ihn aber. 
Es stehen zwei Schlüsseltypen ('RSA' und 'DSA') zur Verfügung, erforderlich ist aber nur
einer von beiden. 
Man wird bei der Erstellung nach einem Passwort gefragt, muß aber keines angeben. 
Es ist also möglich, über diese Schlüsselpaare eine Authentifizierung ohne Passwort zu steuern. 

> ssh-keygen -t rsa
Password:
...
Generating public/private rsa key pair.
... in ~/.ssh/id_dra.pub 
> ssh-keygen -t dsa
Password:
...
Generating public/private dsa key pair.
... in ~/.ssh/id_dsa.pub

Der Inhalt mindestens einer der beiden Dateien 'id_rsa.pub' und 'id_dsa.pub' müssen auf dem
Remote-Rechner in die Datei $HOME/.ssh/authorized_keys eingetragen werden. Verzeichnis als
auch die Datei dürfen nur für den User lesbar und schreibbar sein. 
Die geht manuell oder mit: 

> ssh-copy-id -i /home/tux/.ssh/id_rsa.pub 192...(Server-DNS)
password:
...

In der Serverkonfiguration kann die Passwort-Authentifikation ausgeschaltet werden: 

/etc/ssh/sshd_config: 
# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no

Und gegebenenfalls: 

/etc/ssh/sshd_config: 
- PermitRootLogin yes/no

Der Server muß neu gestartet werden: 

> /etc/init.d/ssh restart
 
<hr>
=== Die Datei /etc/ssh/sshd_config: ===

* BatchMode yes/no 
: Die Abfrage nach dem Passwort oder der Passphrase wird unterbunden, 
: somit lassen sich z.B. Kommandos in Shellscripts ausführen. 
* Compression yes/no 
: Schaltet die Komprimierung der zu übertragenden Daten ein oder aus. 
* FallBackToRsh yes/no 
: Scheitert der Verbindungsaufbau zum Server (zB. weil dieser nicht aktiv ist), 
: kann eine Verbindung über rsh versucht werden. Default: 'no' 
* HostKey Dateiname 
: Spezifiziert die Datei, in der der Host-Schlüssel des Servers abgelegt ist. 
: Normalerweise ist das die Datei /etc/ssh/ssh_host_key. 
: Diese Datei darf nicht für alle Welt lesbar sein, 
: ansonsten verweigert sich sshd die Datei zu verwenden! 
* IgnoreRhosts yes/no 
: Sollen die Dateien ~/.rhosts und ~/.shosts ignoriert werden? 
* KeyRegenerationInterval Zeit 
: Die Anzahl der Sekunden, nach denen der Server-Schlüssel neu erstellt werden soll. 
: Standardmäßig sollte hier 3600 (eine Stunde) stehen. 
: Steht hier eine 0, so wird der Schlüssel niemals neu erstellt. 
* PermitRootLogin yes/no 
: Erlaubt, daß sich der Systemverwalter über ssh einloggen kann. 
* PasswordAuthentication yes/no 
: Soll eine Abfrage des Passwortes durchgeführt werden? 
: Steht der Wert auf »no«, ist ein Anmelden auf einem entfernten Rechner nur möglich, 
: wenn der eigene öffentliche Schlüssel dort bekannt ist. 
* Port n 
: Die Angabe auf welchem Port sshd laufen soll. Normalerweise ist es Port 22. 
* RhostsAuthentication yes/no 
: Ob bei der Authentifizierung die Dateien rhosts und /etc/hosts.equiv ausreichen, 
: soll auf »no« bleiben. 
* RhostsRSAAuthentication yes/no 
: Erlaubt die Benutzung von rhosts und /etc/hosts.equiv, 
: allerdings nur wenn die RSA-HOST-Authentifizierung erfolgreich war. 
: Default »yes«. 
* RSAAuthentication yes/no 
: Authentifizierung mittels RSA-Verschlüsselung. 
: Steht der Wert auf »yes«, sollte die Datei »~/.ssh/identity« 
: oder ein Authentifizierungsagent existieren. 
* StrictHostKeyChecking yes/no 
: Ein »yes« verschärft die Sicherheit, indem das Anmelden nur auf Rechnern gestattet wird, 
: die in den Datenbanken »/etc/known_hosts« bzw. »~/.ssh/known_hosts« enthalten sind. 
: Steht hier »no« werden neu besuchte Rechner automatisch der privaten Datei hinzugefügt. 
 
<hr>
=== Troubleshooting ===

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! 
: Schonmal auf den Server (mit gleicher IP) zugegriffen ? 
: (Schlüssel hat sich geändert) 

> ssh-keygen -R hostname
/home/tux/.ssh/known_hosts updated.
Original contents retained as /home/tux/.ssh/known_hosts.old

Falls es nicht geht: 
: Inhalt von ~/.ssh/known_hosts komplett löschen oder entsprechend editieren! 

Wenn weiter unten die Zeile kommt: 
'DSA host key for 141.44.198.20 has changed and you have requested strict checking.' 
: versuche es mit Änderung in: 
/etc/ssh/sshd_config 
StrictHostKeyChecking: yes/no/ask (def: ask) 

=== Immer noch Probleme? ===

Ist der ssh-Zugriff überhaupt möglich? 
: Ein beliebtes Problem ist '... key_exchange ... connection closed by foreign host'. 
: Das liegt dann meist daran, daß die Reverse-Auflösung der eigenen IP-Adresse nicht 
: mit dem Namen für den eigenen Host übereinstimmt. 
: Auf der anderen Seite in /etc/hosts.deny die ALL: PARANOID Zeile auskommentieren. 
: Oder DNS in Ordnung bringen! 

Passwort wird verlangt. 
: Meistens ein Problem der Permissions auf der eigenen und/oder der anderen Seite: 
: Das Verzeichnis .ssh/ und die die Datei .ssh/authorized_keys darf nur für den Eigentümer, 
: der auch der "angepeilte" Nutzer sein muß, schreibbar sein! 
: ssh -v ... hilft, diese Art von Problemen zu diagnostizieren.

Die SSH2 verlangt die Keys in ~/.ssh/authorized_keys2. 
: Die SSH2 auf Debian/GNU-Linux ist mögl. gepatcht und sucht die wie gehabt in: 
: ~/.ssh/authorized_keys, U.u. muß aber trotzdem auf SuSE-Systemen eben diese 2 angehängt werden. 

<hr>
:: Quellen:
::: [http://www.linux-praxis.de/lpic1/lpi102/1.113.7.html Einrichten von Secure Shell (OpenSSH) - LPI-Study Guides]
::: [http://de.linwiki.org/index.php/Linuxfibel_-_Netzwerk_Server_-_Telnet_%26_Co. Thomas Ermer / Michael Meyer: Linuxfibel - Netzwerk Server - Telnet & Co.]
::: [http://www.schlittermann.de/ssh Heiko Schlittermann: SSH ohne Passwort -- eine kurze Anleitung]
::: [http://www.lrz-muenchen.de/services/security/ssh/ssh-4.html Ernst Bötsch: Secure Shell (SSH) für Benutzer]
::: [http://www.jfranken.de/homepages/johannes/vortraege/ssh1_inhalt.de.html Johannes Franken: OpenSSH Grundlagen]

SSH Konfiguration

2007-10-22T07:02:21Z

OsunSeyi: Die Seite wurde neu angelegt: SSH KONFIGURATION - Konfigurationsdateien - Schlüsselerzeugung - passwortfreies Anmelden - Server-Konfiguration - Troubleshooting - Quellen<br...

SSH KONFIGURATION 

- Konfigurationsdateien 
- Schlüsselerzeugung - passwortfreies Anmelden 
- Server-Konfiguration 
- Troubleshooting 
- Quellen 

<hr>
Wie funktioniert SSH? 

1.
Auf dem Server-Rechner (remote) wird ein Host-Key-Paar (RSA) generiert. 
- ein Verschlüsselungscode (public_key) 
- ein Entschlüsselungscode (private_key). 
Der 'public_key' (öffentlich pubizierter Schlüssel) dient als Erkennung
für die Klients. 
Zusätzlich erzeugt der laufende Server-Prozeß ein Server-Key-Paar, daß nur im
Memory des Remote-Rechners gehalten und periodisch erneuert wird. Es dient der
Verschlüsselung. 

2. Der lokale SSH-Client wendet sich an den SSH-Server auf dem Remote-Rechner,
um eine Verbindung aufzunehmen. 
Der Server schickt dem Client daraufhin sowohl seinen 'public_key' als auch den
periodisch erzeugten öffentlichen Serverschlüssel. 

3. Der Klient überprüft nun den erhaltenen 'public key' mit der Liste in 'known_hosts'. 
Normalerweise wird er sofort nach seinem Passwort gefragt.

4. Existiert aber in 'known_hosts' noch kein zugehöriger Eintrag, so wird dieser hinzu-
gefügt. Dies erfordert eine ausdrücklicher Bestätigung durch den Benutzer. 
Also wird der 'public_key' nur bei der ersten Kontaktaufname übermittelt, danach ist
er bekannt. 
Ändert er sich, wird der Klient die Kontaktaufname verweigern und wieder neu nachfragen. 

4. Ab dann erzeugt der Client eine Zufallszahl und verschlüsselt diese unter Zuhilfename
der beiden übergebenen öffentlichen Schlüssel (Hostkey und Serverkey). 
Diese Zufallszahl dient im weiteren Verlauf als der aktuelle Sitzungsschlüssel. 

5. Nun erst übergibt der Client Userid und Passwort und der Server startet eine Login-Shell
bzw. führt das gewünschte Kommando aus. 

Bei der Authentifizierung des Clients werden der Reihe nach verschiedene Verfahren ausprobiert. 
Dabei wird der Client als berechtigt betrachtet, sobald das erste Verfahren folgender Liste
erfolgreich war: 

1. Autentifikation entsprechend den r-Kommandos; 
Unsicher und per Default deaktiviert. 

2. Wie Punkt1; zusätzliche RSA-Authentifikation. 

3. RSA-Authentifikation; dazu ist auf dem Remote-Rechner ein Eintrag in 
~/.ssh/authorized_keys erforderlich.

4. Durch Paßwort-Abfrage. 

Dateien Serverseitig: 

* /etc/ssh/sshd_config 
Der SSHD wird über diese Datei konfiguriert. 
Meist sind fast alle Zeilen auskommentiert,
dies sollte die praktischen Bedürfnisse auch abdecken. 
Konfiguration 

* /etc/hosts.allow & deny 
In aktuellen Implementierungen des Ssh-Daemons ist die Auswertung der Dateien
/etc/hosts.allow und /etc/hosts.deny zumeist fest verdrahtet: 

tux> strings /usr/sbin/sshd | egrep 'hosts.allow|hosts.deny'
hosts_allow_table
hosts_deny_table
/etc/hosts.allow
/etc/hosts.deny

# Zugang zur Secure Shell (hosts.allow)
sshd : LOCAL
# oder
sshd : 192...(Klient-DNS)/255.255.255.0 *.Domäne : ALLOW
# Alles pauschal verbieten (hosts.deny)
ALL : ALL

* /etc/nologin 
Wenn sie existiert, verweigert sshd jeden Einlogvorgang außer dem von root
(sofern root-Eingänge in der Konfigurationsdatei erlaubt waren). 
Der Inhalt der Datei wird dem Client übermittelt. 

<hr>
Dateien Clientseitig: 

* /etc/ssh/ssh_known_hosts & ~/.ssh/known_hosts 
enthalten die Public-Keys aller bekannten Rechner. 
Die globale Datei wird vom Systemverwalter administriert,
die userbezogene wird automatisch angelegt und erweitert. 
Enthält die folgenden Felder: 
Hostnamen Bits Exponent Modulus Kommentar 
Hostnamen ist eine durch Kommas getrennte Liste von Namen 
(* und ? dürfen benutzt werden).
Wird mit dem vollständigen Hostnamen des Rechners verglichen, der sich anmelden will. 
Bits, Exponent und Modulus werden direkt den Host-Schlüsseln entnommen,
die in den Dateien /etc/ssh/ssh_host_*_key.pub gespeichert sind. 
Das optionale Kommentarfeld wird nicht ausgewertet. 

* /etc/ssh/ssh.config 
Client-Einstellungen. 

<hr>
Schlüssel: 

Der Befehl 'ssh-keygen' erzeugt und verwaltet die Schlüssel für SSH-Verbindungen. 
Normaluser können sich damit einen Schlüssel erzeugen, der Systemverwalter kann auch den
Host-Schlüssel damit anlegen. Diese Schlüssel sind nicht zwingend für den Gebrauch von SSH erforderlich, bestimmte Server
verlangen ihn aber. Es stehen zwei Schlüsseltypen ('RSA' und 'DSA') zur Verfügung, erforderlich ist aber nur einer von beiden. 
Man wird bei der Erstellung nach einem Passwort gefragt, muß aber keines angeben. 
Es ist also möglich, über diese Schlüsselpaare eine Authentifizierung ohne Passwort zu steuern. 

> ssh-keygen -t rsa
Password:
...
Generating public/private rsa key pair.
... in ~/.ssh/id_dra.pub
> ssh-keygen -t dsa
Password:
...
Generating public/private dsa key pair.
... in ~/.ssh/id_dsa.pub

Der Inhalt mindestens einer der beiden Dateien 'id_rsa.pub' und 'id_dsa.pub' müssen auf dem
Remote-Rechner in die Datei $HOME/.ssh/authorized_keys eingetragen werden. 
Verzeichnis als auch die Datei dürfen nur für den User lesbar und schreibbar sein. 
Dies geht manuell oder mit:

> ssh-copy-id -i /home/tux/.ssh/id_rsa.pub 192...(Server-DNS)
password:
...

In der Serverkonfiguration kann die Passwort-Authentifikation ausgeschaltet werden:
/etc/ssh/sshd_config:
# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no

Und gegebenenfalls:
/etc/ssh/sshd_config:
- PermitRootLogin yes/no

Der Server muß neu gestartet werden:
> /etc/init.d/ssh restart

<hr>
Die Datei /etc/ssh/sshd_config : 

* BatchMode yes/no 
Die Abfrage nach dem Passwort oder der Passphrase wird unterbunden,
somit lassen sich z.B. Kommandos in Shellscripts ausführen. 
* Compression yes/no 
Schaltet die Komprimierung der zu übertragenden Daten ein oder aus.
* FallBackToRsh yes/no 
Scheitert der Verbindungsaufbau zum Server (zB. weil dieser nicht aktiv ist),
kann eine Verbindung über rsh versucht werden. Default: 'no'
* HostKey Dateiname 
Spezifiziert die Datei, in der der Host-Schlüssel des Servers abgelegt ist.
Normalerweise ist das die Datei /etc/ssh/ssh_host_key.
Diese Datei darf nicht für alle Welt lesbar sein,
ansonsten verweigert sich sshd die Datei zu verwenden!
* IgnoreRhosts yes/no 
Sollen die Dateien ~/.rhosts und ~/.shosts ignoriert werden?
* KeyRegenerationInterval Zeit 
Die Anzahl der Sekunden, nach denen der Server-Schlüssel neu erstellt werden soll.
Standardmäßig sollte hier 3600 (eine Stunde) stehen.
Steht hier eine 0, so wird der Schlüssel niemals neu erstellt.
* PermitRootLogin yes/no 
Erlaubt, daß sich der Systemverwalter über ssh einloggen kann.
* PasswordAuthentication yes/no 
Soll eine Abfrage des Passwortes durchgeführt werden? 
Steht der Wert auf »no«, ist ein Anmelden auf einem entfernten Rechner nur möglich,
wenn der eigene öffentliche Schlüssel dort bekannt ist.
* Port n 
Die Angabe auf welchem Port sshd laufen soll. Normalerweise ist es Port 22.
* RhostsAuthentication yes/no 
Ob bei der Authentifizierung die Dateien rhosts und /etc/hosts.equiv ausreichen,
soll auf »no« bleiben.
* RhostsRSAAuthentication yes/no 
Erlaubt die Benutzung von rhosts und /etc/hosts.equiv,
allerdings nur wenn die RSA-HOST-Authentifizierung erfolgreich war.
Default »yes«.
* RSAAuthentication yes/no 
Authentifizierung mittels RSA-Verschlüsselung. 
Steht der Wert auf »yes«, sollte die Datei »~/.ssh/identity«
oder ein Authentifizierungsagent existieren.
* StrictHostKeyChecking yes/no 
Ein »yes« verschärft die Sicherheit, indem das Anmelden nur auf Rechnern gestattet wird,
die in den Datenbanken »/etc/known_hosts« bzw. »~/.ssh/known_hosts« enthalten sind.
Steht hier »no« werden neu besuchte Rechner automatisch der privaten Datei hinzugefügt.

<hr>
Troubleshooting: 

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! 
Schonmal auf den Server (mit gleicher IP) zugegriffen ? 
(Schlüssel hat sich geändert) 

> ssh-keygen -R hostname
/home/tux/.ssh/known_hosts updated.
Original contents retained as /home/tux/.ssh/known_hosts.old

Falls es nicht geht: 
Inhalt von ~/.ssh/known_hosts komplett löschen oder entsprechend editieren! 

Wenn weiter unten die Zeile kommt: 
'DSA host key for 141.44.198.20 has changed and you have requested strict checking.' 
Versuche es mit Änderung in: 
/etc/ssh/sshd_config
StrictHostKeyChecking: yes/no/ask (def: ask)

<hr>
Immer noch Probleme? 

* Ist der ssh-Zugriff überhaupt möglich? 
Ein beliebtes Problem ist '... key_exchange ... connection closed by foreign host'. 
Das liegt dann meist daran, daß die Reverse-Auflösung der eigenen IP-Adresse nicht
mit dem Namen für den eigenen Host übereinstimmt.
Auf der anderen Seite in /etc/hosts.deny die ALL: PARANOID Zeile auskommentieren. 
Oder DNS in Ordnung bringen!

* Passwort wird verlangt.
Meistens ein Problem der Permissions auf der eigenen und/oder der anderen Seite: 
Das Verzeichnis .ssh/ und die die Datei .ssh/authorized_keys darf nur für den Eigentümer,
der auch der "angepeilte" Nutzer sein muß, schreibbar sein! 
ssh -v ... hilft, diese Art von Problemen zu diagnostizieren.

<hr>
Quellen:
Einrichten von Secure Shell (OpenSSH) - LPI-Study Guides
Thomas Ermer / Michael Meyer: Linuxfibel - Netzwerk Server - Telnet & Co.
Heiko Schlittermann: SSH ohne Passwort -- eine kurze Anleitung
Ernst Bötsch: Secure Shell (SSH) für Benutzer
Johannes Franken: OpenSSH Grundlagen