Ich habe mehrmals Hosts angetroffen, bei denen rsa nicht funktioniert, nur dsa. Einmal ging aber im Gegenzug dsa nicht. Kann mir jemand sagen, welches von beiden weiter verbreitet ist? Die sshds auf meinen eigenen Systemen unterstützen jedenfalls beides.
openssh2 unterstützt ebenfalls rsa! rsa ist auch immernoch das bevorzugte verfahren. wenn du an einem hosts nicht alle schlüssel findest, war der admin wohl zu "faul" die entsprechenden schlüssel anzulegen. grundsätzlich sollte aber heute nurnoch mit dem protokoll 2 gearbeitet werden. also nochmal: SSH2 kann DSA- und RSA-Schlüssel verwenden. Im Fall von RSA sind das ssh_host_rsa_key und ssh_host_rsa_key.pub, im Fall von DSA sind das ssh_host_dsa_key und ssh_host_dsa_key.pub
Nun kopiert man die Datei id_rsa.pub mittels (aus Sicherheitsgründen) scp in das $HOME/.ssh des Rechners,
Da es sich hier um den oeffentlichen Schluessel handelt, muss man ihn eben _nicht_ so uebertragen, dass er von niemand anders gelesen werden kann (das ist ja gerade der Sinn der asymmetrischen Verschluesselung, dass man den Schluessel einfach zwischen den Kommunikationspartnern uebermitteln kann, und jeder darf diesen oeffentlichen Schluessel sehen). Scp muss den Schluessel also hier gar nicht schuetzen, sondern eben nur das Account-Passwort.
Bei dem privaten Schluessel (id_dsa/id_rsa) sollte man immer darauf achten, dass nur der Nutzer selbst Leserechte hat; die Dateien werden zwar standardmaessig so erzeugt, aber man kann ja nie wissen...
Die Passphrase bei der Erzeugung des Schluesselpaares muss man nicht angeben, in diesem Fall wuerde der private Schluessel unverschluesselt gespeichert, sodass jeder, der ihn in die Finger bekommt, sofort missbrauchen kann. Gibt man eine Passphrase an, wird dieser private Schluessel verschluesselt abgelegt.
Dieser wartet, nachdem das SSH-Kennwort beim Rechnerstart einmal abgefragt wurde, auf bevorstehende SSH-Logins und kümmert sich um die Authentifizierung, damit der Nutzer nichts mehr machen muss.
Der ssh-agent sollte in einer Login-Shell gestartet werden, und man sollte dann alle weiteren Shells von dieser aus aufrufen, damit diese dann auch auf den Agenten zugreifen koennen. Der Agent haelt einfach nur die privaten Schluessel im Speicher, und kuemmert sich dann um die ssh-Authentifizierungen. Nachdem der Agent gestartet wurde, muss man ihm noch die Schluessel uebergeben, die er bereithalten soll, was mittels ssh-add passiert. Dieses Ganze passiert aber nicht beim Rechnerstart, sondern fuer jeden Benutzer, fruehestens nachdem er sich auf dem Rechner eingeloggt hat.
Alle Anleitungen und HOWTOs, die ich im Netz zu diesem Thema gefunden habe, enthielten das Bearbeiten von .xinitrc und/oder .xsession. Benutzt man KDM/GDM/XDM, wird es nochmal ein Stück komplizierter.
Das Naheliegenste waere gewesen, die einschlaegigen man-Pages zu lesen (z.B. von ssh-agent), dort steht auch, was zu tun ist. Die .xsession ist sowieso meistens ein Link zur .xinitrc, ansonsten editiert man einfach beide (.xsession muss fuer die Nutzung mit Xdm editiert werden). Das Einzige, was hinzugefuegt werden muss (von dem Beispiel in diesem Kurztip ausgehend):
eval `ssh-agent` (als ersten Befehl in der Datei)
ssh-add ${HOME}/.ssh/id_rsa (als zweiten Befehl, bewirkt auch die Abfrage der Passphrase)
ssh-agent -k (als letzten Befehl, sorgt dafuer, dass der Agent am Ende der Sitzung beendet wird)
U.U. startet der Xdm den ssh-agent sogar selbst (z.B. bei Debian), sodass nur der Befehl "ssh-add ${HOME}/.ssh/id_rsa" noetig ist. Ob KDM/GDM .xsession/.xinitrc auslesen, weiss ich nicht, mit Xdm klappts auf jeden Fall so.
Außerdem müssen zwei Kennwörter eingegeben werden.
Stimmt in diesem Beispiel _nicht_; es muss _nur_ die _eine_ Passphrase eingegeben werden, mit der der private Schluessel verschluesselt wurde.
PAM-Modul ...
Sieht doch nach wesentlich mehr Aufwand aus, ausserdem muss man dazu Root sein.
Trotzdem ist es schoen, dass dieses Thema mal bei Pro-Linux behandelt wird.
+++ Ob KDM/GDM .xsession/.xinitrc auslesen, weiss ich nicht, mit Xdm klappts auf jeden Fall so. +++
AFAIK tun beide das auch. Ich bin mir recht sicher, dass so in bekannten Linuxbuch (dessen Namen ich jetzt natürlich vergessen habe) von Kofler so mal gelesen zu haben.
Zum ersten Punkt (uebertragung des public keys via scp [aus Sicherheitsgruenden]), dachte ich mir auch erst, es sei nicht noetig... Ist es aber doch (und nein nicht um das Passwort zu schuetzen, man haette ja z.B. den public key aufn ftp schieben koennen, oder per email etc.) ABER: Wichtig ist, das man sich sicher sein kann den ECHTEN public key am anderen Ende der Leitung zu erhalten, sonst schaltet man da naemlich sonst wen frei fuer Passwortlosen zugriff.
Ich hatte es bisher auch so eingerichtet wie Du das jetzt beschreibst. Ich musste aber nach dem üblichen Login per (X|G|K)DM dann aber noch per x11-ssh-askpass o.ä. die Passphrase eingeben (das meinte ich mit "zweimal"), was mich irgendwie angenervt hat. Du hast wohl recht, Deine (die übliche) Vorgehensweise kommt ohne Rootrechte aus, die mit dem pam_ssh-Modul nicht.
Nun kopiert man die Datei id_rsa.pub mittels (aus Sicherheitsgründen) scp in das $HOME/.ssh des Rechners,
Da es sich hier um den oeffentlichen Schluessel handelt, muss man ihn eben _nicht_ so uebertragen, dass er von niemand anders gelesen werden kann (das ist ja gerade der Sinn der asymmetrischen Verschluesselung, dass man den Schluessel einfach zwischen den Kommunikationspartnern uebermitteln kann, und jeder darf diesen oeffentlichen Schluessel sehen).
In der Sache hast Du Recht. Allerdings finde ich es eher gut, daß der Autor die Verwendung von scp auch für diesen Kopiervorgang vorschlägt - zum einen ist rcp aus Sicherheitsgründen auf vielen Rechnern gar nicht mehr installiert, zum anderen gewöhnen sich dann auch nicht so sicherheitsbewußte User an den Gebrauch von verschlüsselten Tools.
Scp muss den Schluessel also hier gar nicht schuetzen, sondern eben nur das Account-Passwort. Es muß doch auch sichergestellt werden, dass der Schlüssel während der Übertragung nicht verändert wird, denn auch bei Public-Key Verfahren muß man irgendwie sicherstellen, dass man den richtigen Schlüsel verwendet.
ist mir noch gar nicht aufgefallen das dieser Tipp bis jetzt fehlte.
Ich betreibe auch in vielen Fällen die Authentifizierung per public-keys. Das klappt auch ganz mit Putty (Windows) -> OpenSSH Anfangs hatte ich noch bedenken, wie das denn sicher sein könne, deswegen für die Zweifler: Der SSH Server kennt ja nun den PublicKey des Clients und bekommt nun die Aufforderung zum Login. Jetzt kann der Server den Handshake mit dem Public_Key verschlüsseln und so sicher sein das nur der Besitzer mit dem entsprechenden Private Key dies entschlüsseln kann und somit als einziger darauf antworten kann. Somit hängt alles daran das niemand an die authorized_keys kommt und dort einfach seinen Public_key anfügt und das natürlich niemand an den privat_key kommt.
also da sind jetzt leider zwei Versionen des Texts irgendwie miteinander vermengt worden, daher ist wohl auch noch der Dreher drin und der Satzteil mit "aus Sicherheitsgründen"... Das hatte ich eigentlich schon korrigiert... Naja die Welt geht nicht unter und wer Linux und intensiv SSH nutzt wird wohl auch noch herausbekommen, dass es pam_ssh und nicht ssh_pam heißen muss...
Funktionieren tut alles super, außer eine Kleinigkeit. Beim Login oder bei su, also immer wenn ich das Passwort eingeben muss, wird die erste Eingabe einfach ignoriert. D.h.
$ su - Passwort: xxxxx (richtiges Passwort) Passwort: xxxxx (nochmal genau das Selbe) $ erst dann kommt ein erfolgreicher Login. Muss ich unter /etc/pam.d/system-auth vielleicht nocht etwas löschen?
Also zumindest bei mir ist es so: will man sich als root einloggen wird erst die SSH-Passphrase abgefragt, auch wenn diese nicht vorhanden ist. Wird dann nichts oder etwas falsches dafür eingegeben, wird das normale Passwort abgefragt. Du kannst einfach für root auch wie beschrieben ein Schlüsselpaar erzeugen und mit einer Passphrase versehen.
Falls man keine Lust auf das Hantieren mit diversen Dateien hat, kann auch das bei neueren Versionen von SSH mitgelieferte Tool ssh-copy-id verwenden: Nach Eingabe von
ssh-copy-id -i FILENAME user@host
wird die Schlüsseldatei FILENAME an die Datei host:/home/user/.ssh/authorized_keys angehängt - die Schlüsseldateien liegen normalerweise in ~/.ssh/ und heißen id_rsa.pub bzw. id_dsa.pub
Ich sehe die Gefahr des Veruntreuens von Passwort oder Passphrase.
Diese Methode eignet sich auch für nicht-verschlüsselnde Dienste zum Login. Dabei muss aber das Unix-Password/ssh-Passphrase eingegeben werden, welches eigentlich im eigenen Protokoll versteckt übertragen wird. Beliebte Protokolle sind XDMCP, ftp, telnet, pop3, http, aber auch Remote-Konsolen (Modem) sind problematisch. Wird pam_ssh selektiv für Dienste verwendet, ist der Vorteil des Single-Sign-On weg.
Wer sowieso Shell-Zugang hat, der sollte sich per SSH einloggen und eventuell noch paar Tunnel bauen (für X11 z.B.). Die anderen Dienste sollten in Ihrer ssl-Version den Verrat verhindern.
Kann mir jemand sagen, welches von beiden weiter verbreitet ist? Die sshds auf meinen eigenen Systemen unterstützen jedenfalls beides.
DSA ist besser und neuer. Vergleich einfach mal RSA-Keys mit DSA-Keys.
prost
Da es sich hier um den oeffentlichen Schluessel handelt, muss man ihn eben _nicht_ so uebertragen, dass er von niemand anders gelesen werden kann (das ist ja gerade der Sinn der asymmetrischen Verschluesselung, dass man den Schluessel einfach zwischen den Kommunikationspartnern uebermitteln kann, und jeder darf diesen oeffentlichen Schluessel sehen). Scp muss den Schluessel also hier gar nicht schuetzen, sondern eben nur das Account-Passwort.
Bei dem privaten Schluessel (id_dsa/id_rsa) sollte man immer darauf achten, dass nur der Nutzer selbst Leserechte hat; die Dateien werden zwar standardmaessig so erzeugt, aber man kann ja nie wissen...
Die Passphrase bei der Erzeugung des Schluesselpaares muss man nicht angeben, in diesem Fall wuerde der private Schluessel unverschluesselt gespeichert, sodass jeder, der ihn in die Finger bekommt, sofort missbrauchen kann. Gibt man eine Passphrase an, wird dieser private Schluessel verschluesselt abgelegt.
Dieser wartet, nachdem das SSH-Kennwort beim Rechnerstart einmal abgefragt wurde, auf bevorstehende SSH-Logins und kümmert sich um die Authentifizierung, damit der Nutzer nichts mehr machen muss.
Der ssh-agent sollte in einer Login-Shell gestartet werden, und man sollte dann alle weiteren Shells von dieser aus aufrufen, damit diese dann auch auf den Agenten zugreifen koennen. Der Agent haelt einfach nur die privaten Schluessel im Speicher, und kuemmert sich dann um die ssh-Authentifizierungen.
Nachdem der Agent gestartet wurde, muss man ihm noch die Schluessel uebergeben, die er bereithalten soll, was mittels ssh-add passiert.
Dieses Ganze passiert aber nicht beim Rechnerstart, sondern fuer jeden Benutzer, fruehestens nachdem er sich auf dem Rechner eingeloggt hat.
Alle Anleitungen und HOWTOs, die ich im Netz zu diesem Thema gefunden habe, enthielten das Bearbeiten von .xinitrc und/oder .xsession. Benutzt man KDM/GDM/XDM, wird es nochmal ein Stück komplizierter.
Das Naheliegenste waere gewesen, die einschlaegigen man-Pages zu lesen (z.B. von ssh-agent), dort steht auch, was zu tun ist. Die .xsession ist sowieso meistens ein Link zur .xinitrc, ansonsten editiert man einfach beide (.xsession muss fuer die Nutzung mit Xdm editiert werden).
Das Einzige, was hinzugefuegt werden muss (von dem Beispiel in diesem Kurztip ausgehend):
U.U. startet der Xdm den ssh-agent sogar selbst (z.B. bei Debian), sodass nur der Befehl "ssh-add ${HOME}/.ssh/id_rsa" noetig ist.
Ob KDM/GDM .xsession/.xinitrc auslesen, weiss ich nicht, mit Xdm klappts auf jeden Fall so.
Außerdem müssen zwei Kennwörter eingegeben werden.
Stimmt in diesem Beispiel _nicht_; es muss _nur_ die _eine_ Passphrase eingegeben werden, mit der der private Schluessel verschluesselt wurde.
PAM-Modul ...
Sieht doch nach wesentlich mehr Aufwand aus, ausserdem muss man dazu Root sein.
Trotzdem ist es schoen, dass dieses Thema mal bei Pro-Linux behandelt wird.
AFAIK tun beide das auch. Ich bin mir recht sicher, dass so in bekannten Linuxbuch (dessen Namen ich jetzt natürlich vergessen habe) von Kofler so mal gelesen zu haben.
NikN
Ist es möglich, sich via KDE am Kerberos-Server anzumelden und das ssh diese Rechte erbt?
Ist es aber doch (und nein nicht um das Passwort zu schuetzen, man haette ja z.B. den public key aufn ftp schieben koennen, oder per email etc.)
ABER: Wichtig ist, das man sich sicher sein kann den ECHTEN public key am anderen Ende der Leitung zu erhalten, sonst schaltet man da naemlich sonst wen frei fuer Passwortlosen zugriff.
Da es sich hier um den oeffentlichen Schluessel handelt, muss man ihn eben _nicht_ so uebertragen, dass er von niemand anders gelesen werden kann (das ist ja gerade der Sinn der asymmetrischen Verschluesselung, dass man den Schluessel einfach zwischen den Kommunikationspartnern uebermitteln kann, und jeder darf diesen oeffentlichen Schluessel sehen).
In der Sache hast Du Recht. Allerdings finde ich es eher gut, daß der Autor die Verwendung von scp auch für diesen Kopiervorgang vorschlägt - zum einen ist rcp aus Sicherheitsgründen auf vielen Rechnern gar nicht mehr installiert, zum anderen gewöhnen sich dann auch nicht so sicherheitsbewußte User an den Gebrauch von verschlüsselten Tools.
best regards,
husky
Es muß doch auch sichergestellt werden, dass der Schlüssel während der Übertragung nicht verändert wird, denn auch bei Public-Key Verfahren muß man irgendwie sicherstellen, dass man den richtigen Schlüsel verwendet.
Ich betreibe auch in vielen Fällen die Authentifizierung per public-keys.
Das klappt auch ganz mit Putty (Windows) -> OpenSSH
Anfangs hatte ich noch bedenken, wie das denn sicher sein könne, deswegen für die Zweifler:
Der SSH Server kennt ja nun den PublicKey des Clients und bekommt nun die Aufforderung zum Login.
Jetzt kann der Server den Handshake mit dem Public_Key verschlüsseln und so sicher sein das nur der Besitzer mit dem entsprechenden Private Key dies entschlüsseln kann und somit als einziger darauf antworten kann.
Somit hängt alles daran das niemand an die authorized_keys kommt und dort einfach seinen Public_key anfügt und das natürlich niemand an den privat_key kommt.
HTH
Max
cu Daniel
also da sind jetzt leider zwei Versionen des Texts irgendwie miteinander vermengt worden, daher ist wohl auch noch der Dreher drin und der Satzteil mit "aus Sicherheitsgründen"... Das hatte ich eigentlich schon korrigiert...
Naja die Welt geht nicht unter und wer Linux und intensiv SSH nutzt wird wohl auch noch herausbekommen, dass es pam_ssh und nicht ssh_pam heißen muss... 
% zcat /usr/share/doc/pam_ssh-1.9/system-auth.example.gz | grep ssh >> /etc/pam.d/system-auth
system-auth.gz ist eine vom Paket bereitgestellte Beispiel-Konfigurationsdatei.
$ su -
Passwort: xxxxx (richtiges Passwort)
Passwort: xxxxx (nochmal genau das Selbe)
$
erst dann kommt ein erfolgreicher Login. Muss ich unter /etc/pam.d/system-auth vielleicht nocht etwas löschen?
ssh-copy-id -i FILENAME user@host
wird die Schlüsseldatei FILENAME an die Datei host:/home/user/.ssh/authorized_keys angehängt - die Schlüsseldateien liegen normalerweise in ~/.ssh/ und heißen id_rsa.pub bzw. id_dsa.pub
best regards,
husky
- michael
Diese Methode eignet sich auch für nicht-verschlüsselnde Dienste zum Login. Dabei muss aber das Unix-Password/ssh-Passphrase eingegeben werden, welches eigentlich im eigenen Protokoll versteckt übertragen wird. Beliebte Protokolle sind XDMCP, ftp, telnet, pop3, http, aber auch Remote-Konsolen (Modem) sind problematisch.
Wird pam_ssh selektiv für Dienste verwendet, ist der Vorteil des Single-Sign-On weg.
Wer sowieso Shell-Zugang hat, der sollte sich per SSH einloggen und eventuell noch paar Tunnel bauen (für X11 z.B.). Die anderen Dienste sollten in Ihrer ssl-Version den Verrat verhindern.
Oder habe ich was übersehen?
funktionieren kann. Oder?