linux-l: Wer hat SSH richtig verstanden...,

[Alexander Stielau]

Mike Fehla <mike.fehla at gmx.de> writes:

> > hast du denn ~/.ssh/identity.pub bzw. ~/.ssh/id_dsa.pub
> > in ~/.ssh/authorized_keys bzw.~/.ssh/authorized_keys2 umbenannt?
> 
> Nein, warum eigentlich? Ich habe genau die defaults belassen, eben
> ~/.ssh/identity.pub usw. Trotzdem ist das eine gute Frage. In der Datei

Weil der public-key das Gegenstück ist, was auf dem anderen Rechner in
$HOME/.ssh/authorized_keys liegen muß, damit eine Authentifizierung
mittels Schlüssel überhaupt probiert wird.

Du mußt ssh-keygen auf deinem lokalen System ausführen und den
identity.pub auf den Rechner in ~/.ssh/ schiessen, auf dem Du Dich
konnecten willst. Dann machst Du DORT ein cat identity.pub >>
authorized_keys. Einen Schlüssel auf dem Server zu generieren ist
unnötig.

> /etc/ssh_config stehen auskommentiert die Dateibezeichnungen, welche man
> eben umdefinieren kann:
> 
> # Site-wide defaults for various options
>  
> # Host *
> #   ForwardAgent no
> #   ForwardX11 no
> #   RhostsAuthentication no
> #   RhostsRSAAuthentication yes
> #   RSAAuthentication yes
> #   PasswordAuthentication yes
> #   FallBackToRsh no
> #   UseRsh no
> #   BatchMode no
> #   CheckHostIP yes
> #   StrictHostKeyChecking yes

Die obigen kannst Du nicht umdefinieren, sondern ein- oder
ausschalten. Der Forward-Agent ermöglicht es z.B., eine mittels
ssh-agent bzw. ssh-add eingegebene Passphrase für einen Key während
einer Session zu 'merken' und auf alle Verbindungen anzuwenden, die
auch nicht mehr lokal sind:

Bei der Verbindung 

Workstation -> ssh-connect auf depp at A -> ssh-connect -> doof at b

ist es so möglich, die Passphrase so zu forwarden als würde die
Connection bzw. der Schlüssel, der mit dieser Passphrase
scharfgeschaltet wird, von Workstation benutzt. 
Das erspart einem in der Praxis das wiederholte und nervige Passphrase
eingeben.

Achtung, Verständnis-Falle: 
Die Passphrase gehört NUR zum geheimen Teil des eigenen Keys - sie hat
erstmal nichts zu tun mit dem public-key. Sie wird nur benötigt, um
den geheimen Schlüssel scharfzuschalten - man kann also auch die 
Passphrase ändern, ohne den public-key tauschen zu müssen.

> #   ForwardX11 no

ForwardX11 erlaubt es, ein Display gleich komplett über die
ssh-Session zu schieben. Das ist in der Regel sinnvoll, ansonsten ist
manuelles Nacharbeiten fällig ala:

export DISPLAY=remote-x:0.0


> #   RhostsAuthentication no
> #   RhostsRSAAuthentication yes
> #   RSAAuthentication yes
> #   PasswordAuthentication yes

Schaltet verschiedene Typen der Authentifikation an oder ab. 
Nach dem Hinterlegen des public-keys auf dem Remote-Rechner sollte man
dort die PasswordAuthentification in der sshd_config abschalten, wenn
man wirklich Sicherheit haben will.

So benötigt man dann nämlich 3 Teile (secret-key im eigenen ~/.ssh,
passenden public auf dem Remotesystem und noch die Passphrase für den
sec-key) und nicht nur das Password.

> #   IdentityFile ~/.ssh/identity  <---
> #   IdentityFile ~/.ssh/id_dsa    <---
> #   IdentityFile ~/.ssh/id_rsa    <---
> #   Port 22

Diese Dinge umzudefinieren macht Probleme, wenn man mit normal
konfigurierten System Kontakt will.

> Oder habe ich das jetzt völlig fehlinterpretiert? Ich frage mich ja
> sowieso, warum das in der Client-Config steht, und nicht in der

Weil man das von Remote-System zu Remotesystem unterschiedlich
handhaben können will. 
Ich will z.B. auf Rechnern, die ich als sicher einstufe (z.B. im LAN),
immer x-forward und agent-forward, aber nicht zu fremden Rechnern.

> server:[fehla]> ls -l .ssh/
> insgesamt 4
> -rw-------   1 fehla    fehla         668 Sep 12 18:08 id_dsa

Wie sind die Rechte von .ssh selbst?

> socket: Die Adreßfamilie wird von der Protokollfamilie nicht unterstützt
> 
> Was bedeutet das genau??

Hmm. Selbskompiliert und die config-Options nicht verstanden?

Aleks
-- 

Vorsorge ist besser als Nachtschicht.