Impossible de trouver une clé valide dans le trousseau de sessions utilisateur pour la signature spécifiée dans l'option de montage après la mise à niveau du 16.04 vers 18.04


12

Il y a environ un mois, j'ai mis à jour mon serveur 16.04 LTS vers 18.04.1 LTS. La mise à niveau s'est bien passée. Cependant, depuis la mise à niveau, chaque fois qu'un utilisateur se connecte, un message s'affiche dans dmesgou sur la console locale (mais pas dans la session SSH de l'utilisateur) qui se lit comme suit:

[890802.820519] Could not find key with description: [HEXSTRING]
[890802.820537] process_request_key_err: No key
[890802.820538] Could not find valid key in user session keyring for sig specified in mount option: [HEXSTRING]
[890802.820557] One or more global auth toks could not properly register; rc = [-2]
[890802.820558] Error parsing options; rc = [-2]

Après beaucoup de recherches sur Google, j'ai trouvé cette question connexe et j'ai réussi à comprendre qu'il s'agissait d'une sauvegarde du disque personnel de l'utilisateur prise lors de la mise à niveau.

Je dois noter que les utilisateurs ont toujours accès à leurs disques durs et qu'ils n'ont pas de problème de connexion, ce n'est qu'un message d'agacement que j'essaie de nettoyer.

J'ai tenté d'ajouter la phrase secrète au trousseau de clés en utilisant la réponse acceptée dans la question liée:

$ /usr/bin/ecryptfs-manager

eCryptfs key management menu
-------------------------------
    1. Add passphrase key to keyring
    2. Add public key to keyring
    3. Generate new public/private keypair
    4. Exit

Make selection: 1

    Mount-wide passphrase:
    Confirm passphrase:
    Using the default salt value

That key was already in the keyring.

Ainsi, la clé est déjà dans le trousseau de clés, mais je reçois toujours le message d'erreur lorsqu'un utilisateur se connecte.

Comment puis-je empêcher cette notification / erreur de se produire?


La signature de clé introuvable ne correspond-elle pas à la signature de clé utilisée? Est-ce le même /home/.ecryptfs/user/.ecryptfs/Private.sig?
Xen2050

@ Xen2050 Oui, ils correspondent. Private.sig a deux clés et une de ces correspond à la "clé introuvable avec description" affichée.
Andy

Je ne suis pas sûr ... à moins que quelque chose essaie de monter un peu trop vite, puis réessaye et réussit (puisque tout semble fonctionner de toute façon) ... donc ça ressemble à un bug? Pourrait simplement effacer les lignes incriminées de syslog ... ou quel chemin / nom contient la "sauvegarde du disque personnel de l'utilisateur"? Peut-être qu'il essaie de monter la sauvegarde et échoue (les clés auraient pu changer)? eCryptfs a un mode détaillé, mais il enregistre les valeurs secrètes dans le journal système
Xen2050

Réponses:


3

Il semble que ce bogue ait été signalé pour la première fois dans Ubuntu 17.10: ecryptfs-mount-private ne parvient pas à initialiser les clés ecryptfs

L'erreur est comme la vôtre:

[ 1265.695388] Could not find key with description: [<correct key ID>]
[ 1265.695393] process_request_key_err: No key
[ 1265.695394] Could not find valid key in user session keyring for sig specified in mount option: [<correct key ID>]
[ 1265.695395] One or more global auth toks could not properly register; rc = [-2]
[ 1265.695396] Error parsing options; rc = [-2]

Vous devez vous abonner au rapport de bogue et vous assurer que vous le marquez vous affecte aussi.

Lisez les messages postés par d'autres utilisateurs. Il existe des solutions qui fonctionnent pour certains et pas pour d'autres.


0

Sur Ubuntu 18.04 lts, ​​cela fonctionne-t-il pour n'importe qui?

exec /usr/bin/startfluxbox

et si vous obtenez un msg vous demandant d'essayer d'exécuter l'interactif, ecryptfs-mount-privateessayez de le faire.

cela devrait donner quelque chose comme:

Jeton d'authentification inséré avec sig dans le trousseau de session utilisateur INFO: Votre répertoire privé a été monté

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.