TS-119 SFTP aktivieren und verbinden?

    Hallo EgLe,


    ja, die Schritte sind so richtig - der Teufel steckt bekanntlich aber im Detail.
    Es freut mich auch, dass die Sache schon so laeuft.


    So, jetzt aber zu der Public-Private-Key Authentifizierung:


    Bei dieser Art der Authentifizierung wird der Benutzer mit einem privaten Schluessel, den er immer verwenden muss, authentifiziert.
    D.h., der Benutzer ist im Besitz seines private key, welcher als einziger schuetzenswert ist. Verliert er ihn, so muss ein neuer Schluessel erstellt werden.
    Der Schluessel sollte nie per Email versandt werden!


    Auf dem Server liegen im Verzeichnis .ssh (oder ~.ssh) in der Datei authorized_keys die oeffentlichen (public) Schluessel, welche eine Art Pendant fuer den private key des jeweiligen Benutzers darstellen.
    Ein public key pro Zeile - Zeilenumbrueche innerhalb des Schluessels sind nicht erlaubt.

    Diese Art der Authentifizierung ist die sicherste, weil Brute Force Angriffe ausgeschlossen sind.
    Besitzt also der Angreifer nicht den richtigen privaten Schluessel, so wird er sofort abgewiesen.


    Es empfiehlt sich, den Schluessel mit einer Passphrase zu schuetzen. Das bedeutet, dass der Benutzer eine Art Kennwort vor der Verwendung des key eingeben muss. Die Passphrase ist ein Kennwort, welches Leerzeichen, Tabs etc. beinhalten darf. Die Laenge ist theoretisch beliebig.


    Was benoetigen wir:


    1. Du brauchst fuer die Erstellung der Schluessel das Putty Tool Puttygen
    2. Fuer das Einfeugen des public-key in die authorized_keys dann noch Putty
    3. Fuer die Verwendung des privaten Schluessels zusammen mit Filezilla wird das Putty-Tool pagent benoetigt - (ebenfalls bei den Putty Tools dabei)
    4. Fuer die Verwendung von WinScp wird pagent nicht benoetigt


    Besorge Dir bitte zuerst die Tools. (z.B. auf der WinScp-Seite)


    Erstellen der Schluessel:


    1. Nach dem Start von Puttygen waehlt man unter Paramters SSH2 RSA aus und vergibt als Schluessellaenge 2048 bits (siehe Number of bits in a generated key)
    (warum nicht "DSA"? Ist eigentlich egal. RSA darf in den USA lizenzrechtlich nicht verwendet werden)
    2. Anschliessend klickt man auf Generate und bewegt die Maus solange, bis die Schluessel erstellt wurden.
    Jetzt sieht man in der mehrzeiligen TextBox schon den public key. Der private key muss explizit ueber den Save private key Button gespeichert werden.
    Aber bevor dies geschieht, sollten ein aussagekraeftiger Kommentar und eine Passphrase vergeben werden. Den Kommentar siehst Du dann z.B. in der auth.log und kannst damit sofort erkennen, welcher Benutzer auf den Server zugegriffen hat. (Das stimmt zwar nicht 100%, weil man oft nur den Fingerprint sieht - das Problem koennen wir aber spaeter mit einem cron job und einem Skript loesen.)


    Speichere also den private key ab.
    Den public key dagegen kopierst Du nur in die Zwischenablage, um ihn anschliessend ueber Cut & Paste im Putty Fenster in die authorized_keys Datei einzufuegen.
    Bitte speichere den Key nicht in einer Datei ab!


    (Falls das Verzeichnis ~.ssh und die Datei authorized_keys nicht existieren - erstelle sie direkt innerhalb des Home-Verzeichnisses. Die Berechtigungen sollen ungefaehr so aussehen: owner ist admin, group ist administrators, chmod 744. Auf jeden Fall benoetigt der Benutzer nur Leserechte auf das Verzeichnis und die Datei. Als Hilfestellung kannst Du auch einen der letzten Screenshots von mir nehmen.)


    Am besten rufst Du die Datei authorized_keys im vi auf (ich weiss, dass Du den vi noch nicht sehr gut kennst - aber Du wirst sehen, dass er nicht nur alt, sondern auch sehr gut ist. Frueher habe ich nur im vi programmieren duerfen - man lernt ihn sehr schnell zu bedienen und zu moegen :-))


    Code
    vi authorized_keys


    Im vi am besten zu Anfang immer die Esc-Taste druecken. Jetzt ist man in einer definierbaren Ausgangssituation aus der man alle Befehle eingeben kann.
    Jetzt die i-Taste fuer den Input druecken und anschliessend mit der rechten Maustaste in das vi-Fenster klicken. Der Text aus der Zwischenablage wird sofort eingefuegt.


    Das Speichern erfolgt so:

    Code
    Esc-Taste druecken
:wq! druecken


    (wq! entspricht: write quite und erzwinge das Speichern falls erforderlich. Falls etwas schief gehen sollte, kannst Du immer Esc druecken und anschliessend :q!. So wird nichts gespeichert und Du darfst von vorne anfangen. ;-))


    Ok. Jetzt haetten wir den public key schon in unserer authorized_keys und den private key in einer beliebigen Windows-Datei (z.B. rsa-20090801.ppt) gespeichert.


    Jetzt kommt nur noch die Anpassung, in der sshd_config und Du kannst die Geschichte ausprobieren.
    Aber mehr dazu demnaechst, weil ich jetzt noch zum Flughafen muss, ich fliege aber noch nicht nach Hause - bin also immer noch nur zu den unmoeglichsten Zeiten erreichbar.


    Viel Erfolg!


    Gruss
    creg

    Hallo creg,


    so habe da ich normal mit dem Windows nichts mehr mache erstmal versucht das ganze
    unter Linux zu machen. Dazu habe ich folgendes gemacht:

    Code
    [~] # ssh-keygen -b 2048 -t rsaGenerating public/private rsa key pair.Enter file in which to save the key (/root/.ssh/id_rsa):/root/.ssh/id_rsa already exists.Overwrite (y/n)? yEnter passphrase (empty for no passphrase):Enter same passphrase again:Your identification has been saved in /root/.ssh/id_rsa.Your public key has been saved in /root/.ssh/id_rsa.pub.The key fingerprint is:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx admin@QNAP-TS119


    Hmm, da kann ich aber kein "Kommentar" mit einfügen wie du meintest das dies wichtig wäre :x


    Also habe ich halt doch das Windows gebootet und das ganze mit Putty gemacht wie du es wolltest.
    Sollte doch aber unter Linux auch möglich sein, oder?


    Den Schlüssel den ich mittels Putty generiert habe lautet nun egle-qnap-key.ppk.


    Habe nun mal unter dem User egle eine ~authorized_keys erstellt mittels vi und
    habe dann auch das ~.ssh erstellt wie hier angegeben:

    Code
    [~] # cd /home/egle
[/home/egle] # mkdir .ssh
[/home/egle] # chown -R egle:administrators .ssh
[/home/egle] # chmod 744 .ssh
[/home/egle] #


    Muss man jetzt eigentlich für jeden User einen eigenen Key erzeugen,
    oder wird dieser nun für alle verwendet?


    Gruß EgLe

    Hallo EgLe,


    natuerlich kannst Du das mit Linux machen, weil das keine Rolle spielt. Aber grundsaetzlich solltest Du immer den schnellsten Weg nehmen - nicht den schwierigsten.


    Also unter Linux kannst Du beim ssh-keygen fuer das Erstellen von Kommentaren in Keys die Option -C verwenden.
    Hier die Syntax:

    Code
    ssh-keygen -c [-P passphrase] [-C comment] [-f keyfile]


    Bsp:

    Code
    ssh-keygen -b 2048 -t rsa -N MeinePassphrase -C MeinKommentar -f /home/monika/~ssh/mein-key


    (Der public key wird jetzt mein-key.pub heissen. Beide Schluessel werden also gleichzeitig erstellt.)


    Die Syntax:

    Code
    ssh-keygen [-b bits] -t type [-N new_passphrase] [-C comment][-f output_keyfile]


    Zitat

    Muss man jetzt eigentlich für jeden User einen eigenen Key erzeugen,
    oder wird dieser nun für alle verwendet?


    Nein, nicht unbedingt. Auch mehrere Benutzer koennen den gleichen Schluessel verwenden, allerdings wirst Du ihre Logins nicht unterscheiden koennen. Geht der Schluessel verloren oder wird kompromittiert, musst Du allen Benutzern einen neuen Schluessel zukommen lassen. :(


    Wie weit bist Du jetzt genau?


    Wenn Deine Schluessel fertig sind, kannst Du schon mal die sshd_config etwas abaendern:

    Code
    LoginGraceTime 2m #Anmeldezeit, entspricht 2 min.PermitRootLogin no #Root kann sich jetzt nicht mehr anmelden. Verwende einen normalen Benutzer und fuehre nach der Amledung: sudo rootMaxAuthTries 1#ein anderer Wert macht bei Key-Authentication keinen SinnPubkeyAuthentication yes #Ab jetzt geht nur noch Key-AuthenticationAuthorizedKeysFile .ssh/authorized_keysRSAAuthentication noPasswordAuthentication no#siehe PubkeyAuthenticationUsePAM noKerberosAuthentication noGSSAPIAuthentication noMaxStartups 2 #Max. Anzahl an nicht authentifizierten Verbindungen. Bei Angriffen (welche jetzt eigentlich ausgeschlossen sind) ist dieser Wert besonders wertvoll


    Beachte bitte, dass nach der Umstellung und dem Restart Deines Systems kein Ameldung durch den Benutzer admin moeglich ist. D.h. nicht direkt moeglich ist.
    Das bedeutet also, dass Du auch noch die Schluessel fuer einen normalen Benutzer, z.B. EgLe erstellen musst, denn nur ueber diesen Benutzer kannst Du Dich ab jetzt als admin anmelden.


    Also...
    1. Du meldest Dich z.B. als EgLe an... und wirst ueber Deinen private key authentifiziert
    2. Jetzt tippst Du auf der Shell folgendes ein

    Code
    su - admin


    3. Erst jetzt kannst Du Dich als admin mit dem dazugehoerigen Kennwort authentifizieren.


    Solltest Du Dich aus welchem Grund auch immer ausgesperrt haben, dann kannst Du ueber Telnet auf die Maschine drauf. Man kann den Telnet ueber die Weboberflaeche einschalten. Allerdings solltest Du den Telnet-Zugang abschalten - er ist unsicher (d.h. nicht ueber das Internet verwenden).


    Noch etwas zum Portforwarding fuer den Zugriff uber das Internet:


    Stelle fuer Deinen Router Portforwarding ein. D.h. Dein Router soll nicht auf Port 22 reagieren. Schalte irgend eine hohe Portnummer ein (z.B. 47610) und leite diese auf Port 22 um. Damit sind schon mal die meisten script kiddies ausgeschlossen. Du wirst sehen, dass Dein Server mit all diesen Einstellungen sehr sicher ist. (Auch wenn man ihn noch etwas sicherer machen koennte - aber dies ist dann meist mit sehr viel Paranoia verbunden.)


    Gruss
    creg

    Hallo creg,


    war jetzt auch noch übers Wochenende in der Schweiz,
    von daher kann ich jetzt erst weitermachen ;)


    So habe für jeden User einen Schlüßel erstellt und habe diesen dann auch entsprechend
    den Usern zugewiesen, und die Box rebootet.


    Schreck lass nach ich konnte mich erst nicht einloggen :oops:


    Habe aber dann für meine keys:
    - egle-qnap-key
    - egle-qnap-key.pub
    dann jeweils einen Symlink erstellt:

    Code
    egle@AMD64-X2-6000:~/.ssh$ ln -s egle-qnap-key id_rsaegle@AMD64-X2-6000:~/.ssh$ ln -s egle-qnap-key.pub id_rsa.pub


    Nun ging das einloggen mittels Fingerprint auch wieder :D

    Code
    egle@AMD64-X2-6000:~$ ssh egle@qnap -vOpenSSH_4.7p1 Debian-8ubuntu1.2, OpenSSL 0.9.8g 19 Oct 2007debug1: Reading configuration data /etc/ssh/ssh_configdebug1: Applying options for *debug1: Connecting to qnap [192.168.0.5] port 22.debug1: Connection established.debug1: identity file /home/egle/.ssh/identity type -1debug1: identity file /home/egle/.ssh/id_rsa type 1debug1: identity file /home/egle/.ssh/id_dsa type -1debug1: Remote protocol version 2.0, remote software version OpenSSH_5.2debug1: match: OpenSSH_5.2 pat OpenSSH*debug1: Enabling compatibility mode for protocol 2.0debug1: Local version string SSH-2.0-OpenSSH_4.7p1 Debian-8ubuntu1.2debug1: SSH2_MSG_KEXINIT sentdebug1: SSH2_MSG_KEXINIT receiveddebug1: kex: server->client aes128-cbc hmac-md5 nonedebug1: kex: client->server aes128-cbc hmac-md5 nonedebug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sentdebug1: expecting SSH2_MSG_KEX_DH_GEX_GROUPdebug1: SSH2_MSG_KEX_DH_GEX_INIT sentdebug1: expecting SSH2_MSG_KEX_DH_GEX_REPLYdebug1: Host 'qnap' is known and matches the RSA host key.debug1: Found key in /home/egle/.ssh/known_hosts:2debug1: ssh_rsa_verify: signature correctdebug1: SSH2_MSG_NEWKEYS sentdebug1: expecting SSH2_MSG_NEWKEYSdebug1: SSH2_MSG_NEWKEYS receiveddebug1: SSH2_MSG_SERVICE_REQUEST sentdebug1: SSH2_MSG_SERVICE_ACCEPT receiveddebug1: Authentications that can continue: publickey,keyboard-interactivedebug1: Next authentication method: publickeydebug1: Trying private key: /home/egle/.ssh/identitydebug1: Offering public key: /home/egle/.ssh/id_rsadebug1: Server accepts key: pkalg ssh-rsa blen 277debug1: read PEM private key done: type RSAdebug1: Authentication succeeded (publickey).debug1: channel 0: new [client-session]debug1: Entering interactive session.debug1: Sending environment.debug1: Sending env LANG = de_DE.UTF-8[egle@QNAP-TS119 ~]$


    Jedoch als Admin selbst geht das aber nicht mehr, auch nicht wie du geschrieben hast:


    Code
    [egle@QNAP-TS119 ~]$ sudo su-sh: sudo: command not found[egle@QNAP-TS119 ~]$ su-sh: su: command not found[egle@QNAP-TS119 ~]$


    Oder hätten wir für den Admin auch nochmals einen eigenen Schlüssel
    erstellen müssen wie bei den Usern selbst???


    Dann würde ja dieses funktionieren:


    Da ich ja meinen User egle nicht in einer Jail gefangen habe, und dieser
    auch der Gruppe der Admins angehört kann ich also aber auch weiter dran rumkonfigurieren...


    Oder ich lasse eben das Telnet offen (im Privaten Lan) dann kann ich natürlich
    auch übers Telnet mich als admin anmelden.


    So sieht der Stand der Dinge zur Zeit bei mir aus.


    Das bedeutet ich müsste jetzt wissen was wir mit dem Admin machen.
    Und wie ich den die Authentifizierung bei den Windowsrechner hinbekomme,
    bei einem Linuxsystem sollte das ja so gehen wie ich das mit dem User egle schon getan habe....


    Gruß EgLe

    Hallo EgLe,


    1. Admin-Anmeldung


    die Anmeldung des Benutzers admin sollte funktionieren, wenn Du nach einer erfolgreichen Ameldung mit dem Benutzerkonto "egle" (egle muss dabei kein administrator sein) den unten stehenden Befehl auf der Shell ausfuehrst:


    Code
    su - admin


    Wichtig ist dabei, dass "admin" unter AllowedUsers in der sshd_config steht.


    2. Public Key


    Den public key musst Du nicht verlinken. Du kannst ihn in die Datei authorized_keys des .ssh-Verzeichnisses hinein kopieren. (Falls die Datei nicht da sein sollte, dann erstelle sie).


    Das musst Du uebrigens fuer alle Deine Benutzer tun. Z.B. fuer monika in die Datei /home/monika/.ssh/authorized_keys


    Wichtig: In die Datei authorized_keys kommen nur die public keys hinein. Die private keys werden im WinSCP verwendet.
    D.h. die authorized_keys kann einen oder mehrer public keys enthalten. Mehrer Schluessel werden z.B. verwendet, wenn auf eine Chroot-Verzeichnis eine Benutzergruppe (mehrere physikalische Benutzer) zugreifen sollte.


    Bsp: Alfred, Monika und Egon sollten mit dem Benutzer sftzugang auf das Chroot-Verzeichnis /home/sftzugang zugreifen koennen. Die public keys der drei Benutzer kommen alle in die Datei /home/sftzugang/.ssh/authorized_keys
    Der jew. Benutzer selbst verwendet in seinem WinSCP seinen privaten Schluessel.


    3. Was machen die Windows-Benutzer


    Zitat

    Und wie ich den die Authentifizierung bei den Windowsrechner hinbekomme


    Ich nehme an, dass Du Chroot-Benutzer meinst. Sie verwenden das Programm WinSCP.
    Die Konfiguration ist denkbar einfach: Siehe Screenshot.


    Falls Du aber PAM meinst, dann muessen wir erst in ca. 2 Wochen darueber reden, weil ich noch solange unterwegs bin und ohne eines Unix-Systems das nicht beschreiben kann.


    4. Telnet im LAN


    Ich denke, dass hier keine Gefahr (oder nur eine sehr geringe Gefahr) besteht. Kannst also verwenden.


    Gruss
    creg

    Hallo creg,



    Ja das meinte ich, das dies bei mir eben nicht funktioniert, weiß nicht warum???

    Code
    [egle@QNAP-TS119 ~]$ su - admin-sh: su: command not found[egle@QNAP-TS119 ~]$


    Zitat von "creg"


    2. Public Key


    Den public key musst Du nicht verlinken. Du kannst ihn in die Datei authorized_keys des .ssh-Verzeichnisses hinein kopieren. (Falls die Datei nicht da sein sollte, dann erstelle sie).


    Ja das habe ich gemacht, das mit dem verlinken meinte ich auf meinem Linux-PC damit
    bei der Anmeldung auch meine eigens erstellte Schlüsseln verwendet werden.
    Sieht man ja bei der Anmeldung mit dem Paramater -v wo er diese sucht ;)

    Code
    debug1: Trying private key: /home/egle/.ssh/identity
debug1: Offering public key: /home/egle/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).


    So wie das ganze Ausieht bis auf dem Punkt Admin-Anmeldung per ssh scheint alles zu laufen.
    muss das nochmals mit ein zwei anderen Rechner bzw. Betriebsystemen durchprobieren,
    dann werde ich mal den Port öffnen und das ganze von meinen Freunden durch spielen lassen
    ob die den Zugriff hin bekommen oder nicht ;)

    Hallo EgLe,



    Zitat

    Ja das meinte ich, das dies bei mir eben nicht funktioniert, weiß nicht warum???


    Gut - ich habe die Shellausgabe ueberlesen -, dann installier es nach. Das Kommando befindet sich in coreutils.
    coreutils kann man einfach ueber ipkg nachinstallieren.
    Dann duerfte die Anmeldung funktionieren.


    Gruss
    creg

    @ EGLE


    Sry für das kuddel muddel, ich habe wohl einmal zuviel editiert. Ich wollte eure Diskussion nur ungern unterbrechen aber Doppelpost sind leider nicht erlaubt daraus resultierte dann mein Fehler beim editieren. Sorry nochmal.


    Christian


    Hallo creg,


    Zitat von "creg"


    Gut - ich habe die Shellausgabe ueberlesen -, dann installier es nach. Das Kommando befindet sich in coreutils.
    coreutils kann man einfach ueber ipkg nachinstallieren.


    So habe mich per Telnet auf die Box als admin eingeloggt und dies installiert:

    Code
    ipkg install coreutils


    Nun klappt das mit dem wechslen zum admin aus der ssh herraus auch :thumb:


    So dann muss ich jetzt nur noch meinen Freunden den Schlüssel bringen
    und sehen ob die sich einloggen können...


    Ich muss mich hier nochmals ausdrücklich bei Dir bedanken für die super Hilfe :thumb:


    Melde mich dann ob alles soweit klappt und funktioniert, sobald es extern getestet wurde :D


    Gruß EgLe


    EDIT 2:


    Hallo creg,


    der Zugriff funktioniert nun auch extern (mit einem Freund getestet) :D
    da er Windows benutzt musste er aber meine Openssh-keys die ich ihm
    geben habe (unter Linux erstellt) aber erst noch mit dem Putty in das Putty-Format
    umwandeln damit dieser in WinSCP verwendet werden konnte.


    Was mir aber dabei nun aufgefallen ist, ist das ich im Webinterface
    der Qnap diese Verbindungen nicht angezeigt bekomme.
    Im Webinterface werden wohl keine SSH-Zugriffe aufgelistet.
    So wie ich das sehe werden dort mir dort nur NFS und HTTP Zugriffe angezeigt.


    Denke mal das ich das dann wohl über das Syslog machen muss?



    Gruß EgLe

    Hallo EgLe,


    bitte sehr. Es freut mich, dass alles funktioniert.


    Zitat

    Was mir aber dabei nun aufgefallen ist, ist das ich im Webinterface
    der Qnap diese Verbindungen nicht angezeigt bekomme.
    Im Webinterface werden wohl keine SSH-Zugriffe aufgelistet.
    So wie ich das sehe werden dort mir dort nur NFS und HTTP Zugriffe angezeigt.


    Denke mal das ich das dann wohl über das Syslog machen muss?


    Hmm, das stimmt. Die eigentlichen Logs findest Du nur in der Auth.log-Datei. (zumind. bei mir - ich verwende den syslog-ng - das duerfte allerdings egal sein.)


    Die Loesung des Problems koennte so aussehen, dass ich Dir ein Skript von mir zukommen lasse, welches Deine Auth.log auswertet und Dir bei Anmeldungen ueber (sshd) eine entsprechende Email zukommen laesst. (Die wuerde ueber einen Cron-job geschehen. Die Inhalte der Log, wie z.B. die Fingerprints sind dabei unkenntlich gemacht, man kann aber zu jedem Fingerprint einen logischen Namen zuordnen - so etwas wie einen Alias.)


    Wenn Du das haben moechtest, kann ich Dir das erst in ca. 10 Tagen hier posten oder per Mail schicken.
    Bin immer noch im Urlaub.


    Gruss
    creg

    Hallo creg,


    Zitat von "creg"

    Hallo EgLe,


    Die Loesung des Problems koennte so aussehen, dass ich Dir ein Skript von mir zukommen lasse, welches Deine Auth.log auswertet und Dir bei Anmeldungen ueber (sshd) eine entsprechende Email zukommen laesst. (Die wuerde ueber einen Cron-job geschehen. Die Inhalte der Log, wie z.B. die Fingerprints sind dabei unkenntlich gemacht, man kann aber zu jedem Fingerprint einen logischen Namen zuordnen - so etwas wie einen Alias.)


    Wenn Du das haben moechtest, kann ich Dir das erst in ca. 10 Tagen hier posten oder per Mail schicken.
    Bin immer noch im Urlaub.


    Das wäre wirklich wunderbar, und würde mich freuen wenn man dies auch noch hin bekommen würde ;)
    Naja anstatt die Fingerprints könnte man ja einfach den Schluss der Schlüssel hernehmen.
    So wie ich gesehen habe enden die ja bei mir alle so in dieser Art:


    * == egle@gnap-key
    * == alex@gnap-key
    * == rainer@gnap-key
    .......


    Aber ich denke du hast Hier in deinem Urlaub echt viel geholfen, nicht nur mir
    von dem Thread werden hoffentlich auch noch einige andere Profitieren :D


    Wünsch Dir einen Schönen erholsamen Urlaub, auch wenn wir mittlerweile bei uns auch
    33° Grad haben und für morgen sind sogar 37°Grad gemeldet :)


    Gruß Egle

    Servus,


    toller, konstruktiver Thread.
    Da könnte man fast ein HowTo daraus machen.
    So ähnlich werde ich meine Box demnächst auch ummodeln ...


    Grüße,
    Case

    Hallo EgLe,



    Zitat

    Naja anstatt die Fingerprints könnte man ja einfach den Schluss der Schlüssel hernehmen.


    Wenn dieser Teil bei Dir protokolliert wurde, dann ist es moeglich.
    Das Skript verwendet von Dir definierte Aliases. Z.B. bei mir fuer die Fingerprints, denn diese sind immer einmalig und man kann sie so einfach nicht faken.


    Bsp: Wenn ein Fingerprint, wie z.B. 69:ad:a2.... gefunden wird, wird er abgeschnitten und um einen Kommentar ergaenzt (als Prefix).
    In dem unteren Beispiel also um den Vornamen des Benutzers und die ersten 2 Buchstaben seines Nachnamens.
    D.h. Du kannst beliebig viele Zeichenkette durch andere ersetzen lassen.



    Gruss
    creg

    Hallo creg,


    du sollst doch nun erstmal deinen Urlaub geniesen :D


    Da ich mir nun die neue Firmaware installiert habe und meine Festplatte doch noch mal
    neu formatiert habe (nun Ext4) und einige Verzeichnisse anderst gemacht habe ist mir
    nun noch ein kleiner Fehler aufgefallen ;)


    Auf der ersten Seite der 4. Beitrag von Dir schriebst du folgendes:


    Zitat von "creg"


    (jetzt wird das Home-Verzeichnis in Form eines SymLinks (also einer Verknüpfung) angelegt)


    cd /home
    ln -s /home/usr-freund /share/HDA_DATA/home/usr-freund


    Hmm, da ich mich ja durch mein Linux und meinen Dreamboxen etwas mit Symlinks
    auskenne ist mir der Fehler erst nicht aufgefallen :)


    Zuerst muss der tatsächliche Pfad angegeben werden und dann der wo der Symlink erstellt wird.
    Gehört also einfach gedreht die Befehlszeile....


    Könntest du diesen Beitrag von Dir evtl. editieren, damit andere die den Thread als Hilfe bzw.
    Anleitung nehmen, sich nicht wundern warum bei denen unter /home keine Symlinks zu den
    User-Homeverzeichnise erstellt werden :D


    Ansonsten scheint die Anleitung soweit völlig Okay zu sein, könnte die also
    (zwar mit viel Aufwand) Problemlos nachvollziehen.....


    PS: das mit dem mitloggen machen wir aber bitte erst nach deinem Urlaub,
    sonst habe ich wirklich ein schlechtes Gewissen :oops:


    Gruß EgLe

    Hallo EgLe,


    ja, Du hast Recht, hier liegt tatsaechlich ein Fehler vor.
    Der Fehler wird von Christian (Forumsadministrator) korrigiert.


    Wenn Du mehr Infos zum Logging etc. brauchst, dann melde Dich einfach.


    Gruss
    creg

    Hallo Creg,


    vielen Dank für das Angebot, würde das natürlich dann auch wahrnehmen :D


    Die Frage ist aber ob man es hier im Thread dann mit machen sollte, oder evtl.
    einen eigenen Thread für Logging erstellen sollte?


    Weil ja das Logging selbst ja nichts mehr direkt mit dem Betreff selbst zu tun hat :oops:

    Hallo,


    so ich habe mal zu diesem Thema eine Anleitung (Wiki) geschrieben.
    Denke das dies ja das mindeste ist wie ich etwas von der Hilfe hier, (besten Danke an Creg)
    an die Internet-Gemeinschaft zurückgeben kann.....


    Hier das Original, denke das es besser zu lesen ist?


    http://wiki.blue-panel.com/ind…H_einrichten_mit_Qnap-NAS


    Und hier mein Versuch das auch in das Qnap-Wiki einzupflegen...
    Leider sind die verschiedenen Wiki-(Formate) doch nicht alle gleich und in die Englischsprachige Hilfe
    dazu lese ich mich sehr schlecht rein.


    Evtl. hat ja einer Lust das ein klein wenig Nachzuarbeiten auch mit den Kategorieren usw???


    http://wiki.qnap.com/wiki/SFTP…ehrere_Benutzer_errichten


    Hoffe auch das es Creg gut geht, war ja schon eine weile nicht mehr Online.




    Aber evtl. hat ja einer auch noch eine Idee dazu???


    Habe mal wieder mit der Firmware rumgespielt, und damit ich die WIki schreiben konnte
    alles auf Werkseinstellung zurückgesetzt um das ganze auch beim schreiben selbst nochmals zu testen.


    Irgendwie erhalte ich aber nun (nachdem die Konfiguration schon zweimal geklappt hat) beim dritten Versuch
    immer folgende Meldung:


    Code
    egle@AMD64-X2-6000:~$ ssh egle@qnap
Received disconnect from 192.168.0.5: 2: Too many authentication failures for egle


    Doch an was das liegt finde ich nicht :roll:

    Hallo,


    also ich komme mit meinem eigenen User nicht weiter :(


    Wenn ich mich mit diesem einloggen will nimmt er nicht die ssh-keydatei bekomme immer folgende Meldung:


    Code
    egle@AMD64-X2-6000:~$ ssh egle@192.168.0.5 -vOpenSSH_4.7p1 Debian-8ubuntu1.2, OpenSSL 0.9.8g 19 Oct 2007debug1: Reading configuration data /etc/ssh/ssh_configdebug1: Applying options for *debug1: Connecting to 192.168.0.5 [192.168.0.5] port 22.debug1: Connection established.debug1: identity file /home/egle/.ssh/identity type -1debug1: identity file /home/egle/.ssh/id_rsa type 1debug1: identity file /home/egle/.ssh/id_dsa type -1debug1: Remote protocol version 2.0, remote software version OpenSSH_5.2debug1: match: OpenSSH_5.2 pat OpenSSH*debug1: Enabling compatibility mode for protocol 2.0debug1: Local version string SSH-2.0-OpenSSH_4.7p1 Debian-8ubuntu1.2debug1: SSH2_MSG_KEXINIT sentdebug1: SSH2_MSG_KEXINIT receiveddebug1: kex: server->client aes128-cbc hmac-md5 nonedebug1: kex: client->server aes128-cbc hmac-md5 nonedebug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sentdebug1: expecting SSH2_MSG_KEX_DH_GEX_GROUPdebug1: SSH2_MSG_KEX_DH_GEX_INIT sentdebug1: expecting SSH2_MSG_KEX_DH_GEX_REPLYdebug1: Host '192.168.0.5' is known and matches the RSA host key.debug1: Found key in /home/egle/.ssh/known_hosts:2debug1: ssh_rsa_verify: signature correctdebug1: SSH2_MSG_NEWKEYS sentdebug1: expecting SSH2_MSG_NEWKEYSdebug1: SSH2_MSG_NEWKEYS receiveddebug1: SSH2_MSG_SERVICE_REQUEST sentdebug1: SSH2_MSG_SERVICE_ACCEPT receiveddebug1: Authentications that can continue: publickey,password,keyboard-interactivedebug1: Next authentication method: publickeydebug1: Trying private key: /home/egle/.ssh/identitydebug1: Offering public key: /home/egle/.ssh/id_rsadebug1: Authentications that can continue: publickey,password,keyboard-interactivedebug1: Trying private key: /home/egle/.ssh/id_dsadebug1: Next authentication method: keyboard-interactivedebug1: Authentications that can continue: publickey,password,keyboard-interactivedebug1: Next authentication method: passwordegle@192.168.0.5's password:


    Mittels Passwort komme ich dann rein (habe diese Option zur Zeit noch zusätzlich aktiviert).


    Habe auch schon neue Schlüssel erstellt und getestet immer das gleiche :(



    Melde ich mich als admin an (habe ich zur Zeit auch wieder aktiviert) geht das ganze.
    Ich wechsle in meinem Linux zum admin mittels:


    Code
    sudo su


    und verbinde mich dann erfolgreich zur Box:



    Das ganze habe ich auch mit einem meiner Freunde die Windows benutzen versucht.
    Dieser kommt auch mittels WinSCP und Putty mit seinem Schlüssel auf die Box.


    Nur eben nicht ich mit meinem eigenen Benutzer, jemand eine Idee?

    Hallo,


    so habe die Lösung nun doch noch selbst gefunden...


    Hatte vergessen in der /etc/passwd den Pfad des Useres aufs Homeverzeichnis zu setzten :oops:
    Habe ja schon wirklich selbst an mir gezweifelt, sorry für die unnötigen Postings.
    Denke mir nur das dies evtl. als Tipp für andere gut sein kann, wenn es denn genauso klemmt...


    Also funktioniert doch "perfect", habe das ganze jetzt insgesamt 3x mal durchgespielt.

    Hallo!


    Habe alles so wie in Howtodo beschrieben gemacht, komme aber nciht mit meinen erstellten Usern per Putty aufs NAS.


    Der merkt sich auch nciht die Einträge ind er sshd_config.


    Danke

    Hallo Ihr!


    SApitz: Hast Du wirklich ein Qnap mit einer Festplatte? Oder evtl ein Raid? Wenn Raid, dann stimmt vielleicht der Pfad /etc/ssh/sshd_config /share/HDA_DATA/custom/sshd_config nicht. Beim Raid wäre das nicht HDA_DATA sondern vielleicht MD0_DATA ...


    Den Fehler hatte ich gemacht!


    An dieser Stelle auch nochmal vielen Dank an creg und EgLe - vielen Dank für Eure Mühe. Dank Euch habe ich es auch hinbekommen. :)


    Gibt es bezüglich des loggings schon was neues? Das ist etwas, wa noch sehr verbesserungswürdig ist?! Wenn ich mich per ssh auf's QNAP einlogge funktioniert noch nichtmal "users" ... Ich bin nicht der Linux-Spezi, dass ich sowas selber regeln könnte. :( Wenn ich - egal wo, Forum, Google - nach "users" suche, dann brauche ich Euch nicht erzählen, was für Suchergebnisse ich bekomme. Es war auf jeden Fall noch nichts hilfreiches ddabei ...


    Bin auch für jede Hilfe dankbar!


    Ciao,
    SmartC