[DanielDuesentrieb]

Zitat (DK2000: 15. Januar 2017 - 12:06)

Oder es liegt wirklich an der Fritz. Gab ja da mal (oder gibt immer noch) das Problem, dass die Verbindung LAN <-> WLAN gar nicht oder nicht richtig funktioniert. Mit FritzOS 6.51 habe ich das Problem zwar nicht mehr, aber dieses Version kam ja leider nicht für alle Modelle raus.

Richtig, deshalb ja mal den Pi per Kabel verbinden . Könnte man so ausschließen, dass es am WLAN liegt.

[RalphS]

Weniger Dienst als... hast Du vielleicht zuviele Ports auf Windows-Seite zugemacht?

Soviele Möglichkeiten für das von Dir beschriebene Verhalten gibt es da nämlich nicht. 

Auf dem Netzwerkstack scheint ja alles zu passen: Verbindung wird aufgebaut, es wird nach Name und PW gefragt und wenn da was falsch eingegeben wird, kommt "Credentials falsch". Das geht mit "kaputtem" Netzwerkstack nicht so weit, da kriegt man erst gar keine Verbindung hin.


Viel wahrscheinlicher ist, daß der Raspberry die Credentials zu authentifizieren versucht und dabei irgendwo drüberstolpert.

Beispiel: Du läßt Credentials via LDAP, RADIUS oder sonstwie 'remote' authentifizieren und diese Gegenstelle antwortet aber nicht. Das wäre eine zusätzliche Verbindung, die dann aber fehlschlägt und entsprechend gibt es dann das beschriebene Timeout an der beschriebenen Stelle.

Evtl haut auch die PAM-Konfiguration nicht hin, und/oder die SSH-Konfiguration selber (via sshd_config).

Was Du genau wie konfiguriert hast bzw geändert hast am Raspberry weißt Du besser als wir anderen. Blöderweise (fürs Debuggen) greift da sehr viel ineinander, und wenn eins nicht paßt, geht gar nix.


-- Vielleicht übersehe ichs grade; falls ja, dann sorry.
- Falls nicht: Schau mal nach, ob ein lokales Logon *VIA SSH* funktioniert.
In Worten: 
>> mit Tastatur an den Pi setzen;
>> "normal" anmelden dort;
>> einen SSH-Client auf dem Pi aufmachen;
>> mit localhost auf Port 22 verbinden.

Und schauen, ob eine Sitzung aufgebaut werden kann (= Connect und Logon sind beide erfolgreich und Du kannst via SSH-Verbindung zur lokalen Maschine was tun).

Falls nicht, hat das mit Windows o.ä. nix zu tun, sondern dann ist irgendwas vom SSH-Server abwärts fehlkonfiguiert auf dem Pi und (wenn das Ding noch so jung ist wie Du schreibst) evtl ein Re-Install die einfachste Option.

[RalphS]

Zitat (nobido: 22. Januar 2017 - 13:25)

Also als user pi kann ich per ssh pi@<ip-Adresse> eine Verbindung samt dazugehoerigen Passwort aufbauen.

Lokal vom Pi aus, oder allgemein? Falls letzteres ist ja von der zugrundeliegenden Konfiguration erstmal alles okay.

Zitat (nobido: 22. Januar 2017 - 13:25)

Ein Versuch dies mit ssh root@<ip-Adresse> zu tun wird mit einer Fehlermeldung quittiert: Permission denied (publickey,password).

Das ist normal und so gewollt. Als root kommst Du auf den Pi, indem Du:
- Dich als "pi" oder sonst ein Benutzer per SSH einwählst
- Mit sudo, oder su, root-Befehle ausführst. Für sudo muß dazu der jeweilige Benutzer irgendwie in sudoers(5) eingetragen sein.

Alles andere ist ein dickes Sicherheitsloch, weil das root-PW über Netz geht und DAS darf möglichst NICHT passieren.

[RalphS]

Windows ist nicht Linux.

Allerdings gibt es auch da Benutzer und Gruppen. Nun ist mein Pi grad offline und ich kann daher nicht nachschauen, aber ich geh schon mal davon aus, daß der Benutzer "Pi" in die *Gruppe* root eingetragen ist (muß allerdings nicht so sein).

Sinngemäß ist "pi" ein stinknormaler Benutzer. root auf der anderen Seite ist ein Benutzer, für den bis auf ganz wenige Ausnahmen keinerlei Sicherheitsvorkehrungen greifen und der daher effektiv "alles" darf. Das Ding heißt Superuser, weil er über den Benutzern steht und mit den Benutzern machen kann was er will. Das kann nur root.

Wenn man jetzt aber als normaler Benutzer wie 'pi' Aufgaben tun will die root-Rechte erfordern, dann kann man das diesem Benutzer einräumen (ebenfalls als root). Sowas nennt sich gemeinhin Delegierung.

Dazu bearbeitet man mit visudo die sudoers(5) Datei. Da kommt rein, unter welchen Bedingungen wer was wie darf.

Die STANDARD-Sudoers ist eigentlich albern. Ubuntu macht zB diesen Müll (oder hats gemacht, vielleicht sind sie inzwischen besser): JEDER darf sudo ausführen und es ist effektiv nichts erforderlich dazu. Damit steht das offen wie ein Scheunentor.

Eine richtig konfigurierte sudoers-Datei sorgt dafür, daß:

- Ich mich als Benutzer ("pi") anmelde
- "sudo perl" eingebe (als Beispiel)
- Ich mein eigenes(!) PW eingebe (NICHT das root pw, das ist komplett daneben, auch wenn es im Standard oft so ist)
- Anhand der Informationen in der sudoers-Datei bewertet wird, ob Benutzer "pi" 'perl' ausführen darf oder nicht. 

Hat man also zB einen anderen Benutzer kuh und der gibt ebenfalls "sudo perl" ein, dann heißt das noch lange nicht daß der das darf, nur weil "pi" das durfte.

Weitergehend kann man wenn man zu bequem ist (oder wenn es nicht anders geht, cf Automatisierung) Benutzern auch die PW-Eingabe ganz ersparen. Muß man natürlich vorsichtig mit sein.


- Das Root-Paßwort selber ist als höchste Geheimhaltungsstufe zu bewerten. Wenn das jemand hat, kann man sein Linux - oder sonstwelchen Unixoiden -- eigentlich genausogut wegwerfen.