Hallo,
versuche mich mit VS2022 (nicht VS Code) zu einem Linux System zu
verbinden.
An sich funktioniert es, aber nicht mehr, nachdem ich auf Chroot
umgestellt habe.
So, meine Konfiguration ist:
Windows 10 mit Visual Studio 2022.
Entfernter Rechner:
openSUSE 15.5, darauf Debian in Chroot mit debootstrap eingerichtet.
Über SSH, nur root kann ich an openSUSE anmelden, alle anderen enden in
Chroot.
Dies funktioniert auch anstandslos.
Hier die sshd_config dazu:
1
# Global settings
2
PermitRootLogin yes
3
UsePAM yes
4
X11Forwarding yes
5
6
Match User *,!root
7
ChrootDirectory /srv/chroot/debian/
8
AllowTCPForwarding yes
9
X11Forwarding yes
10
X11DisplayOffset 10
11
X11UseLocalHost no
12
# PermitTTY no
Einrichtung in VS2022:
Setup in Tools >> Options >> Cross Platform - Connection Manager
Hostname und Port 22, Benutzer und Passwort
Genauso eingerichtet wie alle anderen Zielsysteme auch, nur funktioniert
die Verbindung nur als root und verbindet nach openSUSE, was ich nicht
will. Als normaler Benutzer (jeder außer root) nach Debian in Chroot
funktioniert es nicht.
Ich bekomme dann folgenden Fehler:
1
Unknown Failure: An error occurred connection to ...
Inhalt des Logfiles:
1
Unknown Failure: Channel was closed.
Habe auch ProxyJump versucht. Hat ebenso nicht funktioniert und wäre
eigentlich auch sinnlos.
Was könnte das Problem sein?
Harald K. schrieb:> Hast Du mal einen anderen SSH-Client ausprobiert?
In wie fern?
versucht in cmd mit
ssh root@ip -> opensuse
ssh user@ip -> debian
funktioniert auch mit putty.
In Visual Studio selbst habe ich keine Einstellung dazu gefunden.
Michael D. schrieb:> funktioniert auch mit putty.
Auch mit TCP-Forwarding, ggfs. scp/sftp usw. versucht?
sshd-chroot ist recht frickelig. Hast du alle benötigten Device-Nodes
drinnen?
Einfacher (und sicherer) wär's, statt chroot einen kompletten Container
mit deinem Ziel-OS zu starten, und dorthinein per SSH zu verbinden.
systemd-nspawn oder lxc können das mehr oder weniger direkt mit deinem
"chroot"-Ordner, docker wär' auch möglich.
Εrnst B. schrieb:> Einfacher (und sicherer) wär's, statt chroot einen kompletten Container> mit deinem Ziel-OS zu starten, und dorthinein per SSH zu verbinden.> systemd-nspawn oder lxc können das mehr oder weniger direkt mit deinem> "chroot"-Ordner, docker wär' auch möglich.
Hab mich da mal kurz eingelesen. Es gibt dazu einen Host Network Mode
(versuche zusätzliche IP-Adressen zu vermeiden). Stehe ich dann nicht
wieder vor demselben Problem?
Vielleicht noch eine kurze Erklärung:
Host ist mein Server und soll so wenig wie möglich vom aufgesetzten
System beeinflusst werden. Ich wollte ein vom Host-System unabhängiges
System, auf dem ich mich austoben kann, ohne den Server zuzumüllen. Aber
grundsätzlich soll und darf auf die Ressourcen des Host-Systems
zugegriffen werden können. Daher habe ich mich explizit für Chroot
entschieden auch daher, dass mir Docker zu kompliziert und weniger
zweckmäßig erschien und ich bei einer VM eigentlich alles doppelt
einrichten und pflegen müsste. Hauptsächlich um die vorhandenen
Benutzeraccounts ohne großen Aufwand einzubinden aber dennoch isoliert
zu halten.
Michael D. schrieb:> Vielleicht noch eine kurze Erklärung:> Host ist mein Server und soll so wenig wie möglich vom aufgesetzten> System beeinflusst werden. Ich wollte ein vom Host-System unabhängiges> System, auf dem ich mich austoben kann, ohne den Server zuzumüllen. Aber> grundsätzlich soll und darf auf die Ressourcen des Host-Systems> zugegriffen werden können. Daher habe ich mich explizit für Chroot> entschieden auch daher, dass mir Docker zu kompliziert und weniger> zweckmäßig erschien und ich bei einer VM eigentlich alles doppelt> einrichten und pflegen müsste. Hauptsächlich um die vorhandenen> Benutzeraccounts ohne großen Aufwand einzubinden aber dennoch isoliert> zu halten.
So ein Blödsinn. Wasch mir die Hände, aber mach mich nicht nass.
Ob S. schrieb:> So ein Blödsinn. Wasch mir die Hände, aber mach mich nicht nass.
Abgesehen von blöden Sprüchen reißen, was ist dein konstruktiver Beitrag
zur Lösung des Problems? Oder evtl. ein besserer Ansatz.
Oder hast du noch weniger Ahnung als ich? Dann geh wo anders spielen.
Michael D. schrieb:> Host ist mein Server und soll so wenig wie möglich vom aufgesetzten> System beeinflusst werden. Ich wollte ein vom Host-System unabhängiges> System, auf dem ich mich austoben kann, ohne den Server zuzumüllen. Aber> grundsätzlich soll und darf auf die Ressourcen des Host-Systems> zugegriffen werden können. Daher habe ich mich explizit für Chroot> entschieden auch daher, dass mir Docker zu kompliziert und weniger> zweckmäßig erschien und ich bei einer VM eigentlich alles doppelt> einrichten und pflegen müsste.
Ehrlich gesagt habe ich immer noch nicht -- und nicht einmal ansatzweise
-- verstanden, was Du vorhast.
Ungewöhnlicherweise (*) fängt mein Unverständnis schon am Anfang an. Du
hast etwas, das Du "Server" nennst. Was ist das für ein Server? Einer im
Internet oder ein lokaler RasPi oder...?
Dann verstehe ich nicht, warum Du Dich gegen VMs und Containerlösungen
wie Docker, LXC oder Podman entschieden hast. chroot(8) ist, naja...
auch kein Kinderspiel, denn dort muß alles -- und ich meine: alles --
drin sein, was Deine Prozesse benötigen: Shared Objects,
Konfigurationsdateien, usw.
> Hauptsächlich um die vorhandenen> Benutzeraccounts ohne großen Aufwand einzubinden aber dennoch isoliert> zu halten.
Benutzeraccounts kann man automatisiert verteilen, über NIS, LDAP, und
über drölfzig andere Wege verteilen, auch über klassische SQL-RDBMS und
PAM.
Insofern ist die Kernfrage: was hast Du überhaupt vor? Bitte, versteh'
mich nicht flashc: wir haben hier im Forum sehr häufig Menschen, die ein
Problem und sich bereits für Lösungen entschieden haben, die sich bei
einer näheren Betrachtungen des Problems als, nunja, problematisch
erweisen.
Bitte beschreib' uns doch mal etwas genauer, was Du machen möchtest --
also nicht, was Du Dir ausgedacht hast, wie man das umsetzen könnte,
sondern, was Du erreichen willst. Dann haben wir sicher eine elegantere
Lösung für Dich. Viel Erfolg!
(*) :-)
Sheeva P. schrieb:> Insofern ist die Kernfrage: was hast Du überhaupt vor? Bitte, versteh'> mich nicht flashc: wir haben hier im Forum sehr häufig Menschen, die ein> Problem und sich bereits für Lösungen entschieden haben, die sich bei> einer näheren Betrachtungen des Problems als, nunja, problematisch> erweisen.>> Bitte beschreib' uns doch mal etwas genauer, was Du machen möchtest --> also nicht, was Du Dir ausgedacht hast, wie man das umsetzen könnte,> sondern, was Du erreichen willst. Dann haben wir sicher eine elegantere> Lösung für Dich. Viel Erfolg!
Kein Problem, dann liefere ich mal die gesamte Geschichte,
Ich nutze Linux schon seit über 20 Jahren, aber nach mehreren
fehlgeschlagenen Versuchen, hat es sich nie als Desktop-Betriebssystem
bei mir durchgesetzt. Nutzte nach wie vor Windows. So, jetzt war ich die
letzten 2 Semester an der Uni mehr oder weniger dazu gezwungen, unter
Linux zu programmieren und in der Arbeit mache ich inzwischen auch viel
mit ROS und Raspberry.
Ich hatte bisher immer Visual Studio in Verbindung mit WSL eingesetzt
oder mich mit dem Raspberry oder anderem System verbunden. Beides war
kein Problem. Das einzige Umständliche an WSL ist, immer
unterschiedliche Datenstände zwischen mehreren PCs zu haben.
Sheeva P. schrieb:> Ungewöhnlicherweise (*) fängt mein Unverständnis schon am Anfang an. Du> hast etwas, das Du "Server" nennst. Was ist das für ein Server? Einer im> Internet oder ein lokaler RasPi oder...?
Nein, lokaler Server. Kein umfunktionierter Desktop-Rechner, sondern
einer von Supermicro mit Dual-Xeon und RAID. Etwas älteres Model aber
erfüllt seinen Zweck.
Weiter in der Geschichte. Also war ich auf der Suche nach einer Lösung
das zu zentralisieren. Kurzum, ich habe zu Hause einen Linux-Server
(openSUSE LEAP 15.5), welcher als Fileserver dient mit den üblichen
Diensten (DNS, DHCP, MySQL, SMB usw.) welcher für diesen Zweck
eigentlich ideal erschien. Ich habe alles zentral und eine
Linux-Umgebung. Bin aber auch relativ schnell auf den Gedanken gekommen,
dass es nicht unbedingt das Klügste ist, direkt auf dem Server zu
arbeiten. Also weniger aus sicherheitsrelevanten, sondern mehr aus
organisatorischen Gründen möchte ich Server-Host und meine „Spielwiese“
getrennt halten aber dennoch die Ressourcen des Host-Systems nutzen.
Also keine strikte Trennung und Isolation, sondern einfach nur Pakete
und Anwendungen installieren, welche auf dem Server selbst nicht
verloren haben, wie zum Beispiel cmake oder was auch immer.
Ich habe dazu mal etwas recherchiert und bin auf 3 mögliche Optionen
gestoßen: VMs, Docker und Chroot.
1) WM
Ist ein eigenständiges System und vollständige Isolation vom Host, was
ich eigentlich gar nicht will.
2) Docker
Bin durch openSUSE an Podman gebunden, aber sollte vom Handling her
gleich sein.
Relativ ähnlich zu VMs. Ich habe es mal mit getestet und mir das
ROS-Packet mit Ubuntu geladen, fand es aber zu umständlich und habe den
SSH-Login nicht hinbekommen.
3) Chroot
Erscheint mir für meinen Zweck als ideal. Habe zum Spaß Debian verwendet
und konnte /home und die anderen notwendigen Verzeichnisse per rbind
einbinden. Also eigentlich wie auf dem Host-System direkt aber mit der
geforderten Teil-Isolation.
Bis auf ein paar Kleinigkeiten, an denen ich noch arbeite, läuft wie ich
es haben will. Das größte Problem, dass ich habe, dass sich Visual
Studio nicht verbinden will.
Ich bin aber nach wie vor auch für andere Umsetzungen offen.
Sheeva P. schrieb:> Benutzeraccounts kann man automatisiert verteilen, über NIS, LDAP, und> über drölfzig andere Wege verteilen, auch über klassische SQL-RDBMS und> PAM.
So, wenn ich jetzt etwas weiter blicke, sollte man folgendes vielleicht
auch noch mit in die Überlegung mit aufnehmen:
Ich will meinen Fileserver mit Samba in absehbarer Zeit auf AD
umstellen. Das heißt, Roaming-Accounts für die Windows Rechner und da
ich noch einen Test-Rechner unter Linux und ein paar Raspberries habe,
würde ich die Linux-Benutzerkonten zentral halten wollen. Also die
bereits Vorhandenen auf dem Server per NIS/NFS verteilen.
Also nochmal in Kurz zusammengefasst, was ich eigentlich will.
- Anmeldung auf dem Server per ssh (Konsole mit X11-forwarding reicht,
brauch keine GUI) innerhalb eines Subsystems aber ohne vollständige
Entkapselung vom Host-System um zum Beispiel die vorhandenen Benutzer
und Rechte weiterverwenden zu können aber so, dass ich das Host-System
nicht mit Software-Installationen beeinflusse.
- Anbindung an Visual Studio, Remote Compiling.
Ich hoffe, es ist jetzt etwas verständlicher, was ich vor habe. Habe ich
noch irgendetwas wichtiges vergessen zu erwähnen oder vergessen zu
bedenken?
Michael D. schrieb:> Ich hoffe, es ist jetzt etwas verständlicher, was ich vor habe. Habe ich> noch irgendetwas wichtiges vergessen zu erwähnen oder vergessen zu> bedenken?
Ja: Warum? Was soll der Quatsch?
Oliver
Dir ist schon klar das der SSH Server im Chroot() gar nicht starten kann
wenn im Host schon ein SSH Server auf Port 22 lauscht. Netzwerk
Interface ist ja dasselbe..
Und es ist auch für Erwachsene gar nicht soo einfach zu erkennen ob ein
Prozess vom Host direkt oder im chroot läuft.
Daher auch von hier die dringende Empfehlung das lieber mit LXC/LXD oder
einer anderen Container Lösung zu versuchen - da hat der Gast nämlich
sein eigenes vom Host unabhängiges Netzwerk!
Netzwerkbrücke einrichten (die braucht man wenn man vom Gast auf das
Internet/LAN ohne Klimmzüge zugreifen möchte) geht auch im Nürnberger
Windows. Kann aber sein das es dafür keine direkte Option im Klickibunti
(UI/yast) gibt. Hatte ich hier direkt via Config Datei eingerichtet.
AD will übrigens in einem eigenen, vom Fileserver vollständig getrennten
Container laufen. Ja, auch der Samba AD.
Michael D. schrieb:> Kein Problem, dann liefere ich mal die gesamte Geschichte,> Ich nutze Linux schon seit über 20 Jahren,
Was ja schonmal ein guter Anfang ist, ...
> aber nach mehreren> fehlgeschlagenen Versuchen, hat es sich nie als Desktop-Betriebssystem> bei mir durchgesetzt. Nutzte nach wie vor Windows.
... naja, ein halbwegs guter Anfang. :-D
> Nein, lokaler Server. Kein umfunktionierter Desktop-Rechner, sondern> einer von Supermicro mit Dual-Xeon und RAID. Etwas älteres Model aber> erfüllt seinen Zweck.
Alles fein,
> Weiter in der Geschichte. Also war ich auf der Suche nach einer Lösung> das zu zentralisieren. Kurzum, ich habe zu Hause einen Linux-Server> (openSUSE LEAP 15.5), welcher als Fileserver dient mit den üblichen> Diensten (DNS, DHCP, MySQL, SMB usw.) welcher für diesen Zweck> eigentlich ideal erschien.
Alles fein... jemand, der DNS, DHCP und SMB einrichten kann, ist
jedenfalls kein blutiger Anfänger mehr.
Also weniger aus sicherheitsrelevanten, sondern mehr aus
> organisatorischen Gründen möchte ich Server-Host und meine „Spielwiese“> getrennt halten aber dennoch die Ressourcen des Host-Systems nutzen.
Okay, alles fein.
> 2) Docker> Bin durch openSUSE an Podman gebunden, aber sollte vom Handling her> gleich sein.> Relativ ähnlich zu VMs. Ich habe es mal mit getestet und mir das> ROS-Packet mit Ubuntu geladen, fand es aber zu umständlich und habe den> SSH-Login nicht hinbekommen.
Das... also... äh...
> Ich bin aber nach wie vor auch für andere Umsetzungen offen.
Mein Rat ist: arbyte Dich in Docker ein und benutz das. Ja, das ist
nicht ganz einfach, ich weiß das, und auch unter einer SuSE bist Du
nicht zwangsläufig an DeadRat und seinen Podman gebunden... :-)
Im Kern geht es bei Containerlösungen um isolierte Prozesse in --
Überraschung -- einer Laufzeitumgebung, die Du sehr genau bestimmen
kannst. Du kannst auch in einen laufenden Container hinein bash(1)en
oder in Deinem Container einen OpenSSH-Daemon laufen lassen oder...
genau.
Meine Containerlösung der Wahl ist Docker. Klar, da muß man sich
reinfuchsen, aber erfahrene Linuxer wie Dich stellt das nicht vor
Schwierigkeiten. Was ist ein Mountpoint? Genau, das kennst Du. Netzwerke
auch. GUI-Tools wie Google Chrome oder TheGIMP oder ...? Na klar, das
geht auch.
Zu den (IMHO) elegantesten Punkten gehört, daß ich mit Docker haargenau
die isolierte Laufzeitumgebung bauen kann, die ich haben möchte, die
Isolation dann aber andererseits genau so gestalten kann, wie ich mag.
> [...] die bereits Vorhandenen auf dem Server per NIS/NFS verteilen.
Das würde ich mir an Deiner Stelle noch einmal überlegen. AD ist im Kern
eine Kombination aus LDAP und Kerberos, und mit NIS / YP macht das --
trust me on this one -- keinen Spaß.
> Ich hoffe, es ist jetzt etwas verständlicher, was ich vor habe.
Naja, Du willst sehr komplizierte Dinge möglichst einfach haben, hast
aber wenig Lust auf jene Dinge, die Dir diese Dinge einfach machen
können. :-/
Thread beobachten
Seitenaufteilung abschalten