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

[nobido]

Nein. Das Passwort kann nicht falsch sein, denn bei Falscheingabe des pw gibt es eine Fehlermeldung. Auch ein Neuaufsetzen des System bringt keine Lösung.
Wird es wohl doch am WLan hängen... muss ich den Pi also wohl doch mal verkablen.

Obwohl ich ein dunkles Gefühl habe es könnte an der Configuration von Windows liegen. Habe da nämlich vor langer Zeit sämtliche Dienste, die ich (bisher) nicht brauchte, abgeschaltet.

Ich gucke mal die Tage und berichte dann weiter.

happy WE

n.

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

[nobido]

Den Pi habe ich gestern neu aufgesetzt.
WLan konfiguriert und SSH über die Pi-Einstellungen aktiviert.
Nichtmal das pw geaendert, um halt auch diese Möglichkeit auszuschliessen.
Noch keine Paketaktualisierungen etc. vorgenommen.

Die Aenderung bzgl. der Dienste hat nur unter Windows stattgefunden (bin halt der Meinung dass alles, was laeuft aber nicht gebraucht wird, ein Sicherheitsrisiko darstellt).

Was mich nach erneuter Durchsicht der Log-Datei ein wenig stuzig macht: Windows selber "sendet" auf wechselnden Ports, wohl aber selber nicht auf 22. Was aber, soweit ich das nachvollziehen und recherchieren konnte, nicht weiter schlimm ist. Ist wohl nur wichtig dass auf Port 22 auf dem Pi die Daten ankommen.

Das mit der lokalen SSH-Sitzung werd ich mal ausprobieren... wohl aber erst morgen.

[nobido]

Angenehmen Nachmittag die Gemeinde.

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

Ein Versuch dies mit ssh root@<ip-Adresse> zu tun wird mit einer Fehlermeldung quittiert: Permission denied (publickey,password).
Sowohl als user pi als auch als root (nach wechsel per sudo su).
Dass root-Passwort ist aber definitiv richtig eingegeben worden.


Was die deaktivierten Dienste angeht:  services.txt (10,84K)
Anzahl der Downloads: 196, um da mal drauf zu gucken. Grad auf dem Pi unterwegs...

Dieser Beitrag wurde von nobido bearbeitet: 22. Januar 2017 - 13:44

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

[nobido]

Die ssh-Sitzung war lokal auf dem Pi.
Wenn ich das über Netzwerk mit einem Terminalprogramm von Windows aus mache gibt es die Fehlermeldung: Connection reset by <ip-Adresse> (in diesem Fall die IP des Pi).


@RalphS: Mir scheint da irgendwie noch was unklar bzgl. der user root und pi. Hat der user pi nicht Adminrechte (root-Rechte)? Oder ist da dann noch ein kleiner Unterschied und der user root a bissl hoeher eingestuft als ein user pi (ggf. mit Adminrechte)? Weil, ich hatte ja ssh root@<ip-Adresse> lokal auf dem Pi per sudo/su ausgefuehrt...
Ach ja, die permission denied-Meldung kommt erst nach dreimaliger pw-Abfrage.

Dass das pw uebers Netzt geht laesst sich wohl nicht umgehen. Aber... ssh war doch secure shell, or not? Sollte das dann nicht verschluesselt gesendet werden? Das ist doch der Grund warum ich mir das Gedoens mit ssh antue - sonst koennt ja xrdp zum Einsatz kommen, oder ein TEamViewer-Clone etc.

@d4rkn3ss4ev3r: Nope, der DHCP-Client kann ruhig aus. Alle Adressen werden bei mir fest vergeben. Wg. dem ActiveX-Dienst muesst ich mich mal schlau machen, scheint mir aber der falsche thread. Deswegen... an dieser Stelle. Aber danke.

greetz

Dieser Beitrag wurde von nobido bearbeitet: 22. Januar 2017 - 17:19

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