putty klappt nicht

Mans A. schrieb:
> Kann mir bitte jemand helfen

Toll. Ein schwarzer Bildschirm ist äußerst hilfreich...

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.

Doch, bei mir klappts
Machs einfach so wie ich. :-)

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.).

Ist dann Wohl putty

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.

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.

Ein T. schrieb:
> hast Du einen Tippfehler in Deiner /etc/ssh/sshd_config

Ohne Backup wenig Mitleid. Sonst könnte er vergleichen.

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):

1

ansible@icinga:~$ ls -la /etc/

2

total 928

3

drwxr-xr-x 103 root   root       12288 May 29 19:42 .

4

drwxr-xr-x  18 root   root        4096 Jun 12 14:17 ..

5

drwxr-x---   9 nagios nagios      4096 Apr 13 10:38 icinga2

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:

1

ansible@icinga:~$ which ls

2

/usr/bin/ls

Dann betrachten wir die Berechtigungen:

1

ansible@icinga:~$ ls -la /usr/bin/ls

2

-rwxr-xr-x 1 root root 147176 Sep 24  2020 /usr/bin/ls

Wir stellen fest: ls gehört root und ist für andere Benutzer nicht 
beschreibbar. Versuchen wir es aber trotzdem mal:

1

ansible@icinga:~$ touch /usr/bin/ls

2

touch: cannot touch '/usr/bin/ls': Permission denied

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.

Carla Audimarie schrieb:
> $ sudo su

Wofür soll diese Kombination eigentlich gut sein?

Es gibt sudo -i und sudo -s.

Hmmm schrieb:
> sudo -i und sudo -s

Wofür soll diese Kombination eigentlich gut sein?

Es gibt sudo su

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.

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.

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.

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.

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äß

1

ansible@icinga:~$ sudo

2

usage: sudo -h | -K | -k | -V

3

usage: sudo -v [-AknS] [-g group] [-h host] [-p prompt] [-u user]

4

usage: sudo -l [-AknS] [-g group] [-h host] [-p prompt] [-U user] [-u user] [command]

5

usage: sudo [-AbEHknPS] [-r role] [-t type] [-C num] [-D directory] [-g group] [-h host] [-p prompt] [-R directory] [-T timeout] [-u user] [VAR=value] [-i|-s] [<command>]

6

usage: sudo -e [-AknS] [-r role] [-t type] [-C num] [-D directory] [-g group] [-h host] [-p prompt] [-R directory] [-T timeout] [-u user] file ...

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.

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:
> $ sudo su

Carla Audimarie schrieb:
> Ich komme aus der Ecke Penetrationtests und Forensik.

Hand -> Stirn
Jetzt wundert mich nix mehr, armes Deutschland

Der Kaiser ist nackt, oder was sieht man auf dem angehängten Bild?

Mutti, ach Mutti,
warum klappt es nicht mit Putty?

Nimm doch mal das HTERM her,
oder geht das auch nicht mehr?

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.

Fehlermeldung, keine 32 Bit Anwendung.

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?

Muß auf beiden Seiten Putty installiert sein?

Trolle haben morgen Ausgang.

Trolle haben erst morgen Ausgang.

Heiliger Bimbam was geht denn hier zum Kuckuck ab?

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.

Der Ping funktioniert aber in beide Richtungen.Grrr

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."