Beiträge von mainziman

  • Das längste Thema

    bei mir sind die Werte so ...

    Code: sysctl -a
    net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.accept_redirects = 1
net.ipv4.tcp_syncookies = 1

    und des dürften die default Werte sein, und genau die verwende ich;

    gibt keinen Grund hier etwas herumzufummeln :D

  • Das längste Thema

    Zitat von Ente-Dank

    Weil wir es vorhin von hatten: ist ein 7702P der kann kein dual socket

    ja der hat 64 Cores und 128 Threads, und ich würde meinen das ist das Ende der Fahnenstange,

    man muss das ja auch 'adressieren',

    sprich: hier brauchst bereits 128 bits um die einzelnen Threads zu adressieren;

    da muss vorher ein 'AMD128' erschaffen werden, soferne das AMD noch hinbekommt,

    und nicht hier dann Intel mit einem 'EM128T' die Nase vorne hätte;

    inwieweit das Konzept mit den Prozessor-Gruppen¹ dann noch was bringt sei mal dahingestellt

    https://docs.microsoft.com/en-us/windows/…essaffinitymask

    https://docs.microsoft.com/en-us/windows/…rocessor-groups

    ¹ ob das mit den Prozessor-Gruppen hier eine reine proprietäre Geschichte von Microsoft ist,

    kann ich nicht sagen, würde mich aber doch sehr wundern, wenn hier bei Linux nicht ähnliches gemacht würde;

  • Das längste Thema

    Zitat von MeisterYoda

    Ich weiß nicht ob Dual Sockel Server eingesetzt werden,

    bei Root-Servern schlägt die CPU des Hosts durch - cat /proc/cpuinfo

    und damit kann man herausfinden, ob die CPU denn überhaupt f. den Mehrsockelbetrieb spezifiziert ist

    Zitat von Virinum

    Ja. Dann könnte ich mir theoretisch die Telefonnummer sparen. Richtig?

    in gewisser Weise;

    wobei was ich bei manchen Sites als Impressum vorfinde ist kompletter Quark;

    Gezwitscher (Twitter) und Ferkelbuch (Facebook) als einzige Kontaktmöglichkeit neben einer Adresse

    und einer Telephonnummer bei der man nicht wieß ob es eine Mehrwertnummer ist, empfinde ich persönlich als Frechheit =O

    ein Kontaktformular als Ersatz f. eine E-mailadresse - na ja ...

  • Das längste Thema

    Zitat von perryflynn

    Es wird Zeit das endlich ein großer Dienst auf IPv6-only umstellt, sodass der Rest des Internets gezwungen ist umzustellen.

    des glaub ich weniger ...

    jetzt gegen Ende des Jahres 2021, wo es noch ISPs gibt - meiner ist einer davon - die genug IPv4-Adressen haben,

    und damit nicht gezwungen sind auf IPv6 umzustellen machen Dir derartiges zu nichte; die gehen einfach her und stellen Dir

    ein Fake hin; des vollkommen transparent des abfängt und zwischen IPv4/IPv6 hin- und herroutet und Du merkst es nichtmal;

    ich habe mich mit einem Techniker meines ISPs unterhalten, und dessen Aussage ist nicht von der Hand zu weisen:

    "mit IPv6 kann man zuviel falsch machen und damit eine Hilfestellung vom Support benötigen"

    zurückgeblickt wurden einfach zuviele Fehler gemacht ...

    (ein paar exemplarisch aufgelistet)

    Fehler 1: das Zeitfenster zwischen dem Propagieren des A6-DNS-Records und dann dessen Obsoleterklärung und den Ersatz in den AAAA-Records wie wir sie heute kennen war sicher nicht nur 3 Tage;

    Fehler 2: zu einem Zeitpunkt als es schon geheißen hat, dass die IPv4-Adress-Pools zur Neige gehen, waren garade mal 10% des am Markt

    verfügbaren Equipments IPv6-tauglich

    Fehler 3: lange bevor diese "Knappheit" bekannt wurde, kamen die ersten mobilen Geräte auf den Markt; und wieso hat man diese nicht gleich mit IPv6 ins Internet gebracht?

    (die Ausrede, dass die Mobilfunkbetreiber zu dem Zeitpunkt noch nicht in der Lage waren lass ich hier nicht gelten: wer Verträge verkaufen kann muss auch in der Lage sein, sie zu erfüllen; ich kann mich erinnern, als eine Gesprächsminute umgerechnet 75 cent kostete; und da war bereits absehbar dass der Preisindex nach unten geht/gehen wird; also hat man genug eingenommen/abgezockt um in der Lage zu sein)

    und andere Fehler mehr ...

    bevor IPv4 abgedreht werden kann, haben wir was neues und IPv6 interessiert keinen mehr ...=O

  • Das längste Thema

    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;

    df (diskfree), free (free memory)
    Code
    Filesystem     1K-blocks    Used Available Use% Mounted on
/dev/sda3       12668984 2976956   9026684  25% /
/dev/sda1        1009132  220748    719776  24% /boot
    Code
                   total        used        free      shared  buff/cache   available
Mem:         2493640      406408     1481140        7244      606092     1928104
Swap:        2621436           0     2621436

    mit WinXP hätt ma des auch geschafft, aber seit WinVISTA sind die Zeiten vorbei ...:D

  • Das längste Thema

    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

  • Das längste Thema

    Zitat von Paul

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

    WinSCP Log

    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

  • Das längste Thema

    Zitat von Paul

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

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

    Zitat von Paul

    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

    Zitat von Paul

    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]