Mediaserver

beta

Member
Jan 20, 2021
77
1
13
53
Moin,

nach erfolgreichem Start von PVE mit OVM stelle ich mir jetzt die Frage welchen Weg man am besten für einen Mediaserver geht.
Wege gibt es ja viele, aber für mich als Anfänger sind diese zum Teil wirklich aufwendig.
Ziel: Der Mediaserver (z.B. Emby, Serviio, Plex ...) sollen auf die Daten vom OVM SMB zugreifen können.

1. Wenn ich mit jetzt z.B. ein Debian in einer VM nehme, muss ich alles per CLI machen.
IP, Share, ... das ist zum Teil aufwendig und auch Recherche für mich.
Ich weiss jetzt auch nicht, ob ich mir ein "Default Debian" als VM sichern kann, um es für andere "Server" zu nutzen?
IP, Hostname etc. wären dann ja identisch, was ich wieder ändern müsste?

2. Distri als VM mit GUI? Ich weiss das ist eine Angiffsstelle, für mich aber nicht so relevant, weil nichts geöffnet ist.
Ich weiß aber nicht, ob ich da alle "Anwendungen" einfach installieren kann?

3. LXC sollte ja ähnlich zu 1&2 sein, nur ohne Overhead?

4. Docker/Portainer als LXC/VM?

5. Docker/Portainer direkt auf OMV?

Wichtig ist natürlich der SMB Zugriff auf die Daten vom OMV.

LG
 
Eine Frage ist erst einmal, ob der Media-Server auch online erreichbar sein soll. Ich will mein Emby z.B. auch von Freunden aus oder über die Emby-App vom Smartphone/Tablet aus erreichen können, dass da Medienwiedergabe nicht nur von daheim geht. Willst du an deine Medien also ohne VPN von überall ran, dann musst du den Medienserver schon öffentlich ins das Netz hängen und dann würde ich z.B. aus Sicherheitsgründen keine LXCs mehr nutzen wollen.
Das andere ist Hardware-Beschleunigung beim Encoding von Videos. Meistens musst du monatlich Geld zahlen, damit Plex, Emby und Co dir Hardware-Beschleunigung erlauben. Und natürlich brauchst du dann auch eine entsprechende extra GPU die du per PCI Passthrough einer VM durchreichen musst (und die dann auch keine anderen VMs oder der Host selbst mehr nutzen können). Ohne Hardware-Beschleunigung einer GPU geht das echt auf die CPU. Bei mir lastet das gute 6 Cores völlig aus nur um ein 1080p Video auf der CPU zu enodieren. 4K müsste ich bei mir also garnicht erst testen.^^
Wenn du da Hardware-Beschleunigung willst sind LXCs/Docker-Container glaube ich auch keine Option.

Ich finde der beste Weg ist immer noch sich ordentlich mit Linux zu beschäftigen und es dann selbst in einer VM auf einem frischen Linux einzurichten. Dann weiß man wenigstens genau, warum da was, wie und wann gemacht wird, weil man alles selbst eingerichtet und verstanden hat. Nutzt du ein LXC-Template oder Docker-Container hat da irgendwer etwas lauffähiges zusammengebastelt und du installierst das mit 1-2 Klicks. Dann bist du erstens darauf angewiesen, dass da der andere keine Fehler gemacht hat und zweitens musst du dich immer darauf verlassen, dass da der andere auch ewig seine Templates oder Container pflegt. Der kann ja auch mal Nachwuchs bekommen und dann gibt es halt mal 1 oder 2 Jahre keine Updates mehr oder etwas wird ganz eingestellt. Und weil du dich selbst nie mit all dem wirklich beschäftigen musstest, weißt du dann auch nicht, wie man das alles selbst beheben oder pflegen könnte.
Auch bist du z.B. bei Docker-Containern immer darauf beschränkt, wie der Entwickler das haben möchte. Da kannst du nicht einfach etwas anpassen oder nachinstallieren, wenn dir etwas nicht gefällt oder dir etwas fehlt.

Bei Emby ist das aufsetzen einer Linux-VM z.B. ziemlich einfach und mit wenigen CLI Zeilen getan. Und gegen eine WebGUI für die Linux-Administration wie Webmin spricht ja eigentlich auch nichts. Selbst wenn der Media-Server im Internet hängt. Denn du musst den Port der WebUI ja nicht im Router fürs Port-Forwarding freigeben. Reicht ja völlig, wenn du da nur lokal im LAN auf das WebGUI zugreifen kannst. Alles wirst du aber natürlich nicht per GUI machen können. Bei Linux wird man immer irgendwie CLI nutzen müssen. Aber wenn man eigene Server betreibt, dann sollte man sich auch immer mit der Stabilität und Sicherheit beschäftigen, damit man sich nicht selber ins Bein schießt und da gehört Lernen von Linux-Basics klar dazu. Wenn man kein Linux ohne GUI bedienen kann, dann sollte man sich überlegen, warum man den Server überhaupt selbst aufsetzen will und sich nicht einfach Netflix, Spotify und Co holt.
Soll nicht heißen das du dir da keinen Server aufsetzen sollst. So etwas ist super zum Lernen, wenn man es denn selbst aufsetzt. Aber wenn da schon die Grundlagen wie gängige CLI Kommands fehlen, dann würde ich vermuten, dass da kein sicherer Server bei rauskommt, den ich vom Internet aus erreichbar machen wollen würde. Offline ist das natürlich unproblematisch. Da kannst du dann höchstens deine Mediensammlung verlieren und musst dann halt alles neu aufsetzen.

1. Wenn ich mit jetzt z.B. ein Debian in einer VM nehme, muss ich alles per CLI machen.
IP, Share, ... das ist zum Teil aufwendig und auch Recherche für mich.
Ich weiss jetzt auch nicht, ob ich mir ein "Default Debian" als VM sichern kann, um es für andere "Server" zu nutzen?
IP, Hostname etc. wären dann ja identisch, was ich wieder ändern müsste?
Ja, VMs kannst du Klonen und auch Templates machen. Rechnername, IP etc musst du natürlich trotzdem bei jedem Template dann neu anpassen damit es nicht doppelt ist.
Und lernen musst du da natürlich auch. Ich habe mir einfach eine Anleitung für mich selbst geschrieben, wie ich meine Debian-VMs zu erstellen haben. Dauert dann auch nur so 1 Stunde und ich habe alles fertig installiert und eingerichtet. Kann ich dann ja immer die CLI Kommandos aus meinen Notizen kopieren und in der Shell einfügen.
Ist dann halt einmal Arbeit alles zu recherchieren und aufzuschreiben aber dafür geht danach dann jede weitere VM ziemlich flott.
3. LXC sollte ja ähnlich zu 1&2 sein, nur ohne Overhead?
Nicht so wirklich. Im unprivilegierten LXC darfst du z.B. nichts mounten. Auch keine SMB Shares. Deine Medien würdest du da nur über komplizierte Umwege in den LXC bekommen. Privilegierter LXC dürfte SMB mounten, ist aber auch bzgl. Stabilität und Sicherheit nicht mit einer VM vergleichbar. Würde ich wie gesagt nicht ins Internet lassen.
 
Last edited:
OK, danke.
Von Aussen geht das bei mir nur über das VPN der Fritzbox, das wäre nicht das Problem.
Hmm ... ich schätze auch, dass ich das lieber in einer eigenen VM mit Debian mache.
Zumal man dann unabhängig ist.
So einfach ist es selbst nicht aus einem OMV-Docker an die Shares zu kommen.
 
CLI ist mir noch aus alten Amiga- und DOS-Zeiten bekannt, ich dachte darüber wäre ich hinweg. lol
Gibt es eigentlich sowas wie ein "Basic-Tutorial" um eine Debian halbwegs einzurichten bzw. was
man auf jeden Fall wissen oder ändern muss?
Mit der IP hab ich schon mal angefangen. lol
 
Naja CLI wird nie aussterben, weil es einfach viel schneller geht, wenn man weiß, was man tut. Und man hat halt einfach viel mehr Freiheiten.
Selbst bei Windows10 benutzt man heute noch viel PowerShell, wenn man komplexeres tun will. Da ist das genau wie bei Linux. Willst du professionelleres tun, dann muss man doch CLI nutzen, weil viele der Windows-Programme zur Administrierung halt keine GUI besitzen.
Willst du z.B. auf Win10 professionell einen Ordner von A nach B kopieren, dann nimmst du die eingebaute Robocopy.exe per CLI anstatt das einfach per GUI über den Explorer zu tun.

Was ich bei jeder neuen Debian VM als erstes mache:

1.) Repositories mit nano /etc/apt/sources.list anpassen, dass da "main contrib non-free" benutzt werden. "non-free" ist oft nicht automatisch eingestellt.

2.) SSH key für root einrichten:
mkdir /root/.ssh
nano /root/.ssh/authorized_keys
Dort den Public Key einfügen.
Rebooten.

3.) Sollte man sich per RSA Key dann mit SSH als root verbinden können, dann den Login per Passwort verbieten:
nano /etc/ssh/sshd_config
Zeile "#PasswordAuthentication yes" auf "PasswordAuthentication no" ändern.

4.) Vergewissern, dass da die NIC eine statische IP benutzt:
nano /etc/network/interfaces
Fall da etwas steht wie "iface ens18 inet dhcp" dass dann auf etwas wie...
iface ens18 inet static address 192.168.1.2/24 gateway 192.168.1.1
...ändern.

5.) Falls man kein IPv6 braucht und sich doppelte Arbeit sparen will das Linux abzusichern, dann kann man das auch verbieten:
nano /etc/network/interfaces
Dann da die Zeilen wie "iface ens18 inet6 auto" auskommentieren.
nano /etc/sysctl.conf
Dort "net.ipv6.conf.all.disable_ipv6 = 1" einfügen.

6.) Vergewissern, dass da der richtige DNS-Server gesetzt ist:
nano /etc/resolv.conf
Dort jeweilige DNS-Server einfügen:
Code:
nameserver 192.168.1.1
nameserver 8.8.8.8

7.) Swappiness anpassen:
nano /etc/sysctl.conf
Z.B. "vm.swappiness = 60" einfügen falls viel geswappt werden soll oder "vm.swappiness = 1" wenn Swapping möglichst vermieden werden soll.

8.) QEMU Guest Agent installieren
apt-get install qemu-guest-agent
Und dann sicherstellen, dass da in der ProxmoxGUI auch für die VM die "QEMU Guest Agent"-Checkbox aktiviert ist.

9.) "/tmp" auf RAMdisk legen um SSD zu schonen:
cp /usr/share/systemd/tmp.mount /etc/systemd/system/
systemctl enable tmp.mount

10.) Tägliches TRIM/Discard einrichten, damit für SSDs und Thin Provisioning auch wirklich gelöschte Daten gelöscht werden. Dazu muss für die virtuelle HDD im ProxmoxGUI natürlich auch die "Discard"-Checkbox aktiv sein:
nano /etc/cron.daily/daily_trim
Dort dann einfügen:
Code:
#!/bin/sh
#
# To find which FS support trim, we check that DISC-MAX (discard max bytes)
# is great than zero. Check discard_max_bytes documentation at
# https://www.kernel.org/doc/Documentation/block/queue-sysfs.txt
#
# Copy script to /etc/cron.daily or /etc/cron.weekly
#
for fs in $(lsblk -o MOUNTPOINT,DISC-MAX,FSTYPE | grep -E '^/.* [1-9]+.* ' | awk '{print $1}'); do
    fstrim "$fs"
done
chmod 755 /etc/cron.daily/daily_trim
crontab -e
Dort einfügen:
Code:
0 0 * * *        /bin/sh /etc/cron.daily/daily_trim
(letzteres mache ich nur, weil "/etc/cron.daily/daily_trim" irgendwie nicht automatisch täglich aufgerufen wird. Weiß jemand warum eigentlich nicht?)

11.) Falls Zugriff auf SMB Shares nötig ist:

CIFS-Utils installieren um SMB-Shares mounten zu können:
apt install cifs-utils

Datei mit SMB-Zugangsdaten erstellen:
nano /root/.smb_[FREIGABE_NAME]
Dort einfügen:
Code:
username=[USERNAME]
password=[PASSWORT]

chmod 0600 /root/.smb_[FREIGABE_NAME]
mkdir /media/[FREIGABE_NAME]
chown root:root /media/[FREIGABE_NAME]
nano /etc/fstab
Dort einfügen:
Code:
#SambaShares
//[IP.DES.SMB.SERVERS]/[FREIGABE_NAME]               /media/[FREIGABE_NAME]                cifs    auto,rw,credentials=/root/.smb_[FREIGABE_NAME],uid=[UID_DES_GEWÜNSCHTEN_BESITZERS],gid=[GID_DES_GEWÜNSCHTEN_BESITZERS],file_mode=0660,dir_mode=0770  0 0

12.) Autoupdates installieren, damit Sicherheitsupdates automatisch installiert werden. Sollte man lieber weglassen, wenn man keine regelmäßigen Snapshots und Backups hat:
apt-get install unattended-upgrades apt-listchanges

13.) Sicherstellen, dass da "noatime" für alle xfs-Partitionen und "noatime,nodiratime" für alle ext4-Partitionen unter "Options" gesetzt ist, damit die SSDs länger halten:
nano /etc/fstab

14.) Dann kommen bei mir noch der Zabbix-Agent für das Monitoring und Filebeat für das zentrale Sammeln von Logs hinzu, aber das bringt ja nur etwas, wenn du das auch nutzt.

Das wäre so meine Basics die ich überall in Debian-VMs einstelle. Kommen natürlich noch 100 Sachen hinzu, je nachdem, was ich da dann für Dienste drauf laufen lassen will. "fail2ban" wäre z.B. so eine Sache mit der man sich beschäftigen sollte, wenn man die Sicherheit erhöhen will. Oder "postfix", wenn man auch eMails über einen externen SMTP-Server versenden können will.
 
Last edited:
  • Like
Reactions: nevermindnono
Vielen, vielen Dank.
Richtig geil, dass ist genau was ich gesucht habe.
 
Moin,

aktuell macht das richtig Lust Linux zu "lernen".
Ein paar Fragen hätte ich dazu allerdings noch ..

- Thema Rechte:
Ich habe irgendwo gelesen, dass man nicht zwangsweise ein root passwort vergeben muss und der user bei der
Installation direkt sudo Rechte bekommt?
Hätte das irgendwelche Nachteile?
Bei mir konnte ich mich z.B. nicht über SSH als root anmelden. Dazu musste ich in der PVE Konsole erste den user sudo Rechte geben?

1.) Repositories mit nano /etc/apt/sources.list anpassen, dass da "main contrib non-free" benutzt werden. "non-free" ist oft nicht automatisch eingestellt.
In der sources stehen also die Paktequellen, die bei der Installtion von Paketen durchsucht werden?
Ist in der "non-free" denn was drin, was benötigt wird?

2.) SSH key für root einrichten:
Das benötige ich aber nur, wenn ich remote ssh nutzen möchte?

9.) "/tmp" auf RAMdisk legen um SSD zu schonen:
Benötigt das viel RAM bzw. was passiert wenn der RAM voll ist?

11.) Falls Zugriff auf SMB Shares nötig ist:
username=[USERNAME]
password=[PASSWORT]
Ist in der Datei dann der Name und das Passwort im Klartext hinterlegt?
Wäre das dann nicht auch ein Sicherheitsrisiko?

LG
 
Moin,

aktuell macht das richtig Lust Linux zu "lernen".
Ein paar Fragen hätte ich dazu allerdings noch ..

- Thema Rechte:
Ich habe irgendwo gelesen, dass man nicht zwangsweise ein root passwort vergeben muss und der user bei der
Installation direkt sudo Rechte bekommt?
Hätte das irgendwelche Nachteile?
Bei mir konnte ich mich z.B. nicht über SSH als root anmelden. Dazu musste ich in der PVE Konsole erste den user sudo Rechte geben?
Laut der Debian-Grundeinstellung darf sich root per SSH einloggen, aber eben nicht per Passwort sondern höchstens per RSA Key. Wenn du wie in meiner Anleitung bei Schritt 2 für Root einen SSH Key hinterlegst, dann klappt da auch der Root-Login über SSH. Alternativ kann man in der Konfig-Datei vom SSH-Server auch "PermitRootLogin yes" setzen, dann darf der Root-User auch per Passwort einloggen. Sollte man aber nicht machen, weil es das ganze unsicher macht.
Standardmäßig richtest du bei der Debian-Installation einen normalen User ein der Teil der Gruppe "sudoers" ist und sich damit selbst per sudo zum Root machen darf. Das ist generell kein sehr guter Ansatz, weil eigentlich möchte man ja, dass da User das eben nicht dürfen. Root sollte echt nur zum Administrieren benutzt werden, wenn man z.B. Updates einspielt und dann entsprechende Rechte benötigt. Alle anderen Programme und Dinge sollte man mit extra dafür erstellen Usern machen die nur genau das dürfen, was sie auch wirklich brauchen. Wenn ein User mal etwas mehr Rechte braucht, die normal nur Root besitzt, dann musst du den User auch nicht unbedingt die Rechte geben sich zum Root machen zu dürfen. Über die sudo Konfig-Datei kannst du z.B. einem User den Zugriff auf einzelne Programme/Dateien erlauben die sonst nur root nutzen konnte. Dann kann der User wirklich nur dieses eine Programm aufrufen und nicht sonstigen Unfug anstellen.
Die Idee ist also für alles eigene User zu nehmen und denen die Rechte so weit einzuschränken, dass da alles läuft was die brauchen aber eben auch nicht mehr. Allen Usern einfach per sudo root Rechte verpassen ist zwar bequem, aber halt alles andere als sicher.
In der sources stehen also die Paktequellen, die bei der Installation von Paketen durchsucht werden?
Ist in der "non-free" denn was drin, was benötigt wird?
Linux ist Opensource und nutzt als solches standardmäßig nur Open Source Programme, damit die Opensource Lizenz erfüllt wird. Oft brauchst du aber Programme oder Treiber die nicht Opensource sind. Hast du "non-free" nicht als Repo in der Paketliste, dann kannst du all die Programme halt nicht installieren.
"non-free" brauchst du nicht zwingend. Früher oder später muss ich aber meist Programme installieren die nicht Opensource sind und dann muss ich das eh hinzufügen, um die installieren zu können. Da mache ich das lieber gleich am Anfang. Gibt dir halt mehr Auswahl an installierbaren Programmen und da du ja selbst alles manuell installieren musst, hat ja mehr Auswahl keinen Nachteil.
Das benötige ich aber nur, wenn ich remote ssh nutzen möchte?
Naja, je nachdem wie man das nimmt. SSH nutzt du ja immer "remote". RSA Keys sind halt einfach viel sicherer (und richtig eingerichtet auch komfortabler) als Passwörter, weshalb man das eigentlich immer einrichten sollte. Hast du SSH aktiviert, dann kann ja jeder Rechner im LAN sich Zutritt zum Server verschaffen. Inkl jeder ominösen App auf dem Handy mit sonst wieviel Spyware. Macht also auch Sinn das zu nutzen, wenn man den SSH-Port nicht im Router für das Internet freigibt.

Ich habe meine SSH Keys z.B. im verschlüsselten KeePass Passwort Safe gespeichert, welcher über meine Nextcloud synchron zwischen verschiedenen Rechnern gehalten wird. Auf den Rechnern habe ich dann KeepassXC als Passwort Manager, Pageant als Authentificator und Putty als SSH-Terminal. So muss ich nur einmal beim Login meinen Passwort Safe entsperren, der läd dann die Keys in Pageant und dieser wiederum stellt die Putty bereit. So wird die SSH Verbindung dann automatisch aufgebaut, ohne das ich da überhaupt ein Passwort eingeben müsste. Daher komfortabler und trotzdem noch sicherer. Wenn man das noch sicherer haben möchte, dann sollte man dem RSA Key aber noch ein zusätzlichen Passwort verpassen.
Benötigt das viel RAM bzw. was passiert wenn der RAM voll ist?
Das braucht so viel RAM wie Dinge in den "/tmp"-Ordner geschrieben werden. Wenn du 10GB nach /tmp schreibst brauchst das halt 10GB mehr RAM. "/tmp" ist nur temporäre Dateien gedacht die meist vom Programm, was dahin geschrieben hat, nach wenigen Sekunden wieder gelöscht werden. Spätestens beim Reboot wird alles gelöscht was sich in dem Ordner befindet.
Vorteil dabei ist halt, dass da der RAM 100x schneller als eine SSD ist und sich unendlich oft ohne Abnutzung beschreiben lässt. Die SSD geht mit jedem kleinen Schreibvorgang mehr und mehr kaputt. Da bietet sich es halt an temporäre Dateien gleich in den RAM zu schreiben, anstatt immer gleich auf die SSD, um die SSD etwas zu schonen. Meist wird auch nicht viel nach /tmp geschrieben. Sind bei mir selten mehr als einige hundert MB gleichzeitig. Ist der RAM voll wird vom RAM auf die Swap-Partition ausgelagert und dann landet es vom RAM doch wieder auf der SSD. Also allgemein nicht so das große Problem.
Wenn du das aber irgendwie limitieren willst, kann man statt RamFS auch TmpFS nehmen. Dort lässt sich eine zusätzliche Obergrenze für die Ordnergröße festlegen.
Ist in der Datei dann der Name und das Passwort im Klartext hinterlegt?
Wäre das dann nicht auch ein Sicherheitsrisiko?
Ja, ist in Klartext. Deshalb ja das "chmod 0600 /root/.smb_[FREIGABE_NAME]", damit nur der Besitzer der Datei diese lesen kann. Das gleiche sollte man auch für die "/root/.ssh/authorized_keys" machen, das hatte ich vergessen aufzuschreiben. Wenn du die beiden Dateien nicht als Root erstellt hast solltest du die auch noch über "chown root:root /root/.ssh/authorized_keys" root zum Besitzer machen. Dann ist das kein Problem, wenn da Passwörter im Klartext sind, weil ja nur Root die öffnen kann. Und wenn jemand Unbefugtes schon Root-Rechte erlangt hat, dann sind eh Hopfen und Malz verloren und der kann eh alles mit der VM machen was er will.
Aber besser Passwörter in Klartext in einer Datei die außer Root niemand lesen kann, als wenn du da direkt die Passwörter im Klartext in der /etc/fstab angiebst. Dann landet das Passwort bei Mount-Fehlern wenigstens nicht als Klartext in den Logs, wo dann vielleicht auch andere User drauf Zugriff hätten. So sehen die dann nur den Pfad zur Passwort-Datei, können aber selbst nicht an den Inhalt kommen.
 
Last edited:
OK, danke.

ich meinte nur was passiert, wenn die Ramdisk quasi überläuft bzw. voll ist.
Aber wenn das im Normalfall nur einige hundert MB sind, dürfte da ja nichts passieren.

Standardmäßig richtest du bei der Debian-Installation einen normalen User ein der Teil der Gruppe "sudoers" ist und sich damit selbst per sudo zum Root machen darf.
So ganz verstehe ich das nicht.
Eigentlich sollte ja nur der root auch Rootrechte haben?
Warum kann sich dann ein User selbst mit sudo Rootrechte geben?
Sollte oder kann ich dem User die Rechte denn wieder entziehen?

2.) SSH key für root einrichten:
mkdir /root/.ssh
nano /root/.ssh/authorized_keys
Dort den Public Key einfügen.
Wie komme ich denn an den Public Key?
 
OK, danke.

ich meinte nur was passiert, wenn die Ramdisk quasi überläuft bzw. voll ist.
Aber wenn das im Normalfall nur einige hundert MB sind, dürfte da ja nichts passieren.
Ja, im Normalfall sollte RamFS reichen. Wenn du auf Nummer sicher gehen willst halt TmpFS nehmen und das z.B. auf 1GB begrenzen. Wenn dann mehr als 1GB gespeichert werden soll, dann bekommt der Prozess halt einen Fehler von wegen "Platte voll" und bricht ab. So kann dann nicht mehr als 1GB RAM dafür benutzt werden.
So ganz verstehe ich das nicht.
Eigentlich sollte ja nur der root auch Rootrechte haben?
Warum kann sich dann ein User selbst mit sudo Rootrechte geben?
Sollte oder kann ich dem User die Rechte denn wieder entziehen?
Wenn ein User in der sudoers-Datei aufgeführt wird, dann kann er alles machen was root darf, wenn er ein "sudo" vor den Befehl hängt. Der User kann dann quasi alles machen was Root auch könnte. Der User hat dann quasi volle Root-Rechte ohne selbst root sein zu müssen.
Wenn du es sicher haben willst dann lieber dem User wieder die Sudo Rechte entziehen oder du musst halt sicherstellen, dass da dein User gleich gut abgesichert ist wie root selbst. Kann ja auch Vorteile haben quasi einen Root-User zu besitzen der nicht "root" heißt. So kannst du z.B. "root" als User für SSH verbieten und wenn dann ein Angreifer deinen Server per SSH hacken will, dann muss er nicht nur das Passwort sondern auch den richtigen Usernamen erraten, was dann natürlich die Sicherheit erhöht.
Wie komme ich denn an den Public Key?
Den Public Key musst du dir selbst erstellen. Wen du Windows nutzt z.B. mit PuttyGen ("puttygen.exe" unter "Alternative Binary files").
Oder über Linux z.B. so:
ssh-keygen -t rsa -b 4096
 
Last edited:

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!