PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : SSH, Speicherverzeichnis des AuthorizedKeysFile



LarsThorwald
24.11.07, 11:37
Guten morgen zusammen,

ich habe folgendes anzubringen:
Es sollen sich 3-4 User über ssh bzw. WinSCP an meinem Linuxserver verbinden dürfen. Aus Sicherheitsgründen darf die Anmeldung nur über einem SSH 2 Schlüssel erfolgen. Die Authentifizierung erfolgt über eine Public Key Datei (AuthorizedKeysFile), deren Pfad in der sshd_config von mir vermerkt worden ist. Das klappt eigentlich alles soweit auch ganz gut, nun stellt sich mir eine allgemeine Frage:

In welchem Ordner gehört die Public Key Datei? Die sich anzumelden User müssen wie ich festgestellt habe, zu mindestens ein Leserecht auf die Public Key Datei haben, da ansonsten die Meldung kommt, das eine Authentifizierung nicht möglich sei. Meine Idee, die Datei in das Hmoeverzeichnis des roots wird damit hinfällig. Gibt es eine allgemeine Empfehlung, in welchem Ordner so eine Datei hingehört?

Gruß
Lars

Thorashh
24.11.07, 12:56
Da wo sie standarmäßig landet. Im Homeverzeichnis des Users.
Das mehrere User sich ein Keyfile teilen ist unsinnig und unnötig.

LarsThorwald
24.11.07, 13:38
Da wo sie standarmäßig landet. Im Homeverzeichnis des Users.
Das mehrere User sich ein Keyfile teilen ist unsinnig und unnötig.
Hm, wie verweise ich aber in der sshd_config auf diese Datei? Beim testen stellte ich fest, das 2 Einträge mit AuthorizedKeysFile in der sshd_config nicht funktioniert. Es wird scheinbar der erste Verweis ausgewertet. Der zweite aber nicht mehr :(

echo
24.11.07, 13:47
In welchem Ordner gehört die Public Key Datei? Die sich anzumelden User müssen wie ich festgestellt habe, zu mindestens ein Leserecht auf die Public Key Datei haben, da ansonsten die Meldung kommt, das eine Authentifizierung nicht möglich sei. Meine Idee, die Datei in das Hmoeverzeichnis des roots wird damit hinfällig. Gibt es eine allgemeine Empfehlung, in welchem Ordner so eine Datei hingehört?


was meinste hier mit public key? der key vom server, oder der key von den usern?
der public key der user wird in die authorized_key kopiert, wenn sie auf den server dürfen.

wenn du verhindern willst, dass sich die user immer mehr keys in die authorized_keys eintragen, kannste in der sshd_config hinterlegen, wo diese stehen soll


AuthorizedKeysFile /root/authorized_keys/%u_authorized_keys

%u ist hierbei der Username, der vom sshd ersetzt wird.

darüberhinaus könntest du jedem schlüssel eine absende-IP geben...

LarsThorwald
25.11.07, 12:01
was meinste hier mit public key? der key vom server, oder der key von den usern?
der public key der user wird in die authorized_key kopiert, wenn sie auf den server dürfen.

wenn du verhindern willst, dass sich die user immer mehr keys in die authorized_keys eintragen, kannste in der sshd_config hinterlegen, wo diese stehen soll


AuthorizedKeysFile /root/authorized_keys/%u_authorized_keys

%u ist hierbei der Username, der vom sshd ersetzt wird.

darüberhinaus könntest du jedem schlüssel eine absende-IP geben...

Leider funktioniert die Methode
AuthorizedKeysFile /root/authorized_keys/%u_authorized_keys
nicht. Ich bekomme die Meldung, das der Key nicht akzeptiert wird. Ich würde gerne mal in Erfahrung bringen, auf welchen Schlüssel bei der Authentifzierung zugegriffen wird. Ich finde aber das Logfile nicht. In der sshd_config habe ich ein LogLevel VERBOSE eingetragen. Ohne Erfolg! Kann es vielleicht darin liegen, das im Ordner root und deren Unterverzeichnisse nur explizit der root Leserechte besitzt?

LarsThorwald
25.11.07, 12:12
Leider funktioniert die Methode
nicht. Ich bekomme die Meldung, das der Key nicht akzeptiert wird. Ich würde gerne mal in Erfahrung bringen, auf welchen Schlüssel bei der Authentifzierung zugegriffen wird. Ich finde aber das Logfile nicht. In der sshd_config habe ich ein LogLevel VERBOSE eingetragen. Ohne Erfolg! Kann es vielleicht darin liegen, das im Ordner root und deren Unterverzeichnisse nur explizit der root Leserechte besitzt?
An den Rechten sollte es nixht leigen. Mit dem Root klappt es auch nicht:(

temir
25.11.07, 12:28
Ein 'normaler' User hat in der /root - Directory nichts zu suchen (abgesehen davon, dass er da eh nicht reinkommt).
Warum schaut ihr beide (oder alle drei) nicht in die manpage (`man sshd_config`), oder in den
Backup des sshd_config-Originals? :


#AuthorizedKeysFile .ssh/authorized_keys

Wie man sieht, ist der default-Eintrag sogar auskommentiert (nicht geändert).
Zitat aus der manpage:


AuthorizedKeysFile
Specifies the file that contains the public keys that can be used for user authentication.
AuthorizedKeysFile may contain tokens of the form %T which are substituted during connection setup.
The following tokens are defined: %% is replaced by a literal '%', %h is replaced by the home direc-
tory of the user being authenticated, and %u is replaced by the username of that user. After expan-
sion, AuthorizedKeysFile is taken to be an absolute path or one relative to the user's home directory.
The default is ``.ssh/authorized_keys''.

Früher war der default ``~/.ssh/authorized_keys''.

LarsThorwald
25.11.07, 13:56
Ein 'normaler' User hat in der /root - Directory nichts zu suchen (abgesehen davon, dass er da eh nicht reinkommt).
Warum schaut ihr beide (oder alle drei) nicht in die manpage (`man sshd_config`), oder in den
Backup des sshd_config-Originals? :


#AuthorizedKeysFile .ssh/authorized_keys

Wie man sieht, ist der default-Eintrag sogar auskommentiert (nicht geändert).
Zitat aus der manpage:


AuthorizedKeysFile
Specifies the file that contains the public keys that can be used for user authentication.
AuthorizedKeysFile may contain tokens of the form %T which are substituted during connection setup.
The following tokens are defined: %% is replaced by a literal '%', %h is replaced by the home direc-
tory of the user being authenticated, and %u is replaced by the username of that user. After expan-
sion, AuthorizedKeysFile is taken to be an absolute path or one relative to the user's home directory.
The default is ``.ssh/authorized_keys''.

Früher war der default ``~/.ssh/authorized_keys''.

Also sollte ein Ordner in /.ssh erstellt werden, und die Files dort gelagert werden? Wäre natürlich auch eine Möglichkeit

temir
25.11.07, 19:50
Nicht "/.ssh" sondern ist hier "~/.ssh" gemeint!

EDIT:
~/.ssh ist auch als $HOME/.ssh zu entschlüsseln.

LarsThorwald
25.11.07, 22:33
Nicht "/.ssh" sondern ist hier "~/.ssh" gemeint!

EDIT:
~/.ssh ist auch als $HOME/.ssh zu entschlüsseln.

Wenn ich dich richtig interpretiere sollen die Schlüssel in das jeweilige Homeverzeichnis kopiert werden (und den Ordner in nur "lesend" konvertieren). Was würde denn gegen eine zentrale Verwaltung aller Keys in einem Ordner sprechen? Der Vorschlag
%u_authorized_keys von echo hört sich sehr interessant an.

BedriddenTech
26.11.07, 02:07
Bist du sicher, daß du das System verstanden hast? Nicht böse gemeint, aber vielleicht geht deine Vorstellung etwas an der ursprünglichen Intention vorbei. Die ist folgende: Paßwörter sind abzuschalten, stattdessen besitzt jeder Benutzer (mindestens ein) Schlüsselpaar, mit dem er sich anmelden kann. Das erzeugt er sich selbst und fügt es auch selbst bei sich ein. D.h., der Benutzer ist eigentlich derjenige, der die Schlüssel verwaltet, und da er der einzige ist, der an sein Heimatverzeichnis ran kann, ist auch sichergestellt, daß niemand reinfuscht. Und weil der Benutzer auch nur für sich selbst Schlüssel hinterlegen kann (d.h. "foo" kann nur Schlüssel für "foo" einrichten und nicht für "bar"), entsteht auch keine Sicherheitslücke à la "A schaltet Zugang für B frei", oder gar "A fügt neue Konten hinzu". D.h., es ist sinnlos, ~/.ssh für den Benutzer auf "nur lesen" zu setzen - es ist ja gerade erwünscht, daß er schreibt!
D.h., für den Benutzer "foo" gibt es ein ~foo/.ssh/authorized_keys, für "bar" eben ein ~bar/.ssh/authorized_keys.
Der Admin kommt an einer oder zwei Stellen ins Spiel: Erstens beim Aktivieren der Schlüssel (und dem Deaktivieren der Paßwörter für SSH), und eventuell zweitens beim Hinzufügen des ersten Schlüssels, falls der Nutzer nur per SSH Verbindung zum Gerät aufnehmen kann. (Der steht bei der allerersten Anmeldung nämlich vor dem Henne-Ei-Problem: Er darf nicht verbinden, weil kein Schlüssel da ist, den er aber hat; aber ohne Verbindung kann er den nicht hinterlegen. Dienste wie SourceForge z.B. haben dafür ein Webinterface.)

echo
26.11.07, 08:06
Bist du sicher, daß du das System verstanden hast? Nicht böse gemeint, aber vielleicht geht deine Vorstellung etwas an der ursprünglichen Intention vorbei. Die ist folgende: Paßwörter sind abzuschalten, stattdessen besitzt jeder Benutzer (mindestens ein) Schlüsselpaar, mit dem er sich anmelden kann. Das erzeugt er sich selbst und fügt es auch selbst bei sich ein. D.h., der Benutzer ist eigentlich derjenige, der die Schlüssel verwaltet, und da er der einzige ist, der an sein Heimatverzeichnis ran kann, ist auch sichergestellt, daß niemand reinfuscht. Und weil der Benutzer auch nur für sich selbst Schlüssel hinterlegen kann (d.h. "foo" kann nur Schlüssel für "foo" einrichten und nicht für "bar"), entsteht auch keine Sicherheitslücke à la "A schaltet Zugang für B frei", oder gar "A fügt neue Konten hinzu". D.h., es ist sinnlos, ~/.ssh für den Benutzer auf "nur lesen" zu setzen - es ist ja gerade erwünscht, daß er schreibt!
D.h., für den Benutzer "foo" gibt es ein ~foo/.ssh/authorized_keys, für "bar" eben ein ~bar/.ssh/authorized_keys.
Der Admin kommt an einer oder zwei Stellen ins Spiel: Erstens beim Aktivieren der Schlüssel (und dem Deaktivieren der Paßwörter für SSH), und eventuell zweitens beim Hinzufügen des ersten Schlüssels, falls der Nutzer nur per SSH Verbindung zum Gerät aufnehmen kann. (Der steht bei der allerersten Anmeldung nämlich vor dem Henne-Ei-Problem: Er darf nicht verbinden, weil kein Schlüssel da ist, den er aber hat; aber ohne Verbindung kann er den nicht hinterlegen. Dienste wie SourceForge z.B. haben dafür ein Webinterface.)

Hi,
gegen dieses szenario kann folgendes sprechen:
stell dir vor in einer firma gib es sowas wie eine zentrale userverwalltung. diese könnte zb durch einen ldap-server aufgebaut werden. hier wird jeder user dazu gezwung sein passwort nach bestimmten regeln zu erstellen.

nun will aber diese firma defititiv NICHT, dass sich ein user NICHT an diese regeln hällt. nun wirst du sehen, dass in diesem fall solche schlüssel, die jeder user haben könnte NICHT gewolt sind / sein können. jedoch könnte es nötig sein, für einige user die zb daten von rechner A nach rechner B (per script) kopieren dennoch schlüssel zu benutzen. ggf kann auf diese user jemand ein su ausführen und sich den schlüssel "klauen". täte er dies, wäre er durch die zentrahlen sperr- und "gängelungs-"politik nicht mehr greifbar....

glaub hier muss ich keine weiteren worte tippen oder?

echo
26.11.07, 08:13
AuthorizedKeysFile /root/authorized_keys/%u_authorized_keys



dieses funktioniert defintiv mit meiner installierten version.
ich habe expliziet "/root" als ordner gewählt, da sonst sich der sshd beschwert, dass der ordner nicht root gehört!
als recht habe ich den kompletten ordnerbaum dem user root:root gegeben und die 700 für ordner und 600 für dateien.

ansonsten hier mal der ausschnitt meiner man sshd_config


AuthorizedKeysFile
Specifies the file that contains the public keys that can be used
for user authentication. AuthorizedKeysFile may contain tokens
of the form %T which are substituted during connection set-up.
The following tokens are defined: %% is replaced by a literal
'%', %h is replaced by the home directory of the user being
authenticated and %u is replaced by the username of that user.
After expansion, AuthorizedKeysFile is taken to be an absolute
path or one relative to the user's home directory. The default
is ``.ssh/authorized_keys''.

drcux
26.11.07, 08:51
Der User, der sich anmelden darf, muss aber Leserechte auf den Key haben, wie soll das gehen, wenn der Ordner root mit 700 bzw die Datei mit 600 gehört?

Folgendes habe ich gerade probiert und es funktioniert so:

Ordner erstellen: /etc/sshkeys
Rechte root:root 755
Darin eine Ordner mustermann, Rechte mustermann:users 700
Dort drinne der Schlüssel für mustermann (mustermann:users 600), also:
/etc/sshkeys/mustermann/authorized_keys

In der /etc/ssh/sshd_config
AuthorizedKeysFile /etc/sshkeys/%u/authorized_keys
fertig.

Ein anderer User kann in /etc/sshkey keinen Ordner erstellen und somit auch keinen Key für sich erstellen. Das kann nur Root erledigen, sollte also deinen Ansprüchen genügen.

echo
26.11.07, 09:33
Der User, der sich anmelden darf, muss aber Leserechte auf den Key haben, wie soll das gehen, wenn der Ordner root mit 700 bzw die Datei mit 600 gehört?

ich tippe mal...
sshd läuft als root-prozess und ich denke mal, bei meiner ssh-version wird noch vor dem user-switch der key geprüft. somit ist dann eine user-berechtigung für den ordner/die datei nicht nötig.