Das längste Thema

  • Ich hatte heute einen netten Zufall auf der Arbeit... ^^


    Mein Azubi bastelt gerade eine Art Wrapper für nvm for Windows, mit welchen wir die Updates einer Node.JS Engine unter Windows automatisieren wollen. In PowerShell. Jetzt hatten wir das Problem, dass der Download der index.json vom Node Mirror per Invoke-Webrequest nicht klappte, wenn wir das Script per Task Scheduler als NT-AUTHORITY\SYSTEM ausführen ließen.


    Nach einiger Zeit hatte mein Azubi dann eine Erklärung sowie eine Lösung für das Problem gefunden. Zeitgleich mit meiner Frage, wo er die gefunden hat, streckte ich meinen Kopf am Monitor vorbei und schaute auf seinen Monitor. Mir kam die Seite sofort bekannt vor. Wirklich sehr bekannt. Es war ein Blog und der Blick auf den Namen des Autors sowie die Domain sorgten dann für Aufklärung. Und für ein "Lol den Typen dem der Blog gehört kenn ich!" meinerseits.


    Stellte sich raus - es war perryflynn, der uns den Tag gerettet hat. Danke! :3

    (Problemlösung: https://serverless.industries/…equest-systemservice.html)

  • Hat jemand eine Ahnung wo man bei folgendem Problem zu suchen beginnt od. wo das Problem ist ...

    habe eine Linux-VM (Fedora 35), habe /root/.ssh/authorized_keys angelegt und dort 2 Keys abgelegt,

    also quasi der selbe Inhalt, welchen ich von einer anderen VM kopierte;


    von meiner Jump-VM (der 1te Key) klappt es,

    aber mit WInSCP (der 2te Key) nicht, wo ist hier der Pferdefuß begraben?

    hier erhalte ich den Fehler, dass der Server den Key verweigert ...:(


    bei der anderen VM kappt es sowohl von der Jump-VM als auch mit WinSCP;

  • Fedora ist hier immer sehr schnell, was das Ablehnen alter Kryptos oder Keylängen betrifft. Mal einen neuen (modernen) Key erstellt? Ist das evtl. irgendein alter dsa key oder hat zu wenige "Bits"?

  • Fedora ist hier immer sehr schnell, was das Ablehnen alter Kryptos oder Keylängen betrifft.

    Ja ok, wär ja irgendwie nachvollziehbar ... ABER ...


    Mal einen neuen (modernen) Key erstellt?

    in der Fedora-VM mit

    ssh-keygen ein Keypaar (private/public) erzeugt

    sei das jetzt ein neuer (moderner) Key - der hat 3072 Bits

    id_rsa.pub hab ich zu authorized_keys angehängt


    mit PUTTYGEN.EXE habe ich den private Key id_rsa konvertiert;

    mit PuTTY/WinSCP geht dieser ebenfalls nicht, UND ...

    jetzt kommt der Überhammer schlecht hin:

    mit Windows eigenem SSH klappt dieser Key: ssh -i id_rsa


    Ist das evtl. irgendein alter dsa key oder hat zu wenige "Bits"?

    2048 bits RSA sollte doch passen:/


    kann ich irgendwo in der sshd_config in der Fedora-VM was einstellen?

    (habe an den Einstellungen nichts geändert)


    ein Blick in den Logfile /var/log/secure

    zeigt mir das da: Nov 20 14:53:20 lxfedora sshd[2376]: userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedAlgorithms [preauth]

  • Ich meine mich zu erinnern, dass Fedora ssh-rsa Keys komplett deaktivieren wollte (bzw. OpenSSH wollte das generell wohl so einführen). War mir gerade nicht ganz sicher, ob die das schon in Version 35 gemacht haben, hat aber wohl ganz den Anschein. In Fedora (aber auch in RHEL, CentOS & Co.) lässt sich das ja auch über das `update-crypto-policies` Tool regeln. Das überschreibt auch die lokale sshd_config (egal, was man dort einträgt). Finde ich persönlich ein bisschen unschön und ich ändere das meist (über eine "/etc/systemd/system/sshd.service.d/override.conf"). Aber damit könnte man es zumindest wieder ändern.


    Edit: Kleine Korrektur. Die Crypto Policies überschreiben die sshd_config nur bei RHEL & Co. Nicht bei Fedora. Das hatte ich wohl falsch im Hinterkopf.

    Edit 2: Die Lösung steht im Grunde schon in der letzten genannten Fehlermeldung: PubkeyAcceptedAlgorithms=+ssh-rsa ;)

  • Ich meine mich zu erinnern, dass Fedora ssh-rsa Keys komplett deaktivieren wollte (bzw. OpenSSH wollte das generell wohl so einführen).

    ja und jetzt fängt der Fisch so richtig an zu stinken;


    der Log vom WinSCP hat das mal aufgezeichnet ...


    wenn ich PubkeyAcceptedAlgorithms auf ssh-rsa setze, dann klappt PuTTY/WinSCP wunderbar aber SSH von der Jump-VM geht damit nicht;

    wo finde ich, welche Werte diese Einstellung als Default hat?

    offensichtlich, muss ich des in der Fedora-VM ändern, weil bei WinSCP habe ich kaum eine Möglichkeit

    pasted-from-clipboard.png

  • die unorthodoxe Variante den File 50-redhat.conf aus dem Verz. /etc/ssh/sshd_config.d verbannen

    ich hab einen File 02-permitlegacyalgos.conf mit PubkeyAcceptedAlgorithms +ssh-rsa

    das sollte auch ein Update überleben :)


    yum remove crypto-policies-scripts wäre die strange Variante gewesen, aber die Sinnhaftigkeit, dass man

    da gleich ¾ vom System wegwirft, muss mal einer erklären :D

  • Hey,


    hat wer von euch ne coole Idee für ein Bday Geschenk für nen Kollegen? ITler und zockt gerne. Ne Nintendo Switch hat er, ne Xbox Series X hatten wir im letztes Jahr zum bday geschenkt und zu Weihnachten ne Oculus Rift.


    Wir dachten an ne PS 5, aber die sind aktuell ja auch eher Mangelware. Sonst evtl. ne kleine Systemkamera oder ne GoPro... aber aktuell kann man ja eh nicht verreisen und die Kamera ausnutzen. Tendiere gerade zu ACN Kopfhörern, Over Ear oder In Ear.


    Hat wer noch ne Idee für nen cooles technisches Gadget, was ich nicht auf dem Schirm habe?

  • Ich hab meine small VM - ein Fedora 35; hab so ziemlich alles mit yum remove ... rausgehauen,

    was ich nicht brauch (aus so rund 1500 Paketen wurden schlappe 950 Pakete) - verwendet LXDE;

    die VM hat 2,5 GByte RAM und 2 CPU-Cores; und eine virtuelle Platte mit 16 GByte

    davon sind 1 GByte f. /boot und 2,5 GByte f. swap und der Rest f. / und da sind 9 GByte freier Platz;

  • ja bei den Temperaturen wo des gelagert werden muss, auf jeden Fall;

    Bitcoin-(od sonstwas)-mining wär evtl. effektiver in Relation zur Stromrechnung ^^

    Es ist nicht zwingend notwendig, einen Whisky (insbesondere abgefüllt ab Werk) bei konstant 20 Grad Celsius und gleichbleibender Luftfeuchtigkeit zu lagern, wenn es sich nicht um "höchstpreisige" Sammlerflaschen/-fässer handelt. Kein Sonnenlicht, keine wiederholten/anhaltenden Hitze- und Kältespitzen, keine dauerhafte Feuchtigkeit sind völlig ausreichende Lagerbedingungen für mehrere(!) Jahre.