Hey liebe Leute,
ich konnte zuvor immer eine SSH-Verbindung mit meinem RPi aufbauen.
Nachdem ich jedoch paar Einstellungen vorgenommen habe, kann ich mich in
putty gar nicht mehr anmelden.
Wen es interessiert ich habe einige SSh-Einstellungen konfiguriert,
damit ich root-Rechte besitzen kann.
Kann mir bitte jemand helfen
Mans A. schrieb:> Nachdem ich jedoch paar Einstellungen vorgenommen habe, kann ich mich in> putty gar nicht mehr anmelden.
Dann mach sie rückgängig, lokal solltest Du ja noch draufkommen.
Mans A. schrieb:> Wen es interessiert ich habe einige SSh-Einstellungen konfiguriert,> damit ich root-Rechte besitzen kann.
Du kannst auch "root-Rechte besitzen", ohne den sshd zu
verkonfigurieren, man muss sich ja nicht unbedingt direkt als root
einloggen.
Mans A. schrieb:> Kann mir bitte jemand helfen
Wenn ich mir Deine anderen Threads so angucke, ist Dir vermutlich nicht
zu helfen. Auch der vollkommen nichtssagende Screenshot, der die
eigentlich interessante Fehlermeldung nicht zeigt, untermauert diesen
Eindruck.
Mans A. schrieb:> Kann mir bitte jemand helfen
Wenn du zielsicher jegliche zweckdienliche Information vermeidest, wird
das schwierig.
> ich habe einige SSh-Einstellungen konfiguriert
Das Mindeste wäre doch wohl gewesen, die Änderungen zu nennen.
Hmmm schrieb:> man muss sich ja nicht unbedingt direkt als root einloggen.
Das ist etwas, was mal sowieso verbieten sollte. Zumindest bei
Produktivsystemen. Aber dann auch gleich für ftp mit.
Ich habe mich gerade mal auf deinem Raspi umgesehen. Leider ist er aus
dem Internet erreichbar und jemand hat die Selbstzerstörung aktiviert.
Der Prozess ist bald abgeschlossen, also schnell aus dem Fenster damit!
Jochen schrieb:> Hmmm schrieb:>> man muss sich ja nicht unbedingt direkt als root einloggen.>> Das ist etwas, was mal sowieso verbieten sollte. Zumindest bei> Produktivsystemen.
Ich habe zuhause einige Server & Container. Die meisten davon haben -
abgesehen von den Usern für die jeweiligen Services - nur den root User.
Ausnahmen sind mein Mail und Webserver. Wäre z.B. auf meinem DNS Server
oder meinem log Server auch ziemlich sinnlos, da verbinde ich mich eh
nur, wenn ich was um konfigurieren & restarten muss, oder sonst was
schräg ist, und dann brauche ich sowieso root.
Solange man root nicht per simplem Passwört wie root, pi, toor,
passwort123, tom, oder "correct horse battery staple" absichert, ist das
kein Problem.
Und wenn einem trotzdem Unwohl ist, nennt man root halt stattdessen adm
oder so, kann man ja in der passwd ändern. (Man kann auch mehrere
Usernamen mit uid 0 haben, wenn man root als gesperrten user behalten
will, aus Kompatiblitätsgründen.).
Mans A. schrieb:> Nachdem ich jedoch paar Einstellungen vorgenommen habe, kann ich mich in> putty gar nicht mehr anmelden.
Vermutlich hast du diese Einstellungen in sshd.conf vorgenommen und
dabei Mist gebaut, so dass sich ein ungültiges Konfigurationsfile ergab.
Dann startet der sshd erst garnicht und dementsprechend sind auch keine
Verbindungen zu ihm möglich.
Mach' deine Änderungen rückgängig und starte den sshd neu und alles ist
wieder gut. Zumindist auf dem vorigen Stand.
> Wen es interessiert ich habe einige SSh-Einstellungen konfiguriert,> damit ich root-Rechte besitzen kann.
Das ware nur ein einziger Eintrag, der in sshd.conf zu ändern wäre.
Allerdings solltest du vorher zumindest dafür sorgen, dass für root ein
(nichttriviales) Passwort gesetzt ist.
Mans A. schrieb:> ich konnte zuvor immer eine SSH-Verbindung mit meinem RPi aufbauen.>> Nachdem ich jedoch paar Einstellungen vorgenommen habe, kann ich mich in> putty gar nicht mehr anmelden.>> Wen es interessiert ich habe einige SSh-Einstellungen konfiguriert,> damit ich root-Rechte besitzen kann.
Möglicherweise hast Du einen Tippfehler in Deiner /etc/ssh/sshd_config,
und der SSH-Daemon startet deswegen nicht mehr. Das kannst Du leider nur
beheben, indem Du Dich lokal anmeldest oder die SD-Karte in einen
Rechner steckst, der das Dateisystem Deines RasPi lesen und beschreiben
kann, so daß Du die Datei wieder korrigieren kannst. Wenn Du nicht
zufällig ein Linux mit SD-Kartenslot hast, ist es vielleicht einfacher,
ein frisches Raspbian-Image auf die SD-Karte zu schreiben und von vorne
anzufangen -- YMMV. Achtung: Windows-Editoren machen manchmal als
Zeilenumbruch ein "\r\n" anstelle des unter UNIXen gebräuchlichen "\n",
das kann UNIX-Programme (und meiner Erinnerung nach auch den SSH-Daemon)
so verwirren, daß sie nicht starten.
Übrigens, auch wenn es in Deinem privaten Netzwerk ist: PermitRootLogin
setzt man eigentlich nicht auf "yes", zumindest "prohibit-password"
sollte gesetzt sein, so daß Du Dich zumindest mit Deinem
SSH-Schlüsselpaar als Root einloggen kannst. Das ist in der Regel aber
gar nicht notwendig, denn mit su(1) und sudo(1) gibt es sehr komfortable
und flexible Programme zur Privilegienerweiterung. Im Falle von sudo(1)
kannst Du mit dem Programm visudo(1) sogar bis auf Programmebene hinab
ganz genau konfigurieren, wer welches Programm mit welchen Parametern,
mit oder ohne Eingabe seines eigenen oder eines systemweiten Passworts
ausführen kann. Bitte benutze lieber diese Mechanismen als Deinen
SSH-Daemon so zu konfigurieren, daß er einen direkten Root-Zugang
erlaubt.
Letzter Tipp: wenn man an der sshd_config eines Remote-Rechners
arbeitet, ist es sinnvoll, zusätzlich eine zweite SSH-Verbindung mit
einer Rootshell offen zu haben, damit man seine Änderungen im Fehlerfall
zurücksetzen kann. Viel Spaß und Erfolg!
Jochen schrieb:> Hmmm schrieb:>> man muss sich ja nicht unbedingt direkt als root einloggen.>> Das ist etwas, was mal sowieso verbieten sollte.
Deswegen tut der sshd das ja in der Standardeinstellung.
> Zumindest bei Produktivsystemen.
Auch bei Entwicklungssystemen.
> Aber dann auch gleich für ftp mit.
FTP sollte man schon lange nicht mehr benutzen.
Ein T. schrieb:> Jochen schrieb:>> Hmmm schrieb:>>> man muss sich ja nicht unbedingt direkt als root einloggen.>>>> Das ist etwas, was mal sowieso verbieten sollte.>> Deswegen tut der sshd das ja in der Standardeinstellung.
Das ist falsch. Du kannst dich immer per Public Key als root einloggen,
sofern in root.ssh eine entsprechende authorized_keys liegt.
>>> Zumindest bei Produktivsystemen.>> Auch bei Entwicklungssystemen.
Kannst du erklären warum? Warum sollte der Login als Root per Public Key
unsicher sein? Kann man meines Erachtens auch bei Produktivsystemen
machen, sofern man selbst der einzige Admin ist.
Carla Audimarie schrieb:> Kannst du erklären warum?
Weil es nicht nötig ist?
Welchen Grund, ausser Bequemlichkeit, gibt es sich Remote als Root
anzumelden?
Jürgen schrieb:> Weil es nicht nötig ist?> Welchen Grund, ausser Bequemlichkeit, gibt es sich Remote als Root> anzumelden?
Außer Bequemlichkeit tatsächlich keinen. Aber was spricht dagegen? sudo
Orgien oder sudo su erhöhen die Sicherheit ja nun wirklich nicht.
Carla Audimarie schrieb:> sudo Orgien oder sudo su erhöhen die Sicherheit ja nun> wirklich nicht.
Bei mehreren Admins und getrennten Account separiert sudo die Passwörter
der Admins voneinander, so dass nicht alle das gleiche root-Pw kennen
müssen. Nützlich wenn jemand davon den Laden verlässt. Ausserdem steht
im Log, wer es war.
c-hater schrieb:> Mans A. schrieb:>>> Nachdem ich jedoch paar Einstellungen vorgenommen habe, kann ich mich in>> putty gar nicht mehr anmelden.>> Vermutlich hast du diese Einstellungen in sshd.conf vorgenommen und> dabei Mist gebaut, so dass sich ein ungültiges Konfigurationsfile ergab.> Dann startet der sshd erst garnicht und dementsprechend sind auch keine> Verbindungen zu ihm möglich.>> Mach' deine Änderungen rückgängig und starte den sshd neu und alles ist> wieder gut. Zumindist auf dem vorigen Stand.>>> Wen es interessiert ich habe einige SSh-Einstellungen konfiguriert,>> damit ich root-Rechte besitzen kann.>> Das ware nur ein einziger Eintrag, der in sshd.conf zu ändern wäre.> Allerdings solltest du vorher zumindest dafür sorgen, dass für root ein> (nichttriviales) Passwort gesetzt ist.
Hallo c-Hater, erst einmal vielen Dank für deine Antwort!
Wie du es schon vermutet hast, habe ich Einstellungen in sshd.conf
vorgenommen.
Genauer habe ich diesen Befehl ausgeführt:
sudo nano /etc/ssh/sshd_config
und dann habe ich
permitrootlogin prohibit-password
in
PermitRootLogin yes
abgeändert.
Ich habe mir damit erhofft root-Rechte zu ergattern. Ich bin noch ein
totaler Anfänger.
Nun ich weiß jetzt gar nicht mehr wie ich die Einstellungen rückgängig
machen kann. Ich kann jetzt über putty keine SSH-Verbindung zu meinem
raspberry pi aufbauen.
Mans A. schrieb:> Genauer habe ich diesen Befehl ausgeführt:>> sudo nano /etc/ssh/sshd_config
Du kennst also schonmal sudo.
Mans A. schrieb:> und dann habe ich> permitrootlogin prohibit-password> in> PermitRootLogin yes> abgeändert.
Was hast Du danach noch getan?
Mans A. schrieb:> Ich habe mir damit erhofft root-Rechte zu ergattern. Ich bin noch ein> totaler Anfänger.
Wozu, wenn Du offenbar weisst, dass Du das bei Bedarf mit sudo tun
kannst?
Mans A. schrieb:> Ich kann jetzt über putty keine SSH-Verbindung zu meinem> raspberry pi aufbauen.
Warum hängst Du nicht eine Tastatur und einen Monitor dran und löst es
damit?
Mans A. schrieb:> permitrootlogin prohibit-password>> in>> PermitRootLogin yes>> abgeändert.
offensichtlich nicht, denn sonst koenntest Du Dich weiterhin mit einem
weiteren Benutzer (z.b. pi) anmelden und die Fehler korrigieren. Ich
weiss nicht, ob nano eine Kopie der Datei macht.
Moeglichkeiten sind jetzt noch Console (also Display und Tastatur
anschliessen) oder (falls Du einen getty auf tty1 laufen hast) serielle
Konsole.
Eine andere Linux-Maschine mit SD-Kartenleser hast Du nicht, oder?
Gruesse
Th.
(prx) A. K. schrieb:> Bei mehreren Admins und getrennten Account separiert sudo die Passwörter> der Admins voneinander, so dass nicht alle das gleiche root-Pw kennen> müssen.
Ist, wie zuvor beschrieben, bei mir nicht der Fall und wohl auch beim TO
nicht:
Carla Audimarie schrieb:> Kann man meines Erachtens auch bei Produktivsystemen> machen, sofern man selbst der einzige Admin ist.
Ganz davon abgesehen macht man die Authentifizierung sowieso nur per
Public Key. Da braucht keiner das Passwort zu kennen.
(prx) A. K. schrieb:> Nützlich wenn jemand davon den Laden verlässt.
Dann schmeißt man seinen Key automatisiert aus dem authorized_keys file.
Wenn man wirklich Sicherheit möchte, dann verbietet man Passwortbasierte
Authentifizierung komplett und für alle Benutzer.
(prx) A. K. schrieb:> Ausserdem steht> im Log, wer es war.
Was sieht man? Genau, wer sich eingeloggt hat. Wer einen Befehl
ausgelöst hat, siehst du immer noch nicht. Auch könnte ein Admin einfach
seine eigenen Logeinträge löschen oder sich als anderer Admin einloggen.
Wirklich sinnvoll wird das also erst, wenn alle Eingaben zentral und
unveränderlich protokolliert werden. Aber ja, bei mehreren Admins gehe
ich noch mit, dass man sich nicht direkt als Root einloggt.
Warum ich mir aber in meinem konkreten Fall zusätzliche Tipparbeit
machen sollte, konnte mir immer noch keiner Erklären.
Carla Audimarie schrieb:> Warum ich mir aber in meinem konkreten Fall zusätzliche Tipparbeit> machen sollte, konnte mir immer noch keiner Erklären.
Es ist ein grundsätzlicher Ansatz wenn es um Sicherheit geht. Du
versuchst möglichst wenig Angriffspunkte zu schaffen und wenn Du etwas
nur machst weil es bequem ist läßt Du es.
Wenn das Argument 'was soll schon passieren' auftaucht, ist schon ganz
am Anfang was falsch gelaufen.
Jürgen schrieb:> Es ist ein grundsätzlicher Ansatz wenn es um Sicherheit geht.
Dann frage ich doch gleich nochmal: Wie erhöht eine Tipporgie mit sudo
die Sicherheit?
Jürgen schrieb:> Du> versuchst möglichst wenig Angriffspunkte zu schaffen und wenn Du etwas> nur machst weil es bequem ist läßt Du es.
Welchen Angriffspunkt schafft der direkte Root Login bei einem einzigen
Admin?
Jürgen schrieb:> Wenn das Argument 'was soll schon passieren' auftaucht, ist schon ganz> am Anfang was falsch gelaufen.
Das ist ja noch nichtmal aufgetaucht. Ich sehe nur, dass es wesentlich
bessere Verfahren gibt, als irgendwelche sudo Tipporgien.
Sicherheit ist am Ende des Tages übrigens immer ein Kompromiss. Wenn ich
so argumentiere wie du, dann müssten wir noch eine ganze Menge
zusätzliche und echte Hürden beim Login per SSH einbauen. Nämlich OTP,
Hardwareschlüssel und Fail2Ban. Auf der Ebene sind wir aber bei ein paar
privat gehosteten Spielzeugkisten nicht.
Carla Audimarie schrieb:> Aber was spricht dagegen? sudo> Orgien oder sudo su erhöhen die Sicherheit ja nun wirklich nicht.
Nö einfach nur su, dann fragt er das gesetzte root-PW ab. Funktioniert
auf allen unixoden Systemen, sudo braucht es da nicht. sudo ist
eigentlich auch nicht dazu gedacht einen dauerhaften root-Zugang zu
bekommen.
Carla Audimarie schrieb:> Welchen Angriffspunkt schafft der direkte Root Login bei einem einzigen> Admin?
Das Thema dürfte inzwischen ausdiskutiert sein, Google wird Dir alle
wichtigen Erklärungen liefern. Irgendwann mag man das nicht mehr
wiederholen.
Zeno schrieb:> Nö einfach nur su, dann fragt er das gesetzte root-PW ab.
Dann verliere ich aber die hier zuvor genannten Vorteile. Da kann ich
mich dann wirklich auch direkt als root anmelden. Keine Sorge, ich kenne
su und administriere lang genug Linux Systeme.
Zeno schrieb:> sudo ist> eigentlich auch nicht dazu gedacht einen dauerhaften root-Zugang zu> bekommen.
Genau den brauche ich aber, wenn ich MEINE Server administriere. Da gibt
es nämlich keine Tätigkeit, die ich als Standarduser sinnvoll tun
könnte. Also warum sollte ich mich nicht direkt als Root einloggen?
Ganz davon abgesehen ist sudo die einzige sinnvolle Möglichkeit, um eben
das root Passwort nicht mit mehreren Administratoren gleichzeitig zu
nutzen.
Jürgen schrieb:> Das Thema dürfte inzwischen ausdiskutiert sein, Google wird Dir alle> wichtigen Erklärungen liefern. Irgendwann mag man das nicht mehr> wiederholen.
Du könntest dem ganzen ein für alle Male ein Ende setzen, indem du das
Killerargument nennen würdest. Scheinbar hast du es aber selbst nicht.
Ich habe zwar mal, wie du es mir angeraten hat, ein wenig gegooglet,
erhellend war das aber nicht.
Das Szenario ist immer das selbe: Jemand schaft es das root Passwort zu
erraten und sich einzuloggen. Das ist auf meinen Systemen überhaupt
nicht möglich. Für alle Benutzer wird Public Key Authentifizierung
erzwungen. Wo ist also die konkrete Bedrohung, wenn ich mich, als
einziger_ Admin direkt als root auf _meinen Servern anmelde?
Viel kritisicher wäre es, wenn ich mich mit einem anderen user und einem
schwachen Passwort anmelden würde, das anschließend auch noch direkt für
sudo su missbraucht werden könnte.
Carla Audimarie schrieb:> Du könntest dem ganzen ein für alle Male ein Ende setzen, indem du das> Killerargument nennen würdest.
Nein, das kann ich nicht. Es gibt nicht das Totschlagargument, es gibt
immer nur neue Diskussionen mit Leuten, die meinen 'so ist es bequemer
und was soll da schon passieren'.
Und wenn sogar Microsoft das kapiert hat und den Administrator per
default deaktiviert ... ;-)
Jochen schrieb:> Nein, das kann ich nicht. Es gibt nicht das Totschlagargument, es gibt> immer nur neue Diskussionen mit Leuten, die meinen 'so ist es bequemer> und was soll da schon passieren'.> Und wenn sogar Microsoft das kapiert hat und den Administrator per> default deaktiviert ... ;-)
Und was genau ist das Problem? Erklär es doch einfach!
Carla Audimarie schrieb:> Wo ist also die konkrete Bedrohung, wenn ich mich, als> einziger_ Admin direkt als root auf _meinen Servern anmelde?
Du könntest ein Programm/Skript/wasauchimmer aufrufen, das
verseucht/manipuliert wurde, um genau diesen Umstand Deiner Anmeldung
als root auszunutzen. Wenn das ein Programm ist, das im "sauberen"
Zustand kein sudo braucht (weil es gar nichts dramatisches macht), wie
z.B. "ls", dann kann das recht gründliche Folgen haben.
Ist halt wie ohne Gummi. Kann gutgehen, muss aber nicht.
DerEinzigeBernd schrieb:> Du könntest ein Programm/Skript/wasauchimmer aufrufen, das> verseucht/manipuliert wurde, um genau diesen Umstand Deiner Anmeldung> als root auszunutzen.
Endlich mal ein brauchbares Bedrohungsszenario, auf dessen Basis man
vernünftig argumentieren kann. Nun, zuvor wurde mir noch folgendes
geraten:
Zeno schrieb:> Nö einfach nur su, dann fragt er das gesetzte root-PW ab.
Da macht es wirklich keinen Unterschied, ob ich mich direkt als root
anmelde. Aber nur um Missverständnissen vorzubeugen: Meine Argumentation
bezieht sich ausschließlich auf meine eigenen Server, die nur ich
administriere. Auf meinem Desktop bin ich natürlich nicht permanent
root.
DerEinzigeBernd schrieb:> Wenn das ein Programm ist, das im "sauberen"> Zustand kein sudo braucht (weil es gar nichts dramatisches macht), wie> z.B. "ls", dann kann das recht gründliche Folgen haben.
ls braucht kein sudo? Dann versuchen wir das mal. Wir befinden uns auf
meinem Monitoring System. Eingeloggt sind wir mit dem Benutzer ansible,
der sudo aus Gründen mit NOPASSWD könnte. Aber das verwenden wir jetzt
mal nicht.
Zunächst liste ich mein /etc Verzeichnis auf (hier nur als Auszug):
Wie wir sehen, gehört das Konfigurationsverzeichnis für icinga dem
Benutzer nagios. Möchte ich icinga konfigurieren, muss ich vielleicht
auch wissen, wie es in dem Verzeichnis aussieht. Also mache ich
folgendes:
1
ansible@icinga:~$ ls /etc/icinga2/
2
ls: cannot open directory '/etc/icinga2/': Permission denied
Upps, geht ja gar nicht. Mir fehlen die Berechtigungen. Was kann ich da
machen? Nun, ich könnte tatsächlich auf Nummer sicher gehen und eine
Tipporgie beginnen:
1
$ sudo -u nagios ls /etc/icinga2
Und das für jede Datei, die ich nun editieren möchte ebenfalls. cd kann
ich dadurch auch nicht nutzen und muss jedes mal den gesamten Pfad
schreiben. Autocomplete funktioniert auch nicht. So macht das nun
wirklich niemand. Was also tatsächlich passieren wird, ist bestenfalls
noch folgendes:
1
$ sudo ls /etc/icinga2
oder aber schon wahrscheinlicher
1
$ sudo su
2
$ ls /etc/icinga2
Schon wurde das kompromittierte Binary als root ausgeführt, obwohl ich
mich nicht direkt als root am System angemeldet habe.
Nun gibt es aber noch einen anderen wichtigen Punkt. Nämlich die
Berechtigungen auf ls. Sehen wir uns zunächst an, wo ls sich befindet:
So bekommen wir also schonmal kein manipuliertes ls hin, denn ich
benötige Schreibrechte, die ich als normaler User nicht habe.
Alternativ könnten wir natürlich versuchen, unser evil ls im bin
Verzeichnis von root abzulegen oder in der root.bashrc rumzupfuschen,
um auf unser evil ls umzuleiten. Aber auch hier scheitert es an den
Schreibrechten, die ich nicht habe, wenn ich nicht root bin. Und wenn
ich root bin, dann brauche ich ls nicht mehr auszutauschen.
Das einzig valide Angriffsszenario wäre also eine Schwachstelle, mit der
ich als normaler Benutzer beliebige Dateien (über)schreiben können
müsste. Dann kann ich aber auch einfach ein Binary überschreiben, dass
zyklisch als root ausgeführt wird und benötige überhaupt keine
Nutzerinteraktion mehr.
Und wenn wir hier schon munter Binaries tauschen, frage ich einfach mal
ganz plump: Wer garantiert dir, dass das sudo, dass du aufrufst nicht
manipuliert wurde und dein Passwort im Klartext sonstwo hinschreibt? So
spontan würde mir da ein winziges shell script einfallen, das bei seinem
ersten Aufruf die Passwortabfrage von sudo simuliert, dein Passwort
speichert, falsches Passwort zurückgibt und sich danach selbst entfernt
und das echte sudo aufruft.
Fazit: Es ändert sich also nichts, wenn ich mich direkt als root per SSH
am System anmelde. Es gibt auf einem Server schlicht kaum Dinge, die man
wirklich sinnvoll ohne root Rechte administrieren kann. Dass man nicht
hingeht und z.B. apache oder freeradius als root startet, versteht sich
von selbst. Die werde ich aber mangels Leseberechtigung im
Konfigurationsverzeichnis und den niedrigen Ports auch nicht mit meinem
ansible user starten können.
DerEinzigeBernd schrieb:> Ist halt wie ohne Gummi. Kann gutgehen, muss aber nicht.
Nur hat dein Gummi leider ein Loch.
Tobi schrieb:> Mans A. schrieb:>> Kann mir bitte jemand helfen>> Toll. Ein schwarzer Bildschirm ist äußerst hilfreich...
Ja, die Dummheit ins Bild gefasst. Eindeutiger geht ja nicht. Es ist mir
unverständlich wie jemand auf so einen Beitrag auch nur versuchen will
zu antworten.
Carla Audimarie schrieb:> Hmmm schrieb:>>> sudo -i und sudo -s>> Wofür soll diese Kombination eigentlich gut sein?> Es gibt sudo su
Carl(a) mal wieder... Auch wenn Du wahrscheinlich bloss wieder trollen
willst:
sudo -i und -s starten direkt eine interaktive Shell (bei -i als
Login-Shell), während Dein "sudo su" nochmal sinnloserweise su
dazwischenhängt.
Ein T. schrieb:> Jochen schrieb:>> Hmmm schrieb:>>> man muss sich ja nicht unbedingt direkt als root einloggen.>>>> Das ist etwas, was mal sowieso verbieten sollte.>> Deswegen tut der sshd das ja in der Standardeinstellung.
Nö, tut er nicht. Er verbietet den Login als root mit Passwort.
Thomas W. schrieb:> Mans A. schrieb:>>> permitrootlogin prohibit-password>>>> in>>>> PermitRootLogin yes>>>> abgeändert.>> offensichtlich nicht, denn sonst koenntest Du Dich weiterhin mit einem> weiteren Benutzer (z.b. pi) anmelden und die Fehler korrigieren. Ich> weiss nicht, ob nano eine Kopie der Datei macht.>> Moeglichkeiten sind jetzt noch Console (also Display und Tastatur> anschliessen) oder (falls Du einen getty auf tty1 laufen hast) serielle> Konsole.>> Eine andere Linux-Maschine mit SD-Kartenleser hast Du nicht, oder?>> Gruesse>> Th.
Hi Thomas,
ich habe jetzt meinen Rpi am Monitor angeschlossen.
Wenn ich nun die ssh_config abändern und speichern will, erscheint
folgende Fehlermeldung:
error writing /etc/ssh/sshd_config read-only file system
Also die Datei ist schreibgeschützt.
Kannst du mir bitte weiterhelfen?
Mans A. schrieb:> Thomas W. schrieb:>> Mans A. schrieb:>>>>> permitrootlogin prohibit-password>>>>>> in>>>>>> PermitRootLogin yes>>>>>> abgeändert.>>>> offensichtlich nicht, denn sonst koenntest Du Dich weiterhin mit einem>> Hi Thomas,>> ich habe jetzt meinen Rpi am Monitor angeschlossen.>> Wenn ich nun die ssh_config abändern und speichern will, erscheint> folgende Fehlermeldung:>> error writing /etc/ssh/sshd_config read-only file system
Ofensichtlich ist was anderes kaputt (root-Filesystem r/o weist auf
einen schweren Fehler hin). Optionen sind kaputte SD-Card, das
freundliche rm *,
oder oder oder.
Neuaufsetzen waere mein Ansatz.
Gruesse
Th.
c-hater schrieb:> Mans A. schrieb:>>> Nachdem ich jedoch paar Einstellungen vorgenommen habe, kann ich mich in>> putty gar nicht mehr anmelden.>> Vermutlich hast du diese Einstellungen in sshd.conf vorgenommen und> dabei Mist gebaut, so dass sich ein ungültiges Konfigurationsfile ergab.> Dann startet der sshd erst garnicht und dementsprechend sind auch keine> Verbindungen zu ihm möglich.>> Mach' deine Änderungen rückgängig und starte den sshd neu und alles ist> wieder gut. Zumindist auf dem vorigen Stand.>>> Wen es interessiert ich habe einige SSh-Einstellungen konfiguriert,>> damit ich root-Rechte besitzen kann.>> Das ware nur ein einziger Eintrag, der in sshd.conf zu ändern wäre.> Allerdings solltest du vorher zumindest dafür sorgen, dass für root ein> (nichttriviales) Passwort gesetzt ist.
Hey C-Hater,
ich bin jetzt bei der ssh_config.
Allerdings bekomme ich folgende Fehlermeldung, wenn ich was ändern
möchte:
error writing /etc/ssh/sshd_config read-only file system
Weißt du vielleicht weiter
Mans A. schrieb:> Allerdings bekomme ich folgende Fehlermeldung, wenn ich was ändern> möchte:> error writing /etc/ssh/sshd_config read-only file system>> Weißt du vielleicht weiter
Du hast bereits eine Antwort bekommen, warum liest Du die nicht einfach?
Beitrag "Re: putty klappt nicht"
Hmmm schrieb:> Du hast bereits eine Antwort bekommen, warum liest Du die nicht einfach?
Die Blödheit sieht man doch schon am Eingangspost am schwarzen Bild.
Mans A. schrieb:> error writing /etc/ssh/sshd_config read-only file system>> Also die Datei ist schreibgeschützt.
Steht das da? Seltsam!
Ich lese da: das Dateisystem ist ›read-only‹, kann also nicht
beschrieben werden.
Carla Audimarie schrieb:> Ein T. schrieb:>> Auch bei Entwicklungssystemen.>> Kannst du erklären warum? Warum sollte der Login als Root per Public Key> unsicher sein? Kann man meines Erachtens auch bei Produktivsystemen> machen, sofern man selbst der einzige Admin ist.
Auch ein SSH-Key kann verloren gehen. Da ist es schon sinnvoll, vor der
Erlangung erweiterter Privilegien einen zweiten Faktor zu benötigen. Das
Ganze nennt sich fachsprachlich dann Zwei-Faktor-Authentifizierung (two
factor authentication) und gilt heute als Stand der Technik.
Ein T. schrieb:> Auch ein SSH-Key kann verloren gehen.
Da habe ich keine Angst vor. Mein echter private Key befindet sich im
Anhang. Viel Spaß damit. Für alle, die ihn sich nicht näher ansehen
möchten sei folgendes gesagt: Der Key ist mit einer ausreichend starken
Passphrase geschützt. Mein Passwortmanager kümmert sich um die
weitergabe dieses Passworts an den SSH Agent, sodass ich damit auch
keinen Kontakt habe.
Wer aber wirklich den Key geknackt hat, meldet sich bitte. Ich stelle
dann eine IP zur Verfügung, auf der * sich austoben kann. Alternativ
kann * auch das Internet absuchen, denn ein paar öffentliche IPs haben
diesen SSH Key für den root user hinterlegt.
Ein T. schrieb:> Da ist es schon sinnvoll, vor der> Erlangung erweiterter Privilegien einen zweiten Faktor zu benötigen.
Du wirfst hier gerade etwas durcheinander. Ein statisches Passwort ist
kein zweiter Faktor.
Wenn man wirklich echtes 2FA mit SSH machen möchte, dann nimmt man z.B.
das Modul pam_google_authenticator.so. Dieses integriert sich direkt in
die Passwortabfrage von sshd. Das kannst du aber auch machen, wenn du
dich direkt als root anmeldest.
Niemand garantiert dir, dass deine poor man's 2FA Lösung wirklich sicher
ist. Wie DerEinzigeBernd oben schon ausgeführt hat, könnte jemand
Binaries austauschen. In deinem Szenario kann ich mich bereits als User
anmelden. Ich kann also durch geschicktes rumpfuschen in der .bashrc
folgendes machen:
Carla Audimarie schrieb:> Wer garantiert dir, dass das sudo, dass du aufrufst nicht> manipuliert wurde und dein Passwort im Klartext sonstwo hinschreibt? So> spontan würde mir da ein winziges shell script einfallen, das bei seinem> ersten Aufruf die Passwortabfrage von sudo simuliert, dein Passwort> speichert, falsches Passwort zurückgibt und sich danach selbst entfernt> und das echte sudo aufruft.
Jetzt musst du nur genau einmal sudo benutzen, und deine heile Welt
liegt in Trümmern. Das würde übrigens (etwas abgeschwächt) auch
passieren, wenn dein sudo Passwort ein OTP Code wäre.
Deshalb: Echtes 2FA passiert bei der Anmeldung und nicht danach. Da du
2FA genauso für den root user aktivieren kannst, spielt auch hier der
direkte Login als root noch keine Rolle.
Ein T. schrieb:> Das> Ganze nennt sich fachsprachlich dann Zwei-Faktor-Authentifizierung (two> factor authentication) und gilt heute als Stand der Technik.
Na Herr Lehrer, da ich Ihnen jetzt erklärt habe, warum Ihre bisher
eingesetzte Lösung kein 2FA ist: Ran an die Arbeit und den Stand der
Technik herstellen! Stand der Technik ist übrigens auch, dass der zweite
Faktor auf einem getrennten Gerät gespeichert und erzeugt wird. Auch das
ist bei einem Passwort im Passwortmanager nicht gegeben.
Carla Audimarie schrieb:> Ein T. schrieb:>> Auch ein SSH-Key kann verloren gehen.>> Da habe ich keine Angst vor. Mein echter private Key befindet sich im> Anhang. Viel Spaß damit. Für alle, die ihn sich nicht näher ansehen> möchten sei folgendes gesagt: Der Key ist mit einer ausreichend starken> Passphrase geschützt.
Dann hast Du ja doch Deine "Tipporgie".
> Wer aber wirklich den Key geknackt hat, meldet sich bitte. Ich stelle> dann eine IP zur Verfügung, auf der * sich austoben kann. Alternativ> kann * auch das Internet absuchen, denn ein paar öffentliche IPs haben> diesen SSH Key für den root user hinterlegt.
Ach Gottchen, Du Feigling. Stell Deine hochwichtige IP-Adresse doch
gleich zur Verfügung, wenn es Dir wirklich erst sein sollte.
> Du wirfst hier gerade etwas durcheinander. Ein statisches Passwort ist> kein zweiter Faktor.
Doch, natürlich. Erster Faktor "what you have" ist das Schlüsselpaar,
zweiter Faktor "what you know" ist das Paßwort. Vielleicht solltest Du
erstmal die Grundbegriffe lernen, bevor Du andere zu belehren versuchst
und Dinge schönredest, die dem anerkannten Stand der Technik
widersprechen.
> Wenn man wirklich echtes 2FA mit SSH machen möchte, dann nimmt man z.B.> das Modul pam_google_authenticator.so. Dieses integriert sich direkt in> die Passwortabfrage von sshd. Das kannst du aber auch machen, wenn du> dich direkt als root anmeldest.
Ja, das ist eine super Idee -- einen Teil der Verantwortung für Deine
Systeme an einen Dritten zu übertragen, der nicht einmal deutscher oder
wenigstens europäischer Juristiktion unterliegt. Wow.
> Niemand garantiert dir, dass deine poor man's 2FA Lösung wirklich sicher> ist. Wie DerEinzigeBernd oben schon ausgeführt hat, könnte jemand> Binaries austauschen. In deinem Szenario kann ich mich bereits als User> anmelden. Ich kann also durch geschicktes rumpfuschen in der .bashrc> folgendes machen:
Da steht irgendwie... nichts. Also wenn Du nichts mit meiner .bashrc
machst -- die übrigens nur dann ausgeführt wird, wenn ich die Bash
benutze -- dann sehe ich da jetzt nicht das geringste Problem. Bei Dir
hingegen kann der Angreifer die Abfrage Deines Paßwortes für ssh-agent
manipulieren und ist dann nicht nur im Besitz Deines Schlüssels, sondern
auch Deines Paßwortes.
Übrigens: wenn ein Angreifer auf Deinem System Binaries austauschen
kann, dann hat er bereits erweiterte Privilegien, und Du hast schon
längst verloren. Dagegen hilft Dir Dein Geschwätz dann auch nichts mehr,
tut mir leid.
> Ein T. schrieb:>> Das>> Ganze nennt sich fachsprachlich dann Zwei-Faktor-Authentifizierung (two>> factor authentication) und gilt heute als Stand der Technik.>> Na Herr Lehrer, da ich Ihnen jetzt erklärt habe, warum Ihre bisher> eingesetzte Lösung kein 2FA ist: Ran an die Arbeit und den Stand der> Technik herstellen!
Aber Kindchen, das hast Du doch gar nicht. Im Übrigen bin ich mit genau
dieser Art der Zwei-Faktor-Authentifizierung bereits durch mehrere
Sicherheitsaudits nach BSI-Grundschutz, PCI-DSS, HIPAA und ISO27k
gekommen, ohne daß das je beanstandet wurde. Ganz im Gegenteil haben
sich bereits mehrere Auditoren positiv darüber geäußert, daß wir diese
Art von 2FA auch an Stellen nutzen, wo dies den Regularien nach gar
nicht erforderlich ist.
> Stand der Technik ist übrigens auch, dass der zweite> Faktor auf einem getrennten Gerät gespeichert und erzeugt wird. Auch das> ist bei einem Passwort im Passwortmanager nicht gegeben.
Wer redet denn von einem Paßwortmanager, außer Dir? Du solltest wirklich
genauer aufpassen und, vor allem, lesen -- ganz abgesehen davon, daß es
natürlich auch externe Paßwortmanager gibt und manche Menschen sogar die
kognitiven Fähigkeiten haben, sich mehrere Paßworte in dem biologischen
und meines Wissens bislang nicht maschinenlesbaren Gerät zwischen ihren
Ohren zu speichern.
Naja, lies einfach das BSI-Grundschutzhandbuch, das ist sogar auf
deutsch und dafür, daß es von einer Behörde kommt, sogar ziemlich
brauchbar. Und obendrein ist es das, was den besagten Stand der Technik
beschreibt, also jenen Sachstand, der spätestens dann wichtig wird, wenn
Du wegen grober Fahrlässigkeit auf Schadensersatz verklagt wirst. Viel
Spaß bei der Lektüre, bis demnächst.
Ein T. schrieb:> Dann hast Du ja doch Deine "Tipporgie".
Du musst schon weiter lesen:
Carla Audimarie schrieb:> Mein Passwortmanager kümmert sich um die> weitergabe dieses Passworts an den SSH Agent, sodass ich damit auch> keinen Kontakt habe.
Meinen Passwortmanager entsperre ich genau einmal beim Login mit meinem
Masterkey.
Ein T. schrieb:> Ach Gottchen, Du Feigling. Stell Deine hochwichtige IP-Adresse doch> gleich zur Verfügung, wenn es Dir wirklich erst sein sollte.
Gar nicht so einfach, da auf allen Systemen nochmal lokale Firewalls
laufen, aber bitte: 66.175.236.133. Ich würde aber auch erwarten, dass
jemand, der mal eben den Key knackt, auch die Kapazität hat, mal eben
einen Host zu finden. Wo habe ich eigentlich behauptet, dass meine
Systeme "hochwichtig" seien?
Das System ist ein Monitoring Satellit. Wer ihn kaputt machen möchte,
soll das gerne tun, den setze ich dann aus einem Image neu auf.
Ein T. schrieb:> Doch, natürlich. Erster Faktor "what you have" ist das Schlüsselpaar,> zweiter Faktor "what you know" ist das Paßwort. Vielleicht solltest Du> erstmal die Grundbegriffe lernen, bevor Du andere zu belehren versuchst> und Dinge schönredest, die dem anerkannten Stand der Technik> widersprechen.
Warum? Ich habe dir doch erklärt, wie man technisch richtiges 2FA im
sshd implementiert. Deine Lösung ist nunmal nur Murks, allein schon,
weil ein user für sich schon Schaden anrichten kann. Selbst wenn es nur
Kryptomining, Spamversand oder DDoS ist. What you know und what you have
sind auch so typische Begriffe, die hier leider nicht so richtig geil
sind. Denn ein wesentlicher Punkt bei einer 2FA Authentifizierung ist
doch, dass die Faktoren auf getrennten Geräten liegen und niemals
zusammengeführt werden. Dies verhindert auch bei einem kompromittierten
Gerät, dass ein Angreifer umfassenden Zugriff erhält.
Bei deiner Lösung greift das nicht. Denn das statische Passwort gebe ich
am Gerät ein und der Key liegt auf dem Gerät. Ist das Gerät
kompromittiert, sind beide Faktoren kompromittiert. Dazu kommt: Wer den
ersten Faktor kompromittiert hat, kompromittiert bei deiner Lösung auch
den zweiten. Wie das geht, erfährst du im nächsten Absatz. Arbeite ich
mit z.B. OTP auf einem zweiten Gerät, sieht das anders aus, denn der OTP
Code ist genau einmal gültig.
Ein T. schrieb:> Da steht irgendwie... nichts.
Da steht ein Zitat aus einem meiner Beiträge, in dem ich das schon
umfassend ausgeführt habe.
Ein T. schrieb:> Also wenn Du nichts mit meiner .bashrc> machst -- die übrigens nur dann ausgeführt wird, wenn ich die Bash> benutze -- dann sehe ich da jetzt nicht das geringste Problem.
Wenn du schon provozierst, bis der Arzt kommt, sollst du auch eine
fachliche Antwort kriegen. Irgendeine Shell wirst du schon nutzen. Die
meisten davon haben ein Äquivalent zur .bashrc. Welche Shell du nutzt,
sehe ich als Angreifer in dem diskutierten Szenario. Daher habe ich auch
alle Zeit der Welt, da etwas für dich zugeschnittenes zu bauen. Es gibt
auch genug nette Tricks, um ein Binary mit Nutzerrechten zu überlagern.
Einen zeige ich dir hier. Gerade getestet unter Debian 11.
Gegeben sei, dass der Angreifer sich bereits als der Benutzer ansible
einloggen kann. Also in deinem Szenario: Jemand hat den Key geklaut.
Zunächst prüfe ich, wo sudo liegt:
1
ansible@icinga:~$ which sudo
2
/usr/bin/sudo
Da kann ich natürlich nicht schreiben. Der Befehl sudo liefert
erwartungsgemäß
Ich kann aber natürlich in /home/ansible/ schreiben. Also lege ich ein
Verzeichnis mit dem namen bin an:
1
mkdir ~/bin
und platziere darin ein Textfile mit dem Namen sudo und dem folgenden
Inhalt:
1
#!/bin/bash
2
echo this is evilsudo
Das mache ich ausführtbar:
1
chmod +x ~/bin/sudo
Anschließend schließe ich die SSH Verbindung und öffne sie erneut.
Zuerst prüfe ich wieder, wo sudo liegt:
1
ansible@icinga:~$ which sudo
2
/home/ansible/bin/sudo
Das sieht gar nicht gut aus. Nun führe ich erneut sudo aus:
1
ansible@icinga:~$ sudo
2
this is evilsudo
Das alles nur mit Nutzerrechten. Fazit: Ich hätte deinen "zweiten
Faktor" also das Passwort hier abgreifen und weiterverwenden können. Er
ist also nicht wirksam.
Ein T. schrieb:> Bei Dir> hingegen kann der Angreifer die Abfrage Deines Paßwortes für ssh-agent> manipulieren und ist dann nicht nur im Besitz Deines Schlüssels, sondern> auch Deines Paßwortes.
Jetzt ändert sich aber mal ganz nebenbei dein Angriffsszenario und dein
Scope. Voraussetzung ist nämlich jetzt, dass der Angreifer auf meinem
lokalen Rechner ist. Bisher war die Prämisse, dass ein Angreifer meinen
Key gestohlen hat, und sich als user an einem Server anmeldet. Vor
diesem Hintergrund müssen wir sämtliche hier besprochenen Verfahren
nochmal komplett neu bewerten. Das mache im Ende meines Beitrags.
Ein T. schrieb:> Übrigens: wenn ein Angreifer auf Deinem System Binaries austauschen> kann, dann hat er bereits erweiterte Privilegien, und Du hast schon> längst verloren. Dagegen hilft Dir Dein Geschwätz dann auch nichts mehr,> tut mir leid.
Typ, das weiß ich doch. Das sind genau meine Worte aus einem meiner
vorherigen Posts. Wie man aber ein Binary überlagern kann, habe ich dir
ja jetzt gezeigt. Insofern auch kein "Geschwätz".
Ein T. schrieb:> Aber Kindchen, das hast Du doch gar nicht.
Aber Herr Lehrer, Ihre Lösung ist nunmal nicht wirksam.
Ein T. schrieb:> Im Übrigen bin ich mit genau> dieser Art der Zwei-Faktor-Authentifizierung bereits durch mehrere> Sicherheitsaudits nach BSI-Grundschutz, PCI-DSS, HIPAA und ISO27k> gekommen, ohne daß das je beanstandet wurde.
Aus der Ecke kommst du also. Ich muss aber mal wieder wiederholen, dass
es bei der bisherigen Diskussion um meine privaten Systeme ging. Da habe
ich mit BSI-Grundschutz, PCI-DSS, HIPAA und ISO27001 genau nichts zu
tun.
Wir haben da beide wohl tatsächlich eine unterschiedliche
Herangehensweise. Ich komme aus der Ecke Penetrationtests und Forensik.
Mein Job ist es, praktische Angriffsszenarien zu entwickeln, umzusetzen
und zu dokumentieren. Auch sehe ich, welche Angriffe in der Praxis
vorkommen.
Du dagegen setzt Leitlinien um. Dein Job ist es, dass der Auditor
hinterher glücklich ist. Da gibt es tatsächlich eine Menge Deltas, das
stimmt. Es gibt eine Menge Dinge, die ein Auditor sehen will, die aber
technisch dann nicht (unbedingt) sinnvoll umgesetzt sind. Ein schönes
Beispiel dafür sind DLP Systeme, die zwar gefordert werden, aber immer
nur begrenzt wirksam sind. Ein weiteres schönes Beispiel ist
Festplattenverschlüsselung. Auch die wird gefordert, die praktische
Umsetzung aber nur selten auf Wirksamkeit geprüft. Einer Meiner Kunden
dachte sogar über 10 Jahre, dass er eine Full Disk Encryption eingeführt
hätte. In einem Penetrationstest stellte sich dann heraus, dass keines
seiner Systeme verschlüsselt war, da in der Lösung ein Haken an der
falschen Stelle gesetzt wurde. Der Kunde war übrigens aus dem KRITIS
Sektor und entsprechend Auditiert.
Umgekehrt gibt es meine Herangehensweise, die der Auditor möglicherweise
nicht honoriert oder sogar ablehnt. Insofern kann ich unsere Differenz
jetzt durchaus verstehen. Wenn ich etwas umsetze, bewerte ich immer vor
dem Hintergrund eines Angriffs, betreibe Threat Modelling und entscheide
mich schließlich für die technisch sinnvollste Maßnahme.
Ein T. schrieb:> Ganz im Gegenteil haben> sich bereits mehrere Auditoren positiv darüber geäußert, daß wir diese> Art von 2FA auch an Stellen nutzen, wo dies den Regularien nach gar> nicht erforderlich ist.
Das ist sehr löblich. Das ändert aber nichts daran, dass deine Lösung
kein wirksames 2FA ist. Vielleicht erkennen Auditoren das als 2FA an,
aber so implementiert ist es leider nicht wirksam.
Ein T. schrieb:> Ja, das ist eine super Idee -- einen Teil der Verantwortung für Deine> Systeme an einen Dritten zu übertragen, der nicht einmal deutscher oder> wenigstens europäischer Juristiktion unterliegt. Wow.
Kann es sein, dass du von TOTP überhaupt keine Ahnung hast? Jedenfalls
liegt hier ein häufiges Missverständnis vor. Der Google Authenticator
nutzt den offenen TOTP Standard, den du auch mit jedem anderen TOTP
Authenticator nutzen kannst. Zu Google werden dabei überhaupt keine
Daten übertragen. Google ist lediglich als EIN Anbieter EINER
Implementierung.
Ein T. schrieb:> Wer redet denn von einem Paßwortmanager, außer Dir? Du solltest wirklich> genauer aufpassen und, vor allem, lesen -- ganz abgesehen davon, daß es> natürlich auch externe Paßwortmanager gibt und manche Menschen sogar die> kognitiven Fähigkeiten haben, sich mehrere Paßworte in dem biologischen> und meines Wissens bislang nicht maschinenlesbaren Gerät zwischen ihren> Ohren zu speichern.
Reicht doch, wenn ich das tue. Meine Systeme haben alle Passwörter mit
einer Mindestlänge von 40 Zeichen. Jedes System hat ein anderes
Passwort. Ich würde deine kognitiven Fähigkeiten wirklich gerne mal
herausfordern, aber ich denke, dass ich das Ergebnis schon kenne. Und
selbst wenn du dir all diese Passwörter merken kannst, bist du mit der
Eingabe doch schon sehr beschäftigt.
Ein T. schrieb:> Naja, lies einfach das BSI-Grundschutzhandbuch, das ist sogar auf> deutsch und dafür, daß es von einer Behörde kommt, sogar ziemlich> brauchbar.
Du meinst die Behörde, die für die Sicherheit des Bundestags... Habe
gerade mal nachgeschlagen, weil mir deine Ausführung komisch vorkamen.
Also zum Thema Passwortmanager steht da z.B. folgendes:
1
Passwörter DÜRFEN NICHT mehrfach verwendet werden. Für jedes IT-System bzw. jede Anwendung MUSS ein eigenständiges Passwort verwendet werden. Passwörter, die leicht zu erraten sind oder in gängigen Passwortlisten
2
geführt werden, DÜRFEN NICHT verwendet werden. Passwörter MÜSSEN geheim gehalten werden. Sie DÜRFEN
3
NUR dem Benutzer persönlich bekannt sein. Passwörter DÜRFEN NUR unbeobachtet eingegeben werden. Passwörter DÜRFEN NICHT auf programmierbaren Funktionstasten von Tastaturen oder Mäusen gespeichert werden. Ein
4
Passwort DARF NUR für eine Hinterlegung für einen Notfall schriftlich fixiert werden. Es MUSS dann sicher aufbewahrt werden. Die Nutzung eines Passwort-Managers SOLLTE geprüft werden.
Also zumindest das BSI spricht auch von Passwortmanagern, auch, wenn es
die nicht erzwingt. Auch spricht es von komplexen Passwörtern.
Ein T. schrieb:> Und obendrein ist es das, was den besagten Stand der Technik> beschreibt, also jenen Sachstand, der spätestens dann wichtig wird, wenn> Du wegen grober Fahrlässigkeit auf Schadensersatz verklagt wirst. Viel> Spaß bei der Lektüre, bis demnächst.
Wer soll mich denn verklagen, wenn meine privaten Systeme kompromittiert
werden? Kalibrier bitte mal deinen Scope. Und warum sollte ich verklagt
werden? Wo genau setze ich den Stand der Technik mit einer sauberen 2FA
Lösung nicht um?
Eine Sache bin ich dir aber noch schuldig. Nämlich die Neubewertung der
hier beschriebenen Verfahren bei Kompromittierung meines lokalen
Systems. Dazu zunächst in deinem Fall:
Der Angreifer erlangt Zugang zum SSH Key und schreibt das root Passwort
per Keylogger mit. Alternativ loggt er sich schon vorher mit deinem Key
an den Systemen ein und überlagert sudo. Außerdem kann er das System
bereits als Spamschleuder etc. missbrauchen.
In meinem Fall:
Der Angreifer erlangt Zugang zum SSH Key. Er versucht sich an den
Systemen anzumelden, kann dies aber nicht, da er den TOTP Code benötigt.
Der wird aber auf meinem Smartphone erzeugt. Der Angreifer kann nur
warten, bis ich mich am System anmelde und den Code selbst eingebe. Auch
auf dieses System könnte er dabei Zugriff erlangen, allerdings
wesentlich schwieriger, denn der Code ist schließlich nur einmal gültig.
Fazit: Die Auswirkungen werden bei meiner Lösung also begrenzt, während
bei dir direkt deine Useraccounts auf all deinen Servern betroffen sind.
Ein kompromittiertes Admin System ist aber immer Mist.
Sieh diesen Post bitte als sehr freundliche Geste das hier nicht
eskalieren zu lassen und fang jetzt nicht an rumzupöbeln. Stell aber
gerne dar, warum ich fachlich falsch liege.
Carla Audimarie schrieb:> Ich komme aus der Ecke Penetrationtests und Forensik.
Da gibts aktuell scheinbar wenig zu tun. Sonst hätte man nicht so viel
Zeit für solche Texte. Und das wo man doch Tipporgien hasst :)
Ich A. schrieb:> Da gibts aktuell scheinbar wenig zu tun. Sonst hätte man nicht so viel> Zeit für solche Texte. Und das wo man doch Tipporgien hasst :)
Habe nur eine vier Tage Woche. Warum ich mich aber mit irgendwem hier
rumärgere, frage ich mich manchmal auch. Sollte ich echt mal lassen.
Carla Audimarie schrieb:> Warum?
Damit Du auf ein Niveau kommst, von dem aus Du etwas erklären kannst.
> What you know und what you have> sind auch so typische Begriffe, die hier leider nicht so richtig geil> sind.
Knowledge (what you know), posession (what you have) und inherence (what
you are) sind in diesem Zusammenhang einschlägige Fachbegriffe.
>
1
> ansible@icinga:~$ which sudo
2
> /home/ansible/bin/sudo
3
>
Dein $PATH ist kaputt, noch so ein Sicherheitsproblem -- lustigerweise
aus genau dem Grund, den Du hier anführst.
> Wir haben da beide wohl tatsächlich eine unterschiedliche> Herangehensweise. Ich komme aus der Ecke Penetrationtests und Forensik.> Mein Job ist es, praktische Angriffsszenarien zu entwickeln, umzusetzen> und zu dokumentieren. Auch sehe ich, welche Angriffe in der Praxis> vorkommen.
Wenn Du tatsächlich aus dem Pentesting und der Forensik kämst, dann
würdest Du nicht so unseriös "argumentieren" -- schon gar nicht in einem
Thread, in dem ein Anfänger fragt. Zuerst erzählst Du, ein Remote Login
als Root sei kein Sicherheitsproblem -- aber im weiteren Verlauf des
Threads kommt dann heraus, daß das allerhöchstens für ganz bestimmte
Szenarien gilt, was Du da behauptest. Nämlich, wenn man a) seinen
SSH-Schlüssel mit einem Paßwort versieht, b) zu dessen komfortabler
Nutzung zudem ssh-agent(1), c) obendrein einen externen Paßwortmanager
benutzt, und dann gelten Deine Aussagen auch wieder nur dann, wenn man
ganz alleine der Superuser auf dem Zielsystem ist. Deine Argumentation
folgt einer Salamitaktik, die für unbedarfte Benutzer und für alle
anderen, die den Thread nicht bis zum Ende lesen, irreführend und
letzten Endes gefährlich ist.
> Du dagegen setzt Leitlinien um. Dein Job ist es, dass der Auditor> hinterher glücklich ist.
Nicht wirklich. Die Leitlinien sind nun einmal das, woran sich die
Kunden, Auditoren und am Ende womöglich auch die Gerichte orientieren.
Pentests lassen wir natürlich auch durchführen, aber die dokumentieren
ja nur eine Istsituation und dienen nur der Unterstützung und
Übberprüfung der Arbeit unserer Admins und Entwickler. Mein Job ist es,
nicht, irgendwen glücklich zu machen, sondern, unsere Kunden und uns zu
schützen, damit sie und wir nicht unglücklich werden.
Ein T. schrieb:> Dein $PATH ist kaputt, noch so ein Sicherheitsproblem -- lustigerweise> aus genau dem Grund, den Du hier anführst.
Du hattest die Chance das hier auf einem sachlichen Niveau zu halten. Du
hast dich leider dagegen entschieden und wirfst stattdessen, mal wieder,
mit Halbwahrheiten, anstatt dich mit mit der Realität
auseinanderzusetzen. Schade.
Dieses Verhalten ist der gewollte Standard auf dem System. Das ist sogar
in der .profile im Home Verzeichnis eines Debian users dokumentiert:
1
# set PATH so it includes user's private bin if it exists
2
if [ -d "$HOME/bin" ] ; then
3
PATH="$HOME/bin:$PATH"
4
fi
5
6
# set PATH so it includes user's private bin if it exists
7
if [ -d "$HOME/.local/bin" ] ; then
8
PATH="$HOME/.local/bin:$PATH"
9
fi
Mein $PATH ist also nicht "kaputt". Wurde aber auch genau GAR NICHTS
ändern. Denn in der eigenen .bashrc (oder dem Äquivalent deiner shell)
überschreibe ich mit Userrechten einfach die Path Variable:
1
PATH="/somethingthatdoesnotexist"
und schon passiert nach dem Login das hier:
1
ansible@icinga:~$ ls
2
-bash: ls: command not found
Oder eben das, was ich dir schon zuvor gezeigt habe. Es wird echt mal
Zeit, dass du dich mit Linux Systemen etwas beschäftigst.
Auch, dass es schon ein Problem ist, wenn sich ein Angreifer als
Benutzer am System anmelden kann, ignorierst du sehr gekonnt. Anstatt
einzusehen, dass dein Gebastel kein wirksames 2FA ist, faselst du lieber
etwas von falscher PATH Variable.
Ein T. schrieb:> Wenn Du tatsächlich aus dem Pentesting und der Forensik kämst, dann> würdest Du nicht so unseriös "argumentieren"
Das sind mir die liebsten, die sachlich argumentierenden die Seriösität
absprechen wollen, und das wohlgemerkt ohne auch nur ein sinnvolles
Argument gebracht zu haben.
Ein T. schrieb:> Zuerst erzählst Du, ein Remote Login> als Root sei kein Sicherheitsproblem -- aber im weiteren Verlauf des> Threads kommt dann heraus, daß das allerhöchstens für ganz bestimmte> Szenarien gilt, was Du da behauptest. Nämlich, wenn man a) seinen> SSH-Schlüssel mit einem Paßwort versieht, b) zu dessen komfortabler> Nutzung zudem ssh-agent(1), c) obendrein einen externen Paßwortmanager> benutzt, und dann gelten Deine Aussagen auch wieder nur dann, wenn man> ganz alleine der Superuser auf dem Zielsystem ist.
Völlig sinnfreier Kommentar. Den wichtigsten Aspekt, nämlich dass man
der einzige Admin ist, habe ich von Anfang an genannt. Ebenso die Public
Key Authenfizierung. Hier als Erinnerung für dich:
Carla Audimarie schrieb:> Kannst du erklären warum? Warum sollte der Login als Root per Public Key> unsicher sein? Kann man meines Erachtens auch bei Produktivsystemen> machen, sofern man selbst der einzige Admin ist.
Dass man seinen Private Key schützen sollte, hätte ich tatsächlich
erwähnen sollen. Ob man nun einen SSH-Agent oder einen Passwortmanager
einsetzt, tut dabei aber nichts zur Sache. Wo wir schon beim Thema sind:
Hast du den Key schon knacken können?
Ganz davon abgesehen solltest du mal dringend lernen, wie man Passwort
schreibt: https://www.duden.de/rechtschreibung/Passwort. Mal so ein Tipp
für Leitlinienfetischisten: Der Duden steht noch als übergeordnete
Leitlinie über dem BSI Grundschutz!
Ein T. schrieb:> Deine Argumentation> folgt einer Salamitaktik, die für unbedarfte Benutzer und für alle> anderen, die den Thread nicht bis zum Ende lesen, irreführend und> letzten Endes gefährlich ist.
Mit Salamitaktik hat das überhaupt nichts zu tun. Wir dürfen auch nicht
vergessen, dass der TO hier eben schon diese gefährliche Sache von
Anfang an versucht hat. Einen besseren Weg aufzuzeigen, um das selbe
Ziel zu erreichen, ist da völlig in Ordnung.
Ein T. schrieb:> Knowledge (what you know), posession (what you have) und inherence (what> you are) sind in diesem Zusammenhang einschlägige Fachbegriffe.
Dessen bin ich mir bewusst. An den konkreten Begriffen zu sehr
festzuhalten hilft aber nicht. Denn was ist ein SSH Key? Etwas, was ich
habe, oder etwas, was ich weiß? Wie das per Definition zu beantworten
ist, weiß ich. Aber ob die Antwort bei einem duplizierbaren Key, der bei
Kompromittierung des Systems genauso abgegriffen wird wie das Passwort,
wirklich sinnvoll ist, steht auf einem anderen Blatt. Denn dann entsteht
genau das, was du hier gebaut hast: 2FA ohne echten (technischen)
zweiten Faktor.
Du würdest ja auch bei einem Passwort im Passwortmanager nicht
argumentieren, dass es zu posession gehört, weil es sich ja keiner
merken kann und keiner auswendig weiß. Insofern ist das schön und gut,
wird aber leider von der Realität gelegentlich eingeholt. Nicht ohne
Grund empfehlen die meisten Banken, die TAN App nicht auf einem Gerät
mit der Banking App zu installieren.
Ein T. schrieb:> Nicht wirklich. Die Leitlinien sind nun einmal das, woran sich die> Kunden, Auditoren und am Ende womöglich auch die Gerichte orientieren.> Pentests lassen wir natürlich auch durchführen, aber die dokumentieren> ja nur eine Istsituation und dienen nur der Unterstützung und> Übberprüfung der Arbeit unserer Admins und Entwickler. Mein Job ist es,> nicht, irgendwen glücklich zu machen, sondern, unsere Kunden und uns zu> schützen, damit sie und wir nicht unglücklich werden.
Dann schütze deine Kunden. Implementiere 2FA richtig, aber nicht so, wie
du es hier beschrieben hast. Dann ist deine Arbeit doch völlig in
Ordnung. Was meinst du, was ich für endlos lange Berichte schreiben
müsste, wenn Ihr eure Arbeit nicht machen würdet? Unsere Arbeit geht
letztlich Hand in Hand und im Penstest fallen dann die realen
Abweichungen auf.
Aber du schreibst da was ganz wichtiges: Pentests dokumentieren die
Ist-Situation. Dein Papierverhau dokumentiert dagegen nur die
Wunschsituation. Bitte nicht falsch verstehen: Man braucht wirklich
beides, denn niemandem ist geholfen, wenn im Pentest seitenweise jedes
Jahr das selbe steht.
Schade, dass ihr Papiertigerpfleger meistens nicht sachlich
argumentiert, sondern auf Angriff geht, sobald jemand aus der Praxis
eine andere Meinung hat oder euch gar eines besseren belehrt.
Bestenfalls versteckt ihr euch hinter euren Leitlinien,
schlechtestenfalls setzt ihr euch mit keinem sachlichen Argument mehr
auseinander und sprecht anderen einfach die Kompetenz ab. Ich habe
tatsächlich schon bei zwei Menschen von dieser Sorte aus deinem Metier
dafür gesorgt, dass sie ihren Job verloren haben. Ich freue mich darauf,
falls wir uns mal im echten Leben begegnen sollten.
Ich verabschiede mich hier aus dem Thread. Das macht auf der Basis
nämlich keinen Sinn.
Carla Audimarie schrieb:> Das sind mir die liebsten, die sachlich argumentierenden die Seriösität> absprechen wollen
Wenn Du erst als Carl einen Jammerthread wegen eines
1-Cent-Rundungsfehlers bei Reichelt aufmachst [1], danach Deinen
Vornamen in Carla änderst [2], mit Stangen von Emojis um Dich wirfst und
jeden als "Boomer" oder "frauenfeindlich" bezeichnest, der Dein
Verhalten idiotisch findet, brauchst Du über Seriosität nicht mehr zu
reden.
Dein Thread "Datenleck im Forum", in dem Du Dich darüber echauffiert
hast, dass beim Klicken auf einen User dessen voller Name (sofern
angegeben) angezeigt wird, hat auch nicht dazu beigetragen, dass Du als
kompetenter Ansprechpartner in puncto IT-Security empfunden wirst.
Und auch wenn Du jetzt nicht mehr völlig ahnungslos wirkst, sowohl Dein
vorheriges Verhalten als auch Deine laufend zur Schau gestellte Arroganz
sorgen dafür, dass Deine Beiträge einfach nur nerven.
Carla Audimarie schrieb:> Ich verabschiede mich hier aus dem Thread.
Warum nicht gleich ganz aus dem Forum, wie Du es ja schon angekündigt
(und später wenig glaubwürdig relativiert) hast?
https://www.mikrocontroller.net/user/show/carla_a
1. Beitrag "Reichelt ändert PayPal-Autorisierung nachträglich"
2. Beitrag "Re: Reichelt ändert PayPal-Autorisierung nachträglich"
Carla Audimarie schrieb:> Dieses Verhalten ist der gewollte Standard auf dem System. Das ist sogar> in der .profile im Home Verzeichnis eines Debian users dokumentiert:>
1
> # set PATH so it includes user's private bin if it exists
2
> if [ -d "$HOME/bin" ] ; then
3
> PATH="$HOME/bin:$PATH"
4
> fi
5
>
6
> # set PATH so it includes user's private bin if it exists
7
> if [ -d "$HOME/.local/bin" ] ; then
8
> PATH="$HOME/.local/bin:$PATH"
9
> fi
10
>
>> Mein $PATH ist also nicht "kaputt".
Doch, ist er. Grundlagen von Solaris Admin 1, erster Tag: Erweiterungen
der systemseitig gesetzten Pfadvariable sind am Ende vorzunehmen.
Offensichtlich macht Debian das falsch -- aber das ist ja keine
Entschuldigung.
> Das sind mir die liebsten, die sachlich argumentierenden die Seriösität> absprechen wollen, und das wohlgemerkt ohne auch nur ein sinnvolles> Argument gebracht zu haben.
Ich habe das vollkommen sachlich mit Deiner Salamitaktik begründet.
> Ganz davon abgesehen solltest du mal dringend lernen, wie man Passwort> schreibt: https://www.duden.de/rechtschreibung/Passwort. Mal so ein Tipp> für Leitlinienfetischisten: Der Duden steht noch als übergeordnete> Leitlinie über dem BSI Grundschutz!
Erstens scheinst Du ja zu verstehen, was gemeint ist, so daß meine
Sprache auf der funktionalen Ebene die an sie gestellte Anforderung
erfüllt. Zweitens ist diese Schreibweise natürlich außerhalb des
Schulbetriebs immer noch rechtsgültig und korrekt, wie das
Bundesverfassungsgericht bereits mehrmals festgestellt hat. Aber gut,
sich auf kindische Formalien zu kaprizieren, ist eine beliebte Taktik,
wenn einem die Argumente ausgegangen sind.
> Ich verabschiede mich hier aus dem Thread.
Guten Tag und ein schönes Wochenende wünsche ich.
> Das macht auf der Basis nämlich keinen Sinn.
Endlich mal eine Aussage von Dir, der ich vollumfänglich zustimmen kann.
;-)
Carla Audimarie schrieb:
> $ sudo su
Carla Audimarie schrieb:
> Ich komme aus der Ecke Penetrationtests und Forensik.
Hand -> Stirn
Jetzt wundert mich nix mehr, armes Deutschland
Hmmm schrieb:> Und auch wenn Du jetzt nicht mehr völlig ahnungslos wirkst, sowohl Dein> vorheriges Verhalten als auch Deine laufend zur Schau gestellte Arroganz> sorgen dafür, dass Deine Beiträge einfach nur nerven.
Ach darum geht es also. Es geht gar nicht darum, dass ich nur Müll
schreibe, sondern um eine Elite, die einfach etwas gegen mich hat und
deshalb mit allen Mitteln versucht gegen mich zu "argumentieren" und
dabei allerlei "Argumente" an den Haaren herbei zieht, wobei wohl jeder
hier im Thread selbst wissen dürfte, dass * Unrecht hat. Dann ist die
Lösung wohl zukünftig wieder unter einem Pseudonym zu schreiben.
Was die Arroganz angeht: Die habe ich mir hier im Forum von den Besten
abgeguckt.
Hmmm schrieb:> https://www.mikrocontroller.net/user/show/carla_a>> 1. Beitrag "Reichelt ändert PayPal-Autorisierung nachträglich"> 2. Beitrag "Re: Reichelt ändert PayPal-Autorisierung nachträglich"
Danke für die Schöne Compilation. Da fehlt aber noch eine meiner Perlen:
3. Beitrag "Re: PC für virtuelle Maschinen & Programmieren" ff.
Hmmm schrieb:> Dein Thread "Datenleck im Forum", in dem Du Dich darüber echauffiert> hast, dass beim Klicken auf einen User dessen voller Name (sofern> angegeben) angezeigt wird, hat auch nicht dazu beigetragen, dass Du als> kompetenter Ansprechpartner in puncto IT-Security empfunden wirst.
Na komm, dass der Trollpost einfach nur Bullshit war, war ja wohl sofort
zu erkennen. Nur hier habt ihr einfach schlicht unrecht. Basta.
LokalHorst schrieb:> Mutti, ach Mutti,> warum klappt es nicht mit Putty?>> Nimm doch mal das HTERM her,> oder geht das auch nicht mehr?
Ab in die Pampas
af a Flasch'n Champus
Um halbe achte geht a Zug
ich hab' gesprochen hugh!
Le X. schrieb:> LokalHorst schrieb:>> Nimm doch mal das HTERM her,>> oder geht das auch nicht mehr?>> Was hat denn HTERM mit putty zu tun?
Beide können die Serielle Schnittstelle ansprechen.
Hat nur leider nix mit dem Problem des TO zu tun, wobei man es dann
zumindest für die lokale Console auf der UART nutzen könnte - sofern die
aktiv ist.
Sascha
Du solltest überlegen, ob du einen root Login wirklich willst. Besser
ist der Login als Benutzer pi und dann zu root zu werden. Ansonsten kann
das Gefährlich werden.
Markus schrieb:> Du solltest überlegen, ob du einen root Login wirklich willst.> Besser> ist der Login als Benutzer pi und dann zu root zu werden. Ansonsten kann> das Gefährlich werden.
Will da noch jemand ohne Ahnung aber viel Meinung diskutieren?
Macht es Sinn, Putty unter Linux zu verwenden oder gibt es da bessere
Möglichkeiten?
Unter Windows finden alle Leute dieses Putty ganz toll. Unter Linux ist
es oder ähnliches allerdings nicht verbreitet. Warum ist das so?
abc schrieb:> Macht es Sinn, Putty unter Linux zu verwenden oder gibt es da> bessere> Möglichkeiten?> Unter Windows finden alle Leute dieses Putty ganz toll. Unter Linux ist> es oder ähnliches allerdings nicht verbreitet. Warum ist das so?
Ich habe Putty gerade für Windows XP aus dem Netz geladen, funktioniert
auch nicht.
abc schrieb:> Macht es Sinn, Putty unter Linux zu verwenden oder gibt es da bessere> Möglichkeiten?
Andersrum gefragt: welchen Sinn hätte es, Putty für ssh zu verwenden,
wenn ›ssh‹ den Job tut? Für den typischen Shelluser, der sich seinen
Terminalemulator hübsch eingerichtet hat und seinen Kram mit ’nem
Terminalmultiplexer, den er sich ebenfalls hübsch eingerichtet hat,
koordiniert, wäre ein externes Programm mit externer Oberfläche eher
kontraproduktiv bis störend.
Der TO möchte wissen warum es bei ihm nicht funktioniert. Verständlich.
Bei mir funktioniert es auch nicht.
Was sind denn die grundsätzlichen Netzwerk Bedingungen, damit es
funktionieren könnte. Was könnten die möglichen Ursachen sein damit es
nicht funktionieren kann?
bimbam schrieb:> Was sind denn die grundsätzlichen Netzwerk Bedingungen, damit es> funktionieren könnte.
Im Fall des TE? Eine korrekte Konfiguration des sshd, sowie das Beheben
des Fehlers, der zum remount-ro des Root-FS geführt hat würden mit hoher
Wahrscheinlichkeit dazu führen, dass es funktioniert.
bimbam schrieb:> Muß auf beiden Seiten Putty installiert sein?
Falls du tatsächlich nicht trollen solltest: nein. Falls du trollen
solltest: ja, und der Desktophintergrund muss auf beiden Seiten gleich
sein.
bimbam schrieb:> abc schrieb:>> Macht es Sinn, Putty unter Linux zu verwenden oder gibt es da>> bessere>> Möglichkeiten?>> Unter Windows finden alle Leute dieses Putty ganz toll. Unter Linux ist>> es oder ähnliches allerdings nicht verbreitet. Warum ist das so?>> Ich habe Putty gerade für Windows XP aus dem Netz geladen, funktioniert> auch nicht.
Habe jetzt einen alten usb Stick gefunden mit Portable Apps. Dort befand
sich ein funktionsfähiges putty für Windows xp.
Beim Versuch mich von einem xp Rechner auf einen anderen xp Rechner
einzuloggen kam der Standard Fehler:
Putty Error Connection refused
bimbam schrieb:> bimbam schrieb:>> abc schrieb:>>> Macht es Sinn, Putty unter Linux zu verwenden oder gibt es da>>> bessere>>> Möglichkeiten?>>> Unter Windows finden alle Leute dieses Putty ganz toll. Unter Linux ist>>> es oder ähnliches allerdings nicht verbreitet. Warum ist das so?>>>> Ich habe Putty gerade für Windows XP aus dem Netz geladen, funktioniert>> auch nicht.>> Habe jetzt einen alten usb Stick gefunden mit Portable Apps. Dort befand> sich ein funktionsfähiges putty für Windows xp.> Beim Versuch mich von einem xp Rechner auf einen anderen xp Rechner> einzuloggen kam der Standard Fehler:>> Putty Error Connection refused
Quelle: https://putty.org.ru/htmldoc/chapter10.html#errors-connrefused
10.17 «Network error: Connection refused»
This error means that the network connection PuTTY tried to make to your
server was rejected by the server. Usually this happens because the
server does not provide the service which PuTTY is trying to access.
Check that you are connecting with the correct protocol (SSH, Telnet or
Rlogin), and check that the port number is correct. If that fails,
consult the administrator of your server.
bimbam schrieb:> Fehlermeldung, keine 32 Bit Anwendung.
Tja wenn man zu doof ist die für sein Betriebssystem passende (32Bit-)
Anwendung herunter zu laden, dann funktioniert es natürlich nicht.
Jede andere 64Bit-Anwendung würde sich unter einem 32Bit-OS genauso
verhalten.
bimbam schrieb:> Der TO möchte wissen warum es bei ihm nicht funktioniert. Verständlich.> Bei mir funktioniert es auch nicht.
Ja klar funktiert es bei Dir nicht. Warum habe ich oben geschrieben.
Beim TO hat das ganz andere Ursachen. Der hat schlichtweg seinen
SSH-Server auf dem Pi kaputt konfiguriert. Das passiert halt wenn man
sich an Dingen versucht, von denen man (noch) keine Ahnung hat. Wenn man
dann noch dazu kein Backup der funktionierenden Konfiguration hat, hat
man halt Pech gehabt und muß Lehrgeld zahlen. Mit Entfernen und neu
installieren des SSH Servers sollte man aber den Ausgangszustand wieder
herstellen können. Notfalls kommt man mit FTP weiter, sofern
konfiguriert, indem man eine korrekte Konfiguration einspielt.
bimbam schrieb:> Beim Versuch mich von einem xp Rechner auf einen anderen xp Rechner> einzuloggen kam der Standard Fehler:>> Putty Error Connection refused
Du bist wirklich zu .... . Laß es einfach Du weiß nicht was Du tust.
Die Ursache ist mittlerweile klar, es liegt daran das dieser SSH Server
nicht läuft. So ist es bei einem Linux Rechner bei mir.
Das wird nicht anders sein bei Win XP.
bimbam schrieb:> Die Ursache ist mittlerweile klar, es liegt daran das dieser SSH Server> nicht läuft. So ist es bei einem Linux Rechner bei mir.>> Das wird nicht anders sein bei Win XP.
Sieh da, das könnte man doch auch gleich checken bevor man hier tönt
"Putty funktioniert nicht".
Zeno schrieb:> bimbam schrieb:>> Die Ursache ist mittlerweile klar, es liegt daran das dieser SSH Server>> nicht läuft. So ist es bei einem Linux Rechner bei mir.>>>> Das wird nicht anders sein bei Win XP.> Sieh da, das könnte man doch auch gleich checken bevor man hier tönt> "Putty funktioniert nicht".
Es funktioniert jetzt aber, schaut hier nach:
Beitrag "Re: Öffentlicher SSH Server gesucht."
Thread beobachten
Seitenaufteilung abschalten