No keyserver available

    Um Rückfragen vorzubeugen, bitten wir um folgende Angaben:

    • Thunderbird-Version:52.8.0
    • Betriebssystem + Version:Manjaro
    • Kontenart (POP / IMAP):IMAP
    • Postfachanbieter (z.B. GMX):t-online
    • S/MIME oder PGP:PGP
    • Eingesetzte Antivirensoftware:
    • Firewall (Betriebssystem-intern/Externe Software):

    Hallo,

    ich komme plötzlich nicht mehr auf den Key-Server pool.sks-keyservers.net oder hkps://hkps.pool.sks-keyservers.net
    um z.B. nach einem Schlüssel zu suchen

    Enigmail -> Schlüssel verwalten -> Schlüsselserver -> Suchen: Hanisch ->

    Leider konnte kein passender Schlüssel zu den angegebenen Suchkriterien gefunden werden.

    oder einen Schlüssel hochzuladen

    Enigmail -> Schlüssel verwalten -> einen Schlüssel markieren -> Schlüsselserver -> Öffentlichen Schlüssel hochladen... ->

    Senden der Schlüssel fehlgeschlagen gpg: connecting dirmngr at '/run/user/1000/gnupg/S.dirmngr' failed: IPC connect call failed gpg: no keyserver known gpg: keyserver send failed: No keyserver available

    Das tritt nur unerwartet bei einigen realen Manjaro-Systemen auf.

    $ ping pool.sks-keyservers.net

    Code
    PING pool.sks-keyservers.net (81.187.55.68) 56(84) bytes of data.  64 bytes from tarquin.boo.tc (81.187.55.68): icmp_seq=1 ttl=54 time=59.7 ms  64 bytes from tarquin.boo.tc (81.187.55.68): icmp_seq=2 ttl=54 time=59.3 ms  64 bytes from tarquin.boo.tc (81.187.55.68): icmp_seq=3 ttl=54 time=59.6 ms  ^C  --- pool.sks-keyservers.net ping statistics ---  3 packets transmitted, 3 received, 0% packet loss, time 2003ms  rtt min/avg/max/mdev = 59.329/59.570/59.709/0.171 ms

    Es muß also an Thunderbird/enigmail liegen.

    Was ist da passiert, daß das nicht mehr geht?

    Gruß
    Ch. Hanisch

    Edited 2 times, last by graba: Code-Tags gesetzt ().

    Hallo,

    offensichtlich ist die Ursache für das seltsame Verhalten ein Rechteproblem im Verzeichnis ~/.gnupg.

    Ich konnte mir ~/.gnupg aus einer Sicherung zurückspeichern und dann mit:


    Code
    # Set ownership to your own user and primary group
sudo chown -R "$USER:$(id -gn)" ~/.gnupg
# Set permissions to read, write, execute for only yourself, no others
sudo chmod 700 ~/.gnupg


    die Rechte neu setzen.


    Allerdings habe ich nach:


    Code
    # Set permissions to read, write for only yourself, no others
sudo chmod 600 ~/.gnupg/*


    keinen geheimen Schlüssel mehr.

    Woran liegt das?


    Jetzt stehen die Rechte für ~/.gnupg - Siehe Anhang


    Gruß

    Ch. Hanisch

    Quote from Hanisch

    Allerdings habe ich nach:

    Code
    sudo chmod 600 ~/.gnupg/*

    keinen geheimen Schlüssel mehr.

    Woran liegt das?

    Ist es möglich, dass Du vielleicht gnupg 2.1 oder aktueller nutzt? Private Schlüssel werden ab dieser Version in ~/.gnupg/private-keys-v1.d/ gespeichert, secring.gpg wird nicht mehr genutzt. Da du das Execute-Bit aller Elemente im .gnupg-Verzeichnis entfernt hast, sind Unterordner von .gnupg nach obenstehendem Befehl nicht länger zugängig, und der gpg-agent kann nicht mehr auf seine Dateien zugreifen.


    Wenn meine Theorie stimmt, setze die Rechte nochmal komplett neu. Achte darauf, dass Verzeichnisse das Execute-Bit zumindest für den Eigentümer gesetzt haben müssen, damit du auf sie zugreifen kannst. Ein Beispiel:

    Code
    chmod 0700 -R ~/.gnupg
find ~/.gnupg -type f -print0 | xargs -0 chmod 0600

    Hallo,

    Ich benutze folgende Version:

    Da alles bisher funktioniert werde ich auf dieses

    sudo chmod 600 ~/.gnupg/*

    verzichten.

    Wozu bracht man das eigentlich?


    Gruß

    Ch. Hanisch

    Quote from Hanisch

    Da alles bisher funktioniert werde ich auf dieses


    sudo chmod 600 ~/.gnupg/*

    verzichten.

    Wozu bracht man das eigentlich?

    Der Befehl setzt die Berechtigungen innerhalb des .gnupg-Verzeichnis zurück. Anschließend kann nur der Besitzer dort lesen oder schreiben, niemand (auch nicht der Besitzer!) darf dort Dateien ausführen oder in Unterverzeichnisse wechseln. Der Befehl kann also Probleme beheben, die z.B. durch versehentlich veränderte Dateirechte verursacht wurden. Für gnupg-Versionen vor 2.1 würde das auch wie erhofft funktionieren, da keine Unterverzeichnisse existieren und nichts ausgeführt werden muss.


    Für aktuelle Versionen von gnupg (so wie bei dir) sind Unterverzeichnisse jedoch z.B. für private Schlüssel erforderlich. Der Befehl entzieht in diesem Fall also Berechtigungen, die eigentlich notwendig waren. Dementsprechend muss man anders vorgehen, ein Beispiel steht in meinem letzten Beitrag. Wenn die Berechtigungen aber sowieso stimmen, gibt es keinen Grund diese zurückzusetzen.