=== TheSphinX_ is now known as TheSphinX^
=== eTeddy1 is now known as eTeddy
[08:40] <dreamon> Moin. bin gerade per Remote mit einer Kiste verbunden und dort kann ich kein @ eingeben. ist blöd ssh xxx@yyy.yyy.yyy.yyy ohne @. Gibts einen Trick das irgendwie rüber zu kriegen?
[08:43] <stevieh> copy und paste z.B.
[08:45] <spY|da> guten morgen!
=== sem2peie- is now known as sem2peie
[09:02] <LupusE> zeichensatz korrigieren?
=== sem2peie- is now known as sem2peie
[09:56] <NTQ> dreamon: Mit ssh -l username
[09:58] <dreamon> War ne Teamviewer session. ssh -l Danke!
[14:30] <matze202> Hi, wie bekomme ich das "root"-Passwort vom MySQL-Server was bei der Installation (mit der Muon-Packetverwaltung) nicht abgefragt wurde nachträglich eingestellt? Nach ergoogelten komplettem runterwerfen und neuinstallieren kam auch keine Abfrage des einzurichtenden "root"-Passwortes und wenn ich über "$ sudo dpkg-reconfigure mysql-server-5.7"  versuche das Passwort zu ändern, kommt "Keine Berechtigung" bei d
[14:30] <matze202> en einzelnen Ausgaben und ohne "sudo"  verlangt er es als Root auszuführen
[14:39] <Frickelpit> matze202: der Systembenutzer root sollte sich ohne Passwort anmelden können. Einfach mal mit mysql ausprobieren, wenn du auf dem System root bist.
[14:39] <Frickelpit> Ansonsten: https://wiki.ubuntuusers.de/MySQL/#root-Passwort-vergessen
[14:39] <le_bot> Title: MySQL › Wiki › ubuntuusers.de (at wiki.ubuntuusers.de)
[14:45] <matze202> Frickelpit, ich danke dir sehr (letzte Nacht hatte ich 5 Stunden gekämpft und leider ohne Erfolg, dank deiner Hilfe nun binnen Minuten behoben)
[14:46] <Frickelpit> matze202: Dann kannste ja jetzt schlaf nachholen. ;)
[14:49] <matze202> Frickelpit, Danke, aber ausgeschlafen hatte ich schon, denn ich muss die nächsten Nächte sowieso zur Nachtschicht
[15:56] <NTQ> Toll, gerade ein do-release-upgrade auf meiner externen VM gemacht, dann musste neugestartet werden, jetzt komme ich nicht mehr drauf. Schöne Scheiße.
[15:57] <LupusE> heute lernen wir was ein snapshot ist.
[15:57] <LupusE> und warum meldungen in der console waerend eines upgrades gelesen werden sollten.
[15:58] <NTQ> Es laufen alle ports, die laufen soll, aber nichts funktioniert. ssh schließt die Verbindung einfach nach einem "debug1: SSH2_MSG_KEXINIT sent"
[15:58] <ppq> vielleicht platte voll?
[15:58] <NTQ> Ich kann jetzt über einen Recovery-Kernel rein. Mal schauen, was man so tun kann.
[15:59] <NTQ> Die Platte sollte noch sehr viel Luft nach oben haben. Daran kann es nicht liegen.
[16:00] <LupusE> platte voll kann auch 'inodes voll' bedeuten. gerade bei einem upgrade werden viele dateien geschrieben, keine grossen dateien.
[16:01] <NTQ> LupusE: Auch da sollte noch Luft sein. Das Upgrdae selbst ist ja durchgelaufen. Am Ende kam die Meldung, dass jetzt neugestartet werden müsse.
[16:01] <NTQ> Danach sollten ja nicht noch mehr Inodes benutzt werden. Dann ist es ja schon druch
[16:05] <NTQ> Komisch, nicht mal in auth.log war was von meinen letzten Loginversuchen zu sehen
[16:14] <NTQ> Das ist alles, was ich über ssh -vvv zu sehen bekomme. Kann mir dazu jemand etwas sagen? https://paste.ubuntu.com/p/vqGxSnsBh9/
[16:14] <le_bot> Title: Ubuntu Pastebin (at paste.ubuntu.com)
[16:15] <NTQ> Kann es sein, dass beim Upgrade von 16.04 auf 18.04 irgendeine Firewall automatisch aktiviert wird?
[16:17] <NTQ> Würde mir ja schon reichen, wenn ich wieder per ssh drauf kommen könnte. Ich kann ein Rettungssystem starten, das mir das normale / denn in /repair mountet. Dann krieg ich den Rest in der Regel von selbst hin.
[16:18] <NTQ> Ich schaue mal, ob ufw oder sowas irgendeinen Mist baut, falls ich das finde
[16:24] <tomreyn> wenn der ssh-verbindungsaufbau nach "debug1: SSH2_MSG_KEXINIT sent" (auf dem ssh-client) abgebrochen wird dann suggeriert das erst mal dass der key exchange aufgrund inkompatibler algorithmen zwischen beiden partnern fehlgeschalgen ist.
[16:26] <tomreyn> ein per do-release-upgrade über ssh gestarteter release-upgrade startet einen zweiten ssh-server auf einem anderen port damit man bei bedarf noch drauf kommt wenn die verbindung abbricht und der 'normale' ssh-server bereits rekonfiguriert wird / wurde.
[16:26] <tomreyn> der läuft da aber natürlich nur bis das upgrade beendet wurde / das system neugestartet wurde.
[16:27] <tomreyn> soweit ich mich erinnere bietet strato ne serielle konsole, die man, wenn sie denn auf dem OS konfiguriert ist, für solche zwecke gut verwenden kann. hatte allerdings schon lange nix mehr bei strato.
[16:29] <NTQ> tomreyn: Die serielle Konsole geht nur bei dedicated servern. Die VM hat nur einen Recovery-Boot. Ich bin da gerade drin und hab mich mit chroot zum eigentlichen Server verbunden.
[16:30] <NTQ> Wundern tut mich unter anderem, dass nmap sagt, dass Port 22 offen wäre. Ebenso 80 und 443 und meine Mailserverports. Apache läuftauch so halb, macht immerhin redirects von 80 auf 443.
[16:31] <NTQ> Inkompatible Versionen bei ssh würden mich arg wundern, immerhin hab ich hier selbst 19.04 und der Server sollte jetzt 18.04 sein.
[16:31] <tomreyn> wäre port 22 nicht offen, hätte dein ssh-client auch wesentlich weniger zu tun gehabt (und ausgegben).
[16:31] <NTQ> UNd mit sonstigen Ubuntu-Servern hatte ich auch nie Probleme. Wir haben hier welche von 14.04 bis 18.04 und alle gehen.
[16:32] <NTQ> tomreyn: Ich hab auch gehofft, dass ich auf dem Server in /etc/auth.log etwas finde, aber da steht nichts mehr seitdem ich das Upgrade gestartet habe.
[16:32] <tomreyn> womöglich hast du in der sshd_config auf dem server do key echange algorithmen festgezurrt auf welche die nicht mehr unterstützt werden.
[16:34] <tomreyn> s/ do / die /
[16:34] <NTQ> Die sshd_config ist eigentlich unangetastet.
[16:35] <tomreyn> eigentlich, oder ganz bestimmt, oder ganz bestimmt nicht, oder vielleicht doch ein bisschen?
[16:36] <NTQ> Ich hab nur die Zeile "PubkeyAuthentication yes" aktiviert
[16:37] <tomreyn> das klingt erst mal unproblematisch
[16:38] <NTQ> Gibt es nicht mehr Logs als auth.log dazu? Kann doch nicht sein, dass da gar nichts protokolliert wird. Sogar ufw ist nicht mal installiert. das kann es also auch nicht sein.
[16:39] <tomreyn> kannst ja aus dem chroot mal den ssh-server aus der ubuntu-installation auf nem anderen port lauschend mit debuglogging starten und dann nochmal mit deinem client drauf connecten
[16:39] <tomreyn> mit firewalling hat's nix zu tun
[16:40] <tomreyn> schau auch mal ob deine ssh-client-konfiguration vielleicht zu restriktiv ist was den key exchange angeht
[16:40] <NTQ> tomreyn: Debuglogging mache ich auch in sshd_config?
[16:40] <tomreyn> ich hab noch nie mit 19.04 ne ssh.verbindung zu 18.04 hergestellt, ggf. ist das normal dass das erst mal nicht klappt.
[16:41] <tomreyn> NTQ: ja, oder (besser, da nicht permanent) auf der kommandozeile über -o
[16:41] <NTQ> achso, ich wollte jetzt einfach den service starten in chroot
[16:42] <tomreyn> der würde dann auf wlechem port lauschen?
[16:42] <tomreyn> und auf welchem port bist du grade ins rettungssystem eingeloggt?
[16:43] <tomreyn> ist immer hilfreich wenn über'm hals noch ein weiteres körperteil kommt.
[16:43] <NTQ> Ich bin über 22 drin. Ich hab aber in sshd_config schon auf 1022 umgestellt
[16:43] <tomreyn> ah gut
[16:46] <tomreyn> ich seh grade in deinem ssh-client-log von vorher dass der server nur ecdsa anbietet. das ist ggf. ein bisschen wenig, kein rsa, kein ed25519?
[16:47] <tomreyn> ggf. fehlen dem server die entsprechenden host-keys in /etc/ssh/
[16:48] <NTQ> tomreyn: Das hier ist vorhanden: https://paste.ubuntu.com/p/WMwXhTycyR/
[16:48] <le_bot> Title: Ubuntu Pastebin (at paste.ubuntu.com)
[16:49] <tomreyn> es steht übrigens seitens kryptoanalysten die unwidersprochene vermutung im raum dass ecdsa mit den von der NIST spezifizierten parametern (die dein ssh-server da verwendet) so von der NSA gewünscht wurden um die krypto besser brechen zu können.
[16:50] <tomreyn> ah hast ja doch mehr da. dann müsstest du vom client mit ssh-keyscan mal gucken ob die auch wirklich angeboten werden.
[16:52] <NTQ> Scheinbar hab ich das da: https://serverfault.com/questions/926535/ubuntu-upgrade-to-18-04-setrlimit-getrlimit-ssh-sandbox-child-causing-sshd-to
[16:52] <le_bot> Title: ssh - Ubuntu upgrade to 18.04 setrlimit, getrlimit & ssh_sandbox_child causing sshd to not work - Server Fault (at serverfault.com)
[16:52] <NTQ> Also zumindest sagt mir das Debug-Log von sshd auch diese ssh_sandbox_child-Fehlermeldung
[16:57] <tomreyn> wie's das auch schon in der ersten anmerkung steht: erst mal das upgrade zuende machen, dann nochmal probieren.
[16:58] <NTQ> Ja, das ist schon geschehen. apt -f install ist glücklich.
[16:58] <NTQ> Hier mal mehr Debug-Infos: https://paste.ubuntu.com/p/vgkH6sHZPg/
[16:58] <le_bot> Title: Ubuntu Pastebin (at paste.ubuntu.com)
[16:58] <NTQ> Bin jetzt auf das hier gestoßen. Ob es damit zu tun hat? https://smartos.org/bugview/OS-4407
[16:58] <le_bot> Title: OS-4407: OpenSSH 7.5+ broken in lx brand (at smartos.org)
[17:02] <tomreyn> was hat denn das livesystem für nen kernel?
[17:02] <tomreyn> äh recovery-system
[17:02] <NTQ> ssh-keyscan -p 1022 my.server listet übrigens gar nichts auf. Da kommt nur Connection reset by peer
[17:03] <NTQ> tomreyn: Recovery-Kernel ist 3.16.0
[17:03] <tomreyn> oha
[17:03] <NTQ> Ohnee, liegt es daran?
[17:03] <NTQ> Muss ich jetzt mit Strato meckern?
[17:03] <tomreyn> das seccomp-zeugs vermutlich schon, ja
[17:04] <tomreyn> guck dir am besten mal das systemd-journal oder syslog vom letzten boot an, als das system normal startetete aber der ssh.server nicht wie erwartet funktionierte
[17:05] <tomreyn> da wird sich womöglich im ssh-server-startup auch was dazu finden.
[17:06] <NTQ> tomreyn: Also in /var/log/syslog ist der letzte Eintrag noch von vor dem Upgrade.
[17:06] <tomreyn> dann im systemd-journal
[17:06] <NTQ> Ich such's grad
[17:06] <tomreyn> kannst auch mal mit "UsePrivilegeSeparation yes" testen wenn's auf diesem kernel nicht anders geht, deine entscheidung.
[17:07] <NTQ> Hab ich schon, da stand dann im log, dass es Deprecated sei
[17:07] <tomreyn> vielleicht gibts ja auch noch ein zeitgemäßes recovery-system
[17:07] <NTQ> Das journal-Verzeichnis in /var/log ist komplett leer
[17:08] <tomreyn> dann kam das system wohl gar nicht wirklich zum booten
[17:08] <tomreyn> also zum booten schon aber nicht komplett hoch
[17:09] <tomreyn> mach am besten ne neuinstallation, ist am ende vermutlich schneller
[17:10] <NTQ> Nee, hier gibt's nur Snapshots, die man wieder einspielen kann
[17:11] <NTQ> Ist doch scheiße. Wenn ich den Server neu aufsetze, hätte ich ja alle Daten verloren. Das geht wohl kaum
[17:11] <tomreyn> backups?
[17:11] <NTQ> Da gibt's Snaphots, wie schon gesagt
[17:12] <NTQ> Ich ziehe ja nicht jeden Tag Backups über meine schmale Leitung nach Hause
[17:12] <tomreyn> hab ich schon verstanden, nur sind halt snapshots keine backups
[17:12] <NTQ> Für den kleinen Anwender reicht das
[17:12] <tomreyn> na ja aber wenn du direkt vorher ein snapshot gemacht hast, und das wirst du ja siche rgemacht haben, dann ist das ja auch ausreichend jetzt, ne?
[17:13] <NTQ> Da wurde sowieso einer kurz vorher gemacht
[17:13] <NTQ> Außerdem komme ich ja über das Rettungssystem auch drauf, könnte also alles sichern
[17:13] <NTQ> Ich will jetzt aber lieber das SSH wieder ans laufen kriegen. Neuinstallation dauert wieder Tage
[17:13] <NTQ> Bis ich alles so eingerichtet habe, wie es soll
[17:13] <tomreyn> viel erfolg!
[17:14] <NTQ> Nextcloud, Postfix, Dovecot, die ganzen Let's Encrypt Zertifikate, usw. usf
[17:15] <NTQ> Das ist ja immer Fummelei und kein 1:1 rüberkopieren
[17:23] <NTQ> Welchen Einfluss hat denn der Kernel des Recovery-Systems auf die chroot-Umgebung?
[17:24] <tomreyn> falls du dich entscheidest nen snapshot wiederherzustellen und das upgrade nochmal auszuführen, nutz am besten ppa-purge um alle drittrepos und die pakete von dort zu entfernen (bzw auch in ubuntu verfügbare pakete auf die ubuntu-versioenen downzugraden) und lass danach nochmal https://github.com/tomreyn/scripts#foreign_packages drüber laufen und räum entsprechend weiter auf. danach läuft dann ein release-upgrade in der regel sauber durch.
[17:24] <le_bot> Title: GitHub - tomreyn/scripts: Some scripts I use or used in the past (at github.com)
[17:25] <NTQ> tomreyn: Als Drittpakete hab ich certbot drin gehabt. Und die Sourcen kamen ursprünglich von dem Mirror von Strato. Die hab ich aber auf die originalen Ubuntu-Server umgestellt
[17:26] <NTQ> Und das Upgrade hat ja wie gesagt keine Fehler gemeldet. Es lief alles sauber durch. Naja
[17:29] <NTQ> 40 andere Server laufen ohne Probleme durch und bei meinem eigenen passiert wieder nur Scheiße. 
[17:34] <NTQ> Wenn ich openssh-server komplett lösche und neuinstalliere, sollte doch eigentlich wieder alles gerade gerückt werden können. Oder wo sollen dann noch Probleme liegen?
[17:45] <tomreyn> wie du ja anhand deiner (nicht vorhandenen) logs des letzten boots bereits festgestellt hast ist das system scheinbar gar nicht richtig hoch gekommen. das kann nicht nur am openssh-server gelegen haben.
[17:48] <tomreyn> es sind also durchaus noch andere probleme da. der release-upgrader arbeitet mit dem was er vorfindet, deshalb die empfehlung vor dem upgrade erst mal ordentlich aufzuräumen. es ist keineswegs einfach festzustellen welche drittpakete oder drittpaket-versionen man noch auf einem system installiert hat, die das upgrade behindern können.
[17:49] <tomreyn> ...oder den nächsten systemstart, se4lbst wenn das upgrade erfolgreich durchgelaufen zu sein scheint.
[17:58] <NTQ> Ich spiele am besten gleich einfach den Snapshot wieder ein und dann schau ich mal
[18:10] <NTQ> Wird wohl Zeit, dass ich mir mal irgendwas zu lesen suche um Linux von der Basis auf zu verstehen. Dann könnte ich vielleicht besser herausfinden wie man sowas löst
[18:12] <nicole> O.o "Linux von der Basis auf zu verstehen" 
[18:12] <NTQ> Naja, zumindest die ganzen runlevel und wann wo was wie gestartet wird.
[18:15] <tomreyn> runlevel gibts nicht mehr ;-)
[18:16] <NTQ> :-D Da fängt's schon an
[18:17] <NTQ> Ich als kleiner Admin, der ein bisschen Apache, Postfix, Dovecot und Anwendungsentwicklung mit Python betreibt, komme halt nicht besonders oft mit tiefergründigen Dingen in Kontakt.
[18:30] <NTQ> Für mysql sollte es reichen nochmal /var/lib/mysql zu packen und zu sichern
[18:30] <NTQ> Ich hab vor dem Upgrade alle services gestoppt außer ssh. Das kann es hoffentlich nicht gewesen sein?
[18:32] <NTQ> Und ich hab natürlich doch wieder Mist gefunden mit dem Skript von tomreyn. Und zwar war mono über ein Dritt-PPA installiert.
[18:32] <NTQ> Ich mache jetzt noch ein Backup von allem wichtigen und dann setze ich den Server auf den Snapshot zurück.