Ubuntu - Zugriff auf "root" über "WinSCP" schlägt fehl

[Snoopy69]

Ich würde gerne über WinSCP auf einen Ubuntu-Rechner im Netzwerk auf root zugreifen. Nach Auth. erscheint die Meldung, dass "root" verwendet wird. Ist das der Grund, warum ich trotz richtigem Passwort nicht drauf zugreifen kann?

https://abload.de/img/ewfgbknd.jpg

[Grendizer]

Bei Ubuntu ist doch root standardmäßig nicht aktiv :confused:

[Snoopy69]

K.A. ich versuche mich gerade an Linux
Wenn vorne "root" steht, hab ich root-Rechte, richtig?
https://abload.de/img/gfrswt4jbv.jpg
Aber wenn ich hier root-Rechte hab, frage ich mich, warum der Befehl "nano" nicht funktionierte.
Ich wollte damit eine Datei erstellen etc

Über WinSCP komme ich nur in den Rechner, wenn vorne "user" steht. Damit kann ich aber nichts ändern/erstellen/löschen etc

[universaL]

dann musst du wohl PermitRootLogin yes in der sshd config setzen, würde ich aber tatsächlich nur lokal zum testen empfehlen! ;-)

https://www.liquidweb.com/kb/enable-root-login-via-ssh/

[Snoopy69]

Ok...

Noch eine Frage wegen dem root-Passwort...
Es handelt sich nicht um das klassische Ubuntu - nur um einen Ubuntu-Fork
Ist es normal, dass ich das root-Passwort einfach so ändern kann, ohne das vorherige Passwort eingeben zu müssen? Oder ist das eine "Besonderheit" dieses Forks?

[Rumbah]

Heutzutage nutzt man für sowas sudo, nicht das anmelden per root (deshalb ist ssh root Zugriff auch normalerweise deaktiviert).

Also du meldest dich als normaler Nutzer an, und dann in deinem Fall machst du einfach:
sudo nano
Dann wird nano mit Rechten ausgeführt, du musst natürlich dann einmal das root Passwort eintippen (und dann je nach Einstellung nach x Minuten der Nichtnutzung).
Auch da musst du deinen Benutzer eventuell einmal freischalten, je nach Standardkonfiguration in deiner Distribution.

https://de.wikipedia.org/wiki/Sudo

[fezie]

Für ssh logins auf fremden Rechnern im Internet empfiehlt es sich ssh keys statt Passwörter zu nutzen
Dann ist auch ein direkter root login nicht so unsicher
Im lokalen Netzwerk natürlich nicht so relevant

[Benutzername]

Heutzutage nutzt man für sowas sudo, nicht das anmelden per root (deshalb ist ssh root Zugriff auch normalerweise deaktiviert).

Also du meldest dich als normaler Nutzer an, und dann in deinem Fall machst du einfach:
sudo nano
Dann wird nano mit Rechten ausgeführt, du musst natürlich dann einmal das root Passwort eintippen (und dann je nach Einstellung nach x Minuten der Nichtnutzung).
Auch da musst du deinen Benutzer eventuell einmal freischalten, je nach Standardkonfiguration in deiner Distribution.

https://de.wikipedia.org/wiki/Sudo


Bzw. falls es mehr zu tun gibt als einen Befehl auszuführen su, dann hat man länger root Rechte, weil substitute user auf root defaulted, wenn man keinen anderen Benutzer angibt.

[Rooter]

Ich dachte dafür wäre sudo -i das Mittel der Wahl!?

MfG
Rooter

[fezie]

Ich dachte dafür wäre sudo -i das Mittel der Wahl!?

MfG
Rooter

Zwischen "su -" (- für loginshell) und sudo -i ist jetzt nicht so der große Unterschied.
Vorallem wenn man auf seinem eigenen PC ist und keine Besonderheiten der /etc/sudoers Konfig nutzt

[Simon Moon]

Heutzutage nutzt man für sowas sudo, nicht das anmelden per root (deshalb ist ssh root Zugriff auch normalerweise deaktiviert).


Imo ist diese Sitte ziemlicher Bloedsinn, gerade mit der Standard Konfiguration in der sudo mit dem Userpassword ausgefuehrt wird.

Sicherer ist da imo:

Die sudo Rechte mit capabilities und entsprechenden Systemusern / Programmgruppen soweit wies passt zu beschraenken. Dann starten die Programme auch gar nicht erst mit root rechten, sondern nur den Faehigkeiten, die Aufgabe benoetigt werden. Das kann man dann nach belieben verfeinern - im Sudoers file was die Rechteverwaltung anbelangt, unter pam.d was die Authentifizierung betrifft.

Den root Account bleibt dabei auf VT1 & 2 beschraenkt. Ein VT kannst du fuer Logging zu Stdout nutzen, das angdere um als root zu arbeiten, wenn es denn mal notwendig sein sollte. Generell bleibt aber die Arbeitsumgebung von root spartanisch - je weniger Prozesse aktiv sind, desto weniger koennen exploited werden.

Mit pam kann man auch eine 2FA ueber SSH konfigurieren. Je nachdem vielleicht am besten mit einem eigenen User fuer SSH zuegriff. Das Hauptproblem bei root Anmeldung ueber SSH ist dabei soweit ich vertanden habe, dass dadurch ein Angreifer root Rechte erlangen koennte, wenn er den sshd Socket davor entsprechend praepariert hat.

[Snoopy69]

So, endlich gelöst... :freak:
Man muss zuerst das Übertragungsprotokoll von Standard "SFTP" auf "SCP" umstellen...
https://abload.de/img/cgbd3rk71.jpg


Dann in den "Erweiterten Einstellungen" bei "SCP/Shell" -> "Shell" von "Standard" auf "sudo su -" umstellen - Fertig!!! :uup:
Jetzt kann ich quasi ALLES machen! Und ich musste nicht mal was in Ubuntu umschreiben :)
https://abload.de/img/vsdvf0kgi.jpg

[myMind]

Schön wenn es funktioniert. Trotzdem wiederhole ich nochmal die Empfehlung von fezie auf ssh zu setzen für Remotelogins. Passwörter nur für lokale Logins zulassen. Das ist weitaus sicherer und daher auch standardmäßig so vorkonfiguriert.

Beispielanleitung mit PuTTY:
https://www.howtoforge.de/anleitung/key-basierte-ssh-logins-mit-putty/

WinSCP kann den Pageant von PuTTY dann nutzen: "Versuche Authentifizierung über Pagent".

[fezie]

Dann in den "Erweiterten Einstellungen" bei "SCP/Shell" -> "Shell" von "Standard" auf "sudo su -" umstellen - Fertig!!! :uup:


Diese Unsitte mit sudo und su in einem Befehl zu kombinieren werde ich nie verstehen.
Wie oben bereits erwähnt:
Entweder "su -" odder "sudo -i" reicht aus für eine Login Shell

[Simon Moon]

Schön wenn es funktioniert. Trotzdem wiederhole ich nochmal die Empfehlung von fezie auf ssh zu setzen für Remotelogins. Passwörter nur für lokale Logins zulassen. Das ist weitaus sicherer und daher auch standardmäßig so vorkonfiguriert.


SCP ist dasselbe Protokoll wie SSH, das eine Programm nennt sich einfach SecureCoPy, das andere SecureSHell. Ebenso dann noch eines der beiden verschluesselten FTPs - gibt da irrsinnigerweise SFTP und FTPS. Ich glaub das Ziel war da die Bedienung von FTP auf dem SSH Protokoll nachzubilden.

[myMind]

SCP ist dasselbe Protokoll wie SSH, das eine Programm nennt sich einfach SecureCoPy, das andere SecureSHell. Ebenso dann noch eines der beiden verschluesselten FTPs - gibt da irrsinnigerweise SFTP und FTPS. Ich glaub das Ziel war da die Bedienung von FTP auf dem SSH Protokoll nachzubilden.
Das ist richtig. Es ging mir auch weniger um die Sicherheit der Transportverschlüsselung als um die Sicherheit des Logins. Einen Remotelogin nur mit einem Passwort abzusichern ist einfach keine gute Idee. Insbesondere für User, die administrative Rechte erlangen können. Schlüssel mit Passphrase ist schon deutlich sicherer.

Mit einem ssh-agenten hat man einen sehr guten Kompromiss zwischen Komfort und Sicherheit. Jedenfalls weitaus besser als die Adminpasswörter in diversen Tools zu hinterlegen, wo man nie weiß ob sie sicher gespeichert werden.

Es ist ein wenig Aufwand einen ssh-client wie PuTTY und einen ssh-agent wie Pageant aufzusetzen und unter Windows ist das Thema auch wirklich alles andere als schön. Der Aufwand lohnt sich aber. Wenn man sich bei Github einloggen will oder eine Remote-Linux-VM mieten möchte, oder ähnliches ist man schon mal gut vorbereitet.

Den in Github hinterlegten Public-Key, kann man sich bei der Ubuntuinstallation auch gleich im root-Account eintragen lassen. Fingerprint prüfen und ready to go.

Das einzig ärgerliche ist eigentlich Microsofts Unfähigkeit OpenSSH gescheit in Windows zu integrieren. Offiziell ist alles schon bei Windows 10 dabei (link: OpenSSH in Windows (https://docs.microsoft.com/de-de/windows-server/administration/openssh/openssh_overview)). Ich schau mir das allenthalben mal wieder an und es ist jedesmal an zentralen Stellen kaputt. "Windows OpenSSH" kann sich im Dauerkaputtheitsgrad durchaus mit der "Windows Suche" messen, was schon was heißt. Aber für den Hausgebrauch reicht auch PuTTY mit Pageant.

[Snoopy69]

Diese Unsitte mit sudo und su in einem Befehl zu kombinieren werde ich nie verstehen.
Wie oben bereits erwähnt:
Entweder "su -" odder "sudo -i" reicht aus für eine Login Shell
Diese Unsitte stand im Netz - ich hab sie nur ausprobiert und diese Unsitte funktionierte :freak:

[Benutzername]

Diese Unsitte stand im Netz - ich hab sie nur ausprobiert und diese Unsitte funktionierte :freak:


Ja. funktioniert. Ist aber unnötig doppelt gemoppelt.


Ansonsten immer auch die manpages konsultieren.

man su
man sudo

[Simon Moon]

Das ist richtig. Es ging mir auch weniger um die Sicherheit der Transportverschlüsselung als um die Sicherheit des Logins. Einen Remotelogin nur mit einem Passwort abzusichern ist einfach keine gute Idee. Insbesondere für User, die administrative Rechte erlangen können. Schlüssel mit Passphrase ist schon deutlich sicherer.


Im lokalen Netz ist es denke ich vertretbar sich ausnahmsweise mit einem Passwort anzumelden. Zumindest die ssh Programme geben dir ja auch eine Warnung wenn sich der Host Key geändert hat - wie das bei PuTTY ist, weiss ich aber nicht.

Ich hab bei mir sowieso vor mal ein etwas feinergranuliertes Konzept einzustellen. Einerseits, damit ich nicht bei jedem sudo das Passwort eingeben muss. z.b. wenn ich nur journalctl aufrufe reicht denke ich ein Systemuser mit der Fähigkeit die Systemlogs anzusehen (cap_audit_view oder so). Andererseits gibts dann Dinge die mein Account (an meinen lokalen Desktop Geräten) gar nicht können soll - z.b. eben su [root], sudo su etc. Auf diesen Geräten kann ich mich ja auch auf einem VT seperat als root einloggen. An den remote headless Geräten soll root dann per 2FA gesichert sein.

Ist aber gar nicht so einfach, da die meisten Systeme die Capabilities nicht wirklich konfiguriert haben und das ganze Konzept auf der schlichten User/Root Trennung basieren. Fedora scheint mir da etwas weiter zu sein, dort läuft eigentlich kein Prozess mit allen Caps (soweit ich mal 20min in einer VM reingeschaut habe).

Was ich bei den Standardkonfigurationen eben seh, mal angenommen ich wollte da angreifen, dann würde ich mich nicht direkt an einem statischen Serveraufbau abmühen, sondern eher versuchen ein Nutzerkonto zu kompromittieren und da wüsste ich z
b. gerade nicht, was (in der normalen Konfiguration) ein Script mit Symlink zu sudo verhindern würde. Nun klar heißt es, man soll nur Software und Scripte ausführen die sicher sind, aber dann könnte man ja auch einfach sagen, man soll nur Passwörter eingeben wenn man den Hostkey überprüft hat.

[Snoopy69]

Habe herausfinden können, warum ich überhaupt über WinSCP auf "root" zugreifen kann...
Das wurde oben schon von euch besprochen - es geht um "/etc/sudoers"

Darin steht...
#
# This file MUST be edited with the 'visudo' command as root.
#
# Please consider adding local content in /etc/sudoers.d/ instead of
# directly modifying this file.
#
# See the man page for details on how to write a sudoers file.
#
Defaults env_reset
Defaults mail_badpass
#Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"

#environment variables that should be kept
Defaults env_keep += "http_proxy https_proxy"

# Host alias specification

# User alias specification

# Cmnd alias specification

# User privilege specification
root ALL=(ALL:ALL) ALL

# Members of the admin group may gain root privileges
%admin ALL=(ALL) ALL

# Allow members of group sudo to execute any command
%sudo ALL=(ALL:ALL) ALL

user ALL=(ALL) NOPASSWD:ALL

# See sudoers(5) for more information on "#include" directives:

#includedir /etc/sudoers.d

Die rot markierten Stellen sind Einträge im Ubuntu-Fork. Der Rest entspricht exakt den Einträgen im normalen Ubuntu. Ich habe den Eintrag "user ALL=(ALL) NOPASSWD:ALL" komplett gelöscht. Nachdem ich mit WinSCP fertig war.
Was "environment variables..." bewirkt, könnt ihr mir vielleicht sagen...!?

Desweiteren hätte ich gerne, dass "root" (direkt am Rechner) nicht Standard ist, sondern erst über user per Passwort freigegeben werden muss. Hab allerdings noch nicht herausgefunden, was ich ändern muss
Und was könnte ich hier noch "entschärfen" oder besser so lassen? Ausserdem sollte der Rechner gegen Neustarten/Herunterfahren mit einem Passwort gesichert werden. Wie es bei Ubuntu möglich ist
# User privilege specification
root ALL=(ALL:ALL) ALL

# Members of the admin group may gain root privileges
%admin ALL=(ALL) ALL

# Allow members of group sudo to execute any command
%sudo ALL=(ALL:ALL) ALL

[Darkstar]

Diese Unsitte mit sudo und su in einem Befehl zu kombinieren werde ich nie verstehen.Ja. funktioniert. Ist aber unnötig doppelt gemoppelt.Das ist keine Unsitte und auch nicht doppelt gemoppelt, für die Ausführung von sudo su - benötigt man im Gegensatz zu su - nämlich keine Kenntnis vom root-Paßwort, um auf den User root zu wechseln.

[fezie]

Das ist keine Unsitte und auch nicht doppelt gemoppelt, für die Ausführung von sudo su - benötigt man im Gegensatz zu su - nämlich keine Kenntnis vom root-Paßwort, um auf den User root zu wechseln.

Und warum nicht einfach ein sudo -i? Damit bekommt man genauso eine Login Shell als root

[Snoopy69]

Oben stehen noch paar Fragen :wave2:

[Darkstar]

Und warum nicht einfach ein sudo -i? Damit bekommt man genauso eine Login Shell als rootUm nur irgendeine Login-Shell als root zu bekommen, mag das reichen, aber nicht, um z. B. den feinen Unterschied zwischen sudo su und sudo su - abzubilden.
Was "environment variables..." bewirkt, könnt ihr mir vielleicht sagen...!?Dort kann man Variablen (des ausführenden Nicht-root-Users) angeben, die dann bei der Ausführung mit sudo weiterhin vorhanden sein sollen (siehe How to keep environment variables when using sudo (https://stackoverflow.com/questions/8633461/how-to-keep-environment-variables-when-using-sudo)).

Zu den anderen Fragen kann ich nichts beitragen.

[Simon Moon]

Habe herausfinden können, warum ich überhaupt über WinSCP auf "root" zugreifen kann...
Das wurde oben schon von euch besprochen - es geht um "/etc/sudoers"

Darin steht...
#
# This file MUST be edited with the 'visudo' command as root.
#
# Please consider adding local content in /etc/sudoers.d/ instead of
# directly modifying this file.
#
# See the man page for details on how to write a sudoers file.
#
Defaults env_reset
Defaults mail_badpass
#Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"

#environment variables that should be kept
Defaults env_keep += "http_proxy https_proxy"

# Host alias specification

# User alias specification

# Cmnd alias specification

# User privilege specification
root ALL=(ALL:ALL) ALL

# Members of the admin group may gain root privileges
%admin ALL=(ALL) ALL

# Allow members of group sudo to execute any command
%sudo ALL=(ALL:ALL) ALL

user ALL=(ALL) NOPASSWD:ALL

# See sudoers(5) for more information on "#include" directives:

#includedir /etc/sudoers.d

Die rot markierten Stellen sind Einträge im Ubuntu-Fork. Der Rest entspricht exakt den Einträgen im normalen Ubuntu. Ich habe den Eintrag "user ALL=(ALL) NOPASSWD:ALL" komplett gelöscht. Nachdem ich mit WinSCP fertig war.
Was "environment variables..." bewirkt, könnt ihr mir vielleicht sagen...!?

Desweiteren hätte ich gerne, dass "root" (direkt am Rechner) nicht Standard ist, sondern erst über user per Passwort freigegeben werden muss. Hab allerdings noch nicht herausgefunden, was ich ändern muss
Und was könnte ich hier noch "entschärfen" oder besser so lassen? Ausserdem sollte der Rechner gegen Neustarten/Herunterfahren mit einem Passwort gesichert werden. Wie es bei Ubuntu möglich ist
# User privilege specification
root ALL=(ALL:ALL) ALL

# Members of the admin group may gain root privileges
%admin ALL=(ALL) ALL

# Allow members of group sudo to execute any command
%sudo ALL=(ALL:ALL) ALL


Also, aber dafuer will ich wissen, was fuer ein Ubuntu Fork das ist. Ich will mir das mal reinziehen. X-D

Alles was kein # am Anfang hat, wird der Reihe nach aufsumiert und am Ende ausgefuehrt. Ganz oben steht bei dir ja auch "Defaults env_reset" - das heisst, als Variablen die nicht wieder aufadiert werden bis zum Ende des Scripts, werden wahrend der Ausfuehrung von Sudo geloescht. Das liegt daran, dass man in den Variableben auch Befehle speichern kann und mit etwas tricksen sowas wie /bin/bash ausfuehrend, waehrend man rootrechte hat (und die so dann behalten).

Die Syntax bei den ALL ALL ALL Dingen ist wie folg:

%GRUPPE AUF_HOST = DARF_ALS_USER DIESE_BEFEHLE

Wenn kein % am Anfang steht, ist damit ein Benutzer gemeint, % bezieht sich auf Gruppen. Was vor dem Gleich steht ist eine Bedingung, was nach dem Gleich steht ist was man darf. Also die Gruppe %admin darf an allen Hosts als jeder USER jeden Befehl ausfuehren. Die Gruppe sudo hat dann ja noch (ALL:ALL) direkt nach dem gleich, das bedetet er darf nicht nur den User wechseln, sondern auch die Gruppe ... was aber voellig irrelevant ist, da du als root sowieso auch die Gruppe wechseln kannst.
Hier gibts sonst noch die ganze Anleitung (aber ich bezweifel, dass du dich da durchlesen wirst):
https://man.archlinux.org/man/sudoers.5.en


Ich nehm mal an user hiess nicht user sondern war dein Account? Dann hast du dich gleich mal aus der sudoers rausgeworfen. Weisst du, ob du der sudoers oder admin Gruppe angehoerst oder hast du ein seperates Root-Passwort?

Habe herausfinden können, warum ich überhaupt über WinSCP auf "root" zugreifen kann...

Nein, hast du nicht, denn dann wuesstest du die Antwort - die wir hier im Thread schon die ganze Zeit besprechen - und wuerdest nicht diese Frage stellen:
Desweiteren hätte ich gerne, dass "root" (direkt am Rechner) nicht Standard ist, sondern erst über user per Passwort freigegeben werden muss. Hab allerdings noch nicht herausgefunden, was ich ändern muss

Dein PuTTY meldet sich als als User an, genau so wie du es eingestellt hast:
https://abload.de/img/cgbd3rk71.jpg

Und dann hast du eingestellt, dass es nach dem Login als Erstes mit der Bedingung automatisch sudo (substitute user do) su (substitute user) ausfuehrt:
https://abload.de/img/vsdvf0kgi.jpg

Es gibt da jetzt imo zwei Moeglichkeiten, vielleicht mal kurz selber nachdenken was du da tust oder du loest das Problem einfach in dem du an den PuTTY das "su" durch diesen kurzen Befehl ersetzt, damit es dann so aussieht:
bösartigen Befehl entfernt

Damit loeschst du das Root Verzeichnis und danach ist "root" (direkt am Rechner) nicht mehr Standard.

[Snoopy69]

Also, aber dafuer will ich wissen, was fuer ein Ubuntu Fork das ist. Ich will mir das mal reinziehen. X-D

Natürlich... :wink:
https://download.hiveos.farm/latest/

Was war das für ein "bösartiger Befehl"? :confused:

[Simon Moon]

Wow, das ist wirklich scheisse. Gefaellt es dir?

[Snoopy69]

Was genau?