Beiträge von Kalle12

    Hallo allerseits,


    die Meldung, dass der qemu-guest-agent auf meinem System nicht installiert sei, hatte ich auch schon mehrfach, obwohl der qemu-ga auf meinem VServer (VPS) läuft.

    Unter CentOS 7 sieht das seit Monaten so aus:


    Code
    # systemctl status -l qemu-guest-agent
    ● qemu-guest-agent.service - QEMU Guest Agent
       Loaded: loaded (/usr/lib/systemd/system/qemu-guest-agent.service; enabled; vendor preset: enabled)
       Active: active (running) since Fri 2020-02-07 09:05:43 CET; 6h ago
     Main PID: 881 (qemu-ga)
       CGroup: /system.slice/qemu-guest-agent.service
               └─881 /usr/bin/qemu-ga --method=virtio-serial --path=/dev/virtio-ports/org.qemu.guest_agent.0 --blacklist=guest-file-open,guest-file-close,guest-file-read,guest-file-write,guest-file-seek,guest-file-flush,guest-exec,guest-exec-status -F/etc/qemu-ga/fsfreeze-hook


    Es wird vom Netcup-KVM-Host anscheinend nicht erkannt, dass der qemu-ga läuft. Ist mein qemu-ga evtl. falsch konfiguiert?


    Heute morgen war im Control-Bereich des SCP die Meldung "New KVM Version available! Please power cycle this instance to activate new improvements." Das habe ich dann auch gemacht. Danach kam der Server nur mit leichten Schwierigkeiten wieder hoch (Filesystemcheck), da er wohl 'hart' herungergefahren wurde. Glücklicherweise ist nichts beschädigt worden.


    Auf einem anderen VServer (Rootserver) ist die Situation vergleichbar. Dort läuft seit Monaten testweise ein Windows Server 2019 mit allen virtio-Paketen und dem qemu-guest-agent.


    Wie bekomme ich die VServer denn wirklich komplett ausgeschaltet um einen kompletten Reset zu machen? Per Forced Poweroff oder Forced Reset?


    Kalle.

    Moin,


    da @include common-auth in der PAM-Config des sshd auskommentiert ist, funktioniert die Passwortüberprüfung für den Fall AuthenticationMethods password,publickey nicht.


    Um den Fall 'AuthenticationMethods publickey,keyboard-interactive' ohne Passwortüberprüfung abzudecken könntest Du versuchen @include common-auth mittels pam_succeed_if.so mit einem Match auf "user ingroup SSHManager" zu überspringen. Siehe auch "man pam_succeed_if". Am besten in den anderen PAM-Files Deiner Distribution nachsehen, wie das dort gehandhabt wird.

    Unter CentOS 7.5 funktioniert das selektive Überspringen der Passwortüberprüfung (substack password-auth) für den User sonderfall so: (Anfang von /etc/pam.d/sshd)

    Code
    %PAM-1.0
    auth required  pam_yubico.so nullok id=1 key...
    auth       [default=ignore success=1]  pam_succeed_if.so user = sonderfall
    auth       substack     password-auth
    auth       required     pam_sepermit.so
    auth       include      postlogin
    [...]



    Gruß,


    Kalle.

    Moin,


    ich bin mit CentOS 7.5 unterwegs mit PAM Version 1.1.8-22.el7. Dort sieht /etc/pam.d/sshd deutlich anders aus, sodass ich zu Deiner PAM-config nicht viel sagen kann. Ich hänge hier mal den Anfang meiner /etc/pam.d/sshd rein:


    Code
    #%PAM-1.0
    auth required  pam_yubico.so nullok [Rest yubico weggelassen]
    # Der User Willi muss sich nicht per Passord authentifizieren, alle anderen schon
    # success=1 überspringt die Zeile 'auth       substack     password-auth'
    auth       [default=ignore success=1]  pam_succeed_if.so user = willi
    auth       substack     password-auth
    auth       required     pam_sepermit.so
    auth       include      postlogin
    [...]

    Als erstes wird das Yubikey PAM-Modul eingebunden. Wenn die Yubikey-Auth erfolgreich war wird mit 'auth substack password-auth' zusätzlich die Unix-Passwort-Abfrage gestartet, sodass man eine 3-Faktor Authentifizierung hat, außer der Username ist willi. (Man kann natürlich die password-auth Zeile einfach auskommentieren und die pam_succeed_if Geschichte weglassen und hat dann eine reine 2-Faktor-Authentifizierung).


    Viele Anleitungen mit Bezug auf pam_google_authenticator und Debian 9 schalten in der PAM-Config des sshd 'common-auth' ab. Bei Dir ist das aktiv, was vermutlich die zusätzliche Passwortabfrage nach erfolgreicher Google-Authentifizierung zur Folge hat. Siehe auch:


    Anleitung Debian 9 und Google-Auth


    Dort sieht das so aus:


    Code
    Find the line @include common-auth and comment it out, like what is shown below.
    
    # Standard Un*x authentication.
    #@include common-auth

    Probier das doch mal aus.


    Ich habe bei mir 3 Varianten aktiv (je nach user):


    1.) Nur Yubikey OTP

    2.) Yubikey OTP + Unix Password

    3.) Publickey + Unix Password


    Ich hoffe das hilft etwas weiter.


    Gruß,


    Kalle.

    Moin,


    um zu Testen, ob die Matches in der sshd.config richtig triggern kann man die Optionen -T und -C des sshd verwenden.

    Hier das Ende meiner sshd_config:


    Code
    ChallengeResponseAuthentication yes
    # exceptions for special users without yubikey
    Match Group user1
            AuthenticationMethods  publickey,password
            PasswordAuthentication yes
    
    # defaults for all yubikey users (pub-key + yubikey)
    Match all
            AuthenticationMethods publickey,keyboard-interactive
            PasswordAuthentication no

    Mit dem user1 der Mitglied von group1 ist ergibt sich dann z.B. dies:

    Code
    # sshd -T -C user=user1 -C host=localhost -C addr=127.0.0.1|grep -i AuthenticationMethods
    exposeauthenticationmethods never
    authenticationmethods publickey,password

    Das heißt, der Match auf Group user1 hat getriggert. Damit sollte sich das Verhalten des sshd nachvollziehen lassen. Eine andere Baustelle ist PAM. Evtl. wird in der PAM-Config des sshd password-auth getriggert...


    Gruß,


    Kalle.

    Moin,


    auf einem frisch aufgesetzten CentOS 7 Minimalsystem (Rootserver
    RS 1000 G7 SE) mit Netzkonfiguration per DHCP ergibt sich folgende Routing Tabelle:


    Code
    $ route -nKernel IP routing tableDestination 	Gateway     	Genmask     	Flags Metric Ref	Use Iface0.0.0.0     	185.162.248.1   0.0.0.0     	UG	100	0    	0 eth046.38.225.12	185.162.248.1   255.255.255.255 UGH   100	0    	0 eth0185.162.248.0   0.0.0.0     	255.255.252.0   U 	100	0    	0 eth0


    Wozu dient die Hostroute auf die IP 46.38.225.12 ?
    Diese IP (gehört zu netcup) ist doch bereits über die Defaultroute erreichbar.


    MfG,


    Kalle.