Jemand Erfahrungen mit NetBSD gemacht ? Konkrete Frage zu SFTP Server Einrichtung...

  • Hallo,


    vielleicht gibt es ja jemand, der nicht nur Linux kennt, sondern spezieller auch NetBSD. Habe die aktuelle 9.2 auf einem Phenom X4 System installiert, aber stehe momentan auf dem Schlauch was "Paketmanagement" bei NetBSD angeht, und im Speziellem bzgl. der Einrichtung eines SFTP Servers (ein passendes x509 Zertifikat habe ich).


    Gruß Peter

    "The biggest communication problem is we do not listen to understand. We listen to reply." - Stephen Covey


    Webseite und Blog ist immer noch - seit fast 20 Jahren - online.


  • http://www.pkgsrc.org/

    nach dem da (quickstart) installiert man mit "pkg_add" und einer Pfadvariabeln das Programm "pkgin" - und das benutzt man dann als Paketmanager.



    Paketliste ist da http://cdn.netbsd.org/pub/pkgsrc/current/pkgsrc/

    (pkgsrc steht dabei anscheinend nicht für "Quellcode" sondern für "Quelle")

    -- 1982 gab es keinen Raspberry Pi , aber Pi und Raspberries

  • Ich benutze schon ewig NetBSD, allerdings inzwischen nur noch ältere Versionen.


    Paketmanagement geht per pkgsrc bzw. pkgin für Binärpakete. SSH / SFTP sollte teil des Grundsystems sein (war zumindest immer so.) In dem Fall musst du einfach nur in /etc/rc.conf die entsprechende Variable setzen (sshd=YES) damit der server beim booten startet bzw. sich per /etc/rc.d/sshd start starten lässt.

    Suche: SGI Indigo (gerne IP12), DEC/DIGITAL CRT Monitor und ein VT240 (inkl. Monitor).

  • Ok, ssh bzw. der daemon sshd ist natürlich wichtig, weil SFTP ja SSH als Transportprotokoll nutzt. Aber gibt es auch ein dedizierten daemon für sftp, also sftpd oder so was ähnliches, und gibt es so was wie eine sftp_config (oder eben nur die sshd_config) oder ist quasi die ganze Logik im sshd enthalten und man benötigt dann nur noch ein sftp Client ?

    "The biggest communication problem is we do not listen to understand. We listen to reply." - Stephen Covey


    Webseite und Blog ist immer noch - seit fast 20 Jahren - online.

    • Offizieller Beitrag

    So ist das zumindest bei Linux; die sshd-Konfiguration bei NetBSD sollte zeigen, ob das dort auch so ist.

    Denn Feindschaft wird durch Feindschaft nimmermehr gestillt; Versöhnlichkeit schafft Ruh’ – ein Satz, der immer gilt. Man denkt oft nicht daran, sich selbst zurückzuhalten; Wer aber daran denkt, der lässt den Zorn erkalten. Sprüche von Buddha, aus dem ‹Dhammapada›.


    Mein Netz: Acorn | Atari | Milan | Amiga | Apple //e und IIGS | Macintosh | SUN Sparc | NeXT |SGI | IBM RS/6000 | DEC Vaxstation und Decstation| Raspberry Pi | PCs mit OS/2, BeOS, Linux, AROS, Windows, BSD | Stand-alone: Apple //c und III | Commodore 128D | Sinclair QL | Amstrad | PDAs

  • ein X.509-Zertifikat benötigst Du für FTP-S (FTP over TLS). Für SFTP / SSH eigentlich nicht, Du brauchst (d)einen Public Key (im OpenSSH-Format), wenn Du dich mittels PublicKey-Authentication (also ohne Kennworteingabe) anmelden willst.

    Bei uns in der Firma (SuSE und RHEL) wird eigentlich immer der "interne" SFTP-Dienst (Subdienst SSHd) verwendet, wenn wir geCHROOTetes SFTP machen, nicht der externe.

    • Offizieller Beitrag

    Der sshd von NetBSD macht auch sftp: https://man.netbsd.org/NetBSD-5.0/sshd_config.5

    Denn Feindschaft wird durch Feindschaft nimmermehr gestillt; Versöhnlichkeit schafft Ruh’ – ein Satz, der immer gilt. Man denkt oft nicht daran, sich selbst zurückzuhalten; Wer aber daran denkt, der lässt den Zorn erkalten. Sprüche von Buddha, aus dem ‹Dhammapada›.


    Mein Netz: Acorn | Atari | Milan | Amiga | Apple //e und IIGS | Macintosh | SUN Sparc | NeXT |SGI | IBM RS/6000 | DEC Vaxstation und Decstation| Raspberry Pi | PCs mit OS/2, BeOS, Linux, AROS, Windows, BSD | Stand-alone: Apple //c und III | Commodore 128D | Sinclair QL | Amstrad | PDAs

  • Habe mit ssh-keygen mir ein Schlüsselpaar erzeugt (steht ja normalerweise in ~/.ssh ).

    Aber dann bin ich abgehängt, finde ein Hinweis auf ssh-copy-id, das bringt mir aber sofort einen Fehler.

    O-Ton der Anleitung: After generating a new key, you need to add the public key to the file ~/.ssh/authorized_keys


    Kapiere auch nicht, was ich mit dem "public" Schlüssel dann bspw. mit FileZilla anfange. Kann man die .pub Datei dort irgendwo angeben ?


    P.S.: Ah... sehe gerade da gibt es ein "add file" beim Menüpunkt Connection->SFTP, damit wäre zumindest klar wo ich es bei FileZilla angebe. Allerdings erwartet wird da eine Schlüsseldatei in einem anderen Dateiformat ...

    "The biggest communication problem is we do not listen to understand. We listen to reply." - Stephen Covey


    Webseite und Blog ist immer noch - seit fast 20 Jahren - online.

    Einmal editiert, zuletzt von Peter z80.eu ()

    • Offizieller Beitrag

    Der Public Key Deines Clients gehört (wie in der Anleitung gesagt) auf den Server, den Du per Filezilla ansprechen willst und dort in die .ssh/authorized_keys Datei des Users, auf den Du dann sftp machen willst. Die Datei ist eine einfache Textdatei, in der zeilenweise die Keys stehen.


    Die Public Key Datei muss einfach irgendwie von Deinem Client zum Server kommen, im Zweifelsfall einmalig mit Username/Passwort-Authentifizierung und scp, ftp oder sftp.


    Wo FileZilla auf dem Client den Private Key erwartet, weiss ich aber nicht. Wäre es ssh, wäre $HOME/.ssh/id_rsa der richtige Ort (darf nur für den User les/schreibbar sein).

    Denn Feindschaft wird durch Feindschaft nimmermehr gestillt; Versöhnlichkeit schafft Ruh’ – ein Satz, der immer gilt. Man denkt oft nicht daran, sich selbst zurückzuhalten; Wer aber daran denkt, der lässt den Zorn erkalten. Sprüche von Buddha, aus dem ‹Dhammapada›.


    Mein Netz: Acorn | Atari | Milan | Amiga | Apple //e und IIGS | Macintosh | SUN Sparc | NeXT |SGI | IBM RS/6000 | DEC Vaxstation und Decstation| Raspberry Pi | PCs mit OS/2, BeOS, Linux, AROS, Windows, BSD | Stand-alone: Apple //c und III | Commodore 128D | Sinclair QL | Amstrad | PDAs

  • das ~/.ssh-Verzeichnis deines Benutzers auf dem server muß Rechte 0700 haben und dem Benutzer gehören. Die ~/.ssh/authorized_keys sollte auch auf 0600 stehen. Eventuell mußt Du einen Forwarding-Agent wie z.B. beim PuTTY der pageant starten und dort den (Public) Key laden.

    Beim PuTTY starte ich den Client dann immer mit "-v", "-v -v", oder gar "-v -v -v" dann gibt's jede Menge Debugging-Output. Auf dem (Linux-)Server entweder die /var/log/messages (initd) oder mit "journalctl -x -e" (systemd) als root nach den Meldungen suchen - z.B. nach dem Benutzernamen.

    Da sieht man dann auch, ob der Benutzer überhaupt in sein Homeverzeichnis darf ^^

  • Ich würde erstmal den FileZilla oder sonstwas für Client vergessen und den NetBSD Server so konfigurieren dass das PublicKey login vom Server auf sich selbst klappt. Dazu als root:

    1) in /etc/rc.conf sshd=YES setzen

    2) /etc/rc.d/sshd start

    dann als normaler Nutzer:

    3) per ssh-keygen Schlüssel erzeugen (in .ssh/id_rsa{,.pub})

    4) dann ssh 127.0.0.1 testen (mit Kennwort), das sollte gehen

    5) die .ssh/id_rsa.pub kopieren nach .ssh/authorized_keys

    6) mit ssh 127.0.0.1 sollte jetzt Login ohne Kennwort gehen.


    Auf diese Weise werden auch die Permissions automatisch richtig gesetzt wie von Cpt_Void beschrieben. Falsch sind die normalerweise aber auch nur wenn man Home-Verzeichnisse unvorsichtig umher kopiert.


    Wenn das oben soweit funktioniert und du dich auch mit FileZilla mit Kennwort einloggen kannst, dann kommt jetzt der Public Key vom Client (und zwar der User Public Key) auf den Server.


    Da FileZilla selbst kein User Key Pair erzeugt, müsstest du:

    1) wieder auf dem NetBSD Server ein weiteres Paar erzeugen. Also wieder mit ssh-keygen, allerdings diesmal einen anderen Pfad angeben damit die .ssh/id_rsa{,.pub} nicht überschrieben werden, z.B. ~/id_rsa_filezilla.

    2) Auf dem Server ~/id_rsa_filezilla.pub nach .ssh/authorized_keys kopieren. Ruhig überschreiben, es gibt keinen guten Grund die oben zum Testen angelegte .ssh/authorized_keys Datei zu behalten.

    3) Auf dem Server die Schlüssel in das antiquierte PEM Format umwandeln: ssh-keygen -f id_rsa_filezilla.pub -e -m pem > id_rsa_filezilla_pem.pub und openssl rsa -in id_rsa_filezilla -outform pem > id_rsa_filezilla_pem

    4) Die gerade erstellten id_rsa_filezilla_pem{,.pub} Dateien mit FileZilla kopieren. (Dazu brauchst du jetzt noch das Kennwort.)

    5) FileZilla so konfigurieren dass dein gerade kopiertes id_rsa_filezilla_pem{,.pub} Schlüsselpaar verwendet wird.


    Falls das login ohne Kennwort jetzt funktioniert, dann solltest du die id_rsa_filezilla{,.pub} und id_rsa_filezilla_pem{,.pub} Dateien vom Server löschen. Die gehören nur auf den Client.


    Sauberer wäre es die Schlüssel auf dem Client zu erzeugen und nur den Public Key auf den Server zu kopieren. Wie das geht kommt aber auf das Betriebssystem auf der Client Seite an.

    Suche: SGI Indigo (gerne IP12), DEC/DIGITAL CRT Monitor und ein VT240 (inkl. Monitor).

  • Der Zugriff auf den NetBSD Rechner soll aus dem Internet erfolgen, daher auch der Wunsch mit FileZilla (oder vielleicht auch WinSCP) arbeiten zu können, wenn man Dateien kopieren möchte. Mir geht es nicht um den Zugriff via telnet/ssh (bzw. putty).

    In der ssh_config gibt es bereits andere zusätzliche Schlüsselwörter bzgl. Passwortnutzung die ich wohl noch elimieren muss.

    Es soll halt ausschließlich mit dem Schlüssel gehen, nicht entweder/oder.

    Das mit dem Umwandeln in PEM ist ein guter Hinweis... probiere ich heute noch, bin momentan noch "auf der Arbeit" (HomeOffice).

    "The biggest communication problem is we do not listen to understand. We listen to reply." - Stephen Covey


    Webseite und Blog ist immer noch - seit fast 20 Jahren - online.

    Einmal editiert, zuletzt von Peter z80.eu ()

  • Der Zugriff auf den NetBSD Rechner soll aus dem Internet erfolgen

    dann solltest Du aber nicht den Standard-Port 22 verwenden, sonst hast Du die Script-Kiddies am Arsch wie eine Kuh die Fliegen. Die kommen dann zwar nicht per Login dran, aber: "Versuch macht kluch", Scripte sind geduldig. Und der root-Login sollte dann auf jeden Fall deaktiviert sein, also nicht explizit erlaubt werden.

  • Einen anderen Port zu benutzen ist sicherlich keine schlechte Idee aber ist eher so was wie Security by Obscurity (weil.... wer nmap benutzen kann findet das auch auf einem anderen Port).

    Da hilft eher, das nur auf Bedarf einzuschalten...

    "The biggest communication problem is we do not listen to understand. We listen to reply." - Stephen Covey


    Webseite und Blog ist immer noch - seit fast 20 Jahren - online.