Authorized_Keys - Neuen User anlegen

[Offenbacher]

Hallo,

versuche gerade, einen weiteren Benutzer für OpenSSH (und/oder Dropbear) anzulegen. Mittels "ConnectBot" für Android habe ich einen Publickey generiert und diesen, über die Weboberfläche unter "authorized_keys" erstellt. Der Benutzer "mobile" wurde erfolgreich via Telnet angelegt. Meine authorized_keys sieht also gekürzt so aus:

--mobile
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABBACYH7DEXURuQuwN/lejeBGZRTDs3ebyhkViPqy+sMlT/SEjZqIDfDt3aMLhLfYUoRcZuEk10SbUaIJke/szSDxSn0GGiWlYGnbadDxTt84KQ1EjSWFtKTZIgY9tv9gwkqMwzMXrf9PJQYmuhFCteP3zzIISAErhyxm5vVBjkPFJbKxx4Ggdrxvxg4NdVsno2a5w42voI3LPYfUm4T0niDyiD7A18C1XGlfOwVO/ll5z5IS07DYHg9cFMcEDPkrNB0jAwR+7yEIgW3ttrWD7+M47lkOONaOHLNU0bCzH5Fstg4n5X9acAXn0xqoCcfIOlapsd913Sun9eWNWqokdQlrw0nSJ Home Mobile

Jedoch bekomme ich immer ein Log-In failed. Liegt es eventuell daran?:

Bitte beachte, dass nur für den Benutzer root die Schlüssel automatisch persistent im Flash gespeichert werden. Für alle anderen Benutzer muss das Heimatverzeichnis auf persistenten Speicher (z.B. eine USB Festplatte) zeigen.

In der online-Hilfe von Freetz (http://freetz.org/wiki/packages/authorized-keys) ist darüber kein sterbenswörtchen erwähnt, auch hier (http://freetz.org/wiki/help/howtos/security/user_management) wurde ich nicht schlauer.

 

[Hengzzzzt]

muss das hier mal hochholen...

hab einen user angelegt auf der fritz.box der sich per ssh ohne pw anmelden soll..

ist eingetragen in der authorized_keys doch wenn der nutzer sich anmeldet, will er immer das pw haben.
beim root user klappt das ohne probleme.
im homeverzeichnis vom nutzer legt er auch die authorized_keys datei an, doch funktionieren tut es nicht.

hat das jemand in benutzung?


gruß

 

[PeterPawn]

Normalerweise prüfen die SSH-Server die Zugriffsrechte für die "authorized_keys" und nur der Nutzer selbst darf Zugriff haben (01??000000 als "Bitmaske", also irgendwas zwischen 400 und 700 beim chmod) ... die normale "umask" im FRITZ!OS würde der Gruppe ebenfalls Rechte einräumen, wenn so eine Datei ohne weitere Vorkehrungen angelegt wird. Einen Blick (bzw. eine Überprüfung) ist es zumindest wert ...

Liegt dann das Home-Verzeichnis noch auf einem Volume mit dem falschen Dateisystem (FAT/NTFS), kann man gar keine abweichenden Rechte setzen, weil das in aller Regel beim Mounten festgelegt wird für das gesamte Volume.

 

[Hengzzzzt]

hey peter,

hab die "authorized_keys" des Nutzers "backup" jetzt so mit Rechten versehen:

-rwx------- 1 backup backup 403 Dec 8 14:21 authorized_keys

entspricht chmod 700

Liegen tut das Homeverzeichnis testweise auf dem internen Flash der 7490, also kein fat/ntfs Problem.

Die authorized_keys vom root Nutzer hat die gleichen Rechte, und da funktioniert der Login.

gruß

 

[PeterPawn]

Beide Seiten (wenigstens den Client) mal mit ausführlicher Protokollierung starten ... da wird dann u.a. auch angezeigt, welche Schlüssel für einen automatischen Login-Versuch verwendet werden bzw. ob ein solcher überhaupt stattfindet, bevor dann ein Fallback auf Kennwort-Authentifizierung erfolgt.

Wenn es die Zugriffsrechte für die "authorized_keys" nicht sind, kommen wieder mehrere Ursachen in Frage und dann wird das "Raten" schwerer. Das geht u.U. schon bei Schwierigkeiten des SSH-Servers los, die Verzeichnisse bis zu dieser Datei zu traversieren ... ich rechne fest damit, daß diese Datei in einem Unterverzeichnis ".ssh" des Home-Directories liegt. Kommt der Server an den "public key" ohne Probleme heran, bleibt die Frage, ob der Client ihm die Authentifizierung mit dem fraglichen Schlüsselpaar überhaupt anbietet. Auch DHE-Verfahren und Tunnel-Verschlüsselung sind aus so einem Debug-Log ersichtlich ... wobei Fehler bei einer Aushandlung an dieser Stelle andere Fehlernachrichten hervorrufen sollten.

TL;DR:
Protokoll-Datei einer Anmeldung erstellen und nachsehen, ob vom Server "PubKeyAuthentication" angeboten wird und wie der Client darauf reagiert, welchen Schlüssel er wählt und was der Server darauf antwortet. Je nach der Stelle des Problems muß man dann andere Ursachen in Erwägung ziehen.

 

[koyaanisqatsi]

Moins


Wahrscheinlich ist es das alte Problem der nichtmultiuserfähigkeit der Fritz!Boxen.
Denn zuviele Dateien/Verzeichnisse lassen sich nur als root benutzen.
Deswegen sollten (meines Erachtens) alle Benutzer der Fritz!Box die Gruppe root haben.
...genauso wie die von der Fritz!Box über das Webinterface angelegten boxusr.

Also nicht...
backup.backup
...sondern...
backup.root
/var/tmp/passwd

backup:$1$HthSzgwF$e9NBn5ZBQndHXuq3q9QG20:1000:[COLOR=#ff0000][B]0[/B][/COLOR]:backup:/var/tmp:/bin/ash

 

[level20peon]

Ich mache es wie folgt:

Nach dem Anlegen des users via

adduser foo
modusers save
modsave flash

packe ich folgendes in die debug.cfg

#create directory structure for foo
mkdir /home/foo/
chmod g+rx /home/foo/
chgrp -R foo /home/foo/

mkdir /home/foo/.ssh
echo 'ssh-rsa AAAAB9281nfld09AAABJQAAAIBaR5iQGvTpcklU70RDESp1Ke6R0DEZ/7KPKsjd9aHn2nfl299XBVCSJwc1LrSq+Wq/q8sOLbLnTmolf929mnmas92n49fDRrp4jaHytXMRbCVkr+sfgvMsjd8Hfkf9jVLccOw1JQtUHnD/SUJ9s9jfj9vm2lOIHysU8WF36Q== foo' > /home/foo/.ssh/authorized_keys
chmod 0700 /home/foo/.ssh
chown foo:foo /home/foo/.ssh

Damit wird nach dem reboot das home Verzeichnis des users wieder angelegt und sein public key in das entsprechende .ssh Verzeichnis gelegt. Das ermöglicht dann ein Einloggen des users "foo" mit seinem private key.

 

[Hengzzzzt]

danke an level20peon

damit gehts jetzt

 

[PeterPawn]

@Hengzzzzt:
Magst Du das vielleicht noch genauer erklären?

Wenn Du die Kommandos lediglich wie o.a. abgetippt hast, sollte spätestens beim

chgrp -R foo /home/foo

ein Problem auftauchen, solange die Gruppe "foo" nicht vorher irgendwo angelegt wurde.

Davon lese ich aber im gesamten Thread nichts ... wird die inzwischen von Freetz automatisch erzeugt?

Eine Suche mit

grep -r "foo[^t]"

findet keine entsprechende Zeile in einem Freetz-Image.

Wenn das nicht automatisch erfolgt, wäre das Ergebnis hier für spätere Leser sicherlich erneut sehr unbefriedigend, weil die korrekte Lösung wieder nicht dargestellt ist.

Auch nicht ganz uninteressant wäre es, worin denn (außer "foo:foo" anstelle von "backup:backup" bei Dir, jedenfalls schreibst Du das in #4) der Unterschied beim Ergebnis zu Deinen vorherigen Versuchen nun bestand ... vielleicht hilft es ja späteren Lesern, denselben Fehler zu vermeiden? Ich würde zwar darauf tippen, daß die Rechte zum Traversieren des Verzeichnisbaum dann nicht stimmten, aber das ist eben auch nur geraten, während Du es ja wissen müßtest.

 

[level20peon]

Beim Nutzen von "adduser" wird automatisch eine gleichnamige Gruppe angelegt.

 

[PeterPawn]

Beim Nutzen von "adduser" wird automatisch eine gleichnamige Gruppe angelegt.

Tatsächlich ... das, was ansonsten beim "großen" Linux über die /etc/logins.def und USERGROUPS_ENAB i.V.m. der Standardgruppe geregelt wird, legt hier bei der Busybox klamm- und heimlich eine zusätzliche Gruppe mit an (und nicht etwa "nogroup", um den neuen Benutzer dann dort zu verewigen, denn eine GID braucht er natürlich) ... ist mir vorher nie aufgefallen, danke für den Hinweis.

Wobei ich die Erklärung der Applets da schon arg mißverständlich finde: http://linux.die.net/man/1/busybox -> weiter zu "adduser"

Das erklärt dann, warum das chgrp ohne Fehler funktioniert, soweit verstanden.

Was war denn nun aber das eigentliche Problem bei Hengzzzzt?

Der Unterschied zwischen "foo" und "backup" wird es ja immer noch nicht gewesen sein und ich sehe nicht, wo sich jetzt Deine chmod-/chown-Folge für die "authorized_keys" von dem unterscheidet, was zur Anzeige von

-rwx------- 1 backup backup 403 Dec 8 14:21 authorized_keys

geführt hat.

Also bleibt weiterhin nur die Vermutung, daß da die x-Rechte auf den Verzeichnissen bis zu dieser "authorized_keys" fehlten - die Du ja explizit mit dem chmod für die Gruppe einrichtest, bevor Du die Gruppe änderst.

Ich frage aber u.a. deshalb so hartnäckig nach, weil der SSH-Server offenbar die Identität des Benutzers schon für das Lesen der "authorized_keys" annimmt, denn ansonsten hätte er ja (davon ausgehend, daß der Server selbst als "root" läuft) eher keine Probleme, sich bis dort "durchzuhangeln" (selbst wenn das sicherlich irgendein stat()-Aufruf sein wird). Daß der SSH-Daemon dann die Rechte der "authorized_keys" tatsächlich noch einmal explizit testet, damit da niemand anderes als der User (und root) etwas hineingeschrieben haben kann, ist schon klar ... wieso der Server jetzt wohl gar nicht dorthin gelangte (bzw. ob das überhaupt der Fall war, denn ein "debug"-Lauf ist ja nicht zu sehen), wäre (für mich) immer noch die Frage - dem Bekunden nach soll das Home-Verzeichnis ja auf /var/media/ftp gelegen haben und da haben - sofern man es nicht ändert - "others" auch "rx"-Rechte. Also kann es nur die "eingeschobene Verzeichnisebene" für das Home-Verzeichnis des neuen Benutzers gewesen sein. Beim Anlegen des Benutzers mit "adduser" wird das aber automatisch richtig gemacht für das Home-Verzeichnis, wenn die Option zum Verwenden eines bereits existierenden Verzeichnisses nicht angegeben wurde. Das "adduser" funktioniert ja auch unter Freetz-Bedingungen nur deshalb ohne Fehlermeldung, weil unter /home dort ein Symlink auf ein beschreibbares Verzeichnis liegt.

Wenn das Fazit/der Hinweis am Ende nur lautet: Achtet darauf, daß ihr den Benutzer mit "adduser" hinzufügt oder die Rechte bis zur "authorized_keys" in jedem Falle stimmen, wenn ihr den Benutzer "von Hand" hinzufügt, ist mir das ja auch recht ... wie es Hengzzzzt nun wirklich gemacht hat, kann man ja aus:

hab einen user angelegt auf der fritz.box der sich per ssh ohne pw anmelden soll..

nicht wirklich entnehmen, aber wenn er es mit "adduser" gemacht hat und dabei wurden sowohl Gruppe als auch das richtige Home-Verzeichnis angelegt, erklärt das seine anfänglichen Probleme ja immer noch nicht.

 

[level20peon]

Ich frage aber u.a. deshalb so hartnäckig nach, weil der SSH-Server offenbar die Identität des Benutzers schon für das Lesen der "authorized_keys" annimmt, denn ansonsten hätte er ja (davon ausgehend, daß der Server selbst als "root" läuft) eher keine Probleme, sich bis dort "durchzuhangeln" (selbst wenn das sicherlich irgendein stat()-Aufruf sein wird).

Soweit ich mich erinnern kann nimmt er die Identität des Nutzers als Sicherheitsmaßnahme an, um zu verhindern, dass jeweils andere Nutzer das ~/.ssh Verzeichnis lesen können, in dem neben dem "authorized_keys" nämlich auch private keys abgelegt werden. Wenn der ~/.ssh Ordner die falschen (zu viele) Leserechte hat, weigert der sshd sich, es überhaupt zu lesen.

 

[Hengzzzzt]

hey PeterPawn,

nicht wirklich entnehmen, aber wenn er es mit "adduser" gemacht hat und dabei wurden sowohl Gruppe als auch das richtige Home-Verzeichnis angelegt, erklärt das seine anfänglichen Probleme ja immer noch nicht.

Habe meinen user "backup" mit adduser angelegt, das Homeverzeichnis hatte ich bei späteren Testes auf den Flashspeicher der box geändert, wegen deinem Tipp mit den kaputten Linux Rechten bei NTFS.

Daher denke ich das es wie du schon vermutest an den Rechten lag:

Also bleibt weiterhin nur die Vermutung, daß da die x-Rechte auf den Verzeichnissen bis zu dieser "authorized_keys" fehlten - die Du ja explizit mit dem chmod für die Gruppe einrichtest, bevor Du die Gruppe änderst.

wobei meine Datei jetzt folgende Rechte hat:

-rw-r--r--    1 root     root           403 Jan  8 14:25 authorized_keys

Finaler Tipp wäre dann wohl: user "foo" über adduser anlegen und Rechte wie folgt setzen :

chmod g+rx /home/foo/
chgrp -R foo /home/foo/
chmod 0700 /home/foo/.ssh
chown foo:foo /home/foo/.ssh

und home verzeichnis nicht auf ntfs/fat haben