Ich habe mir vor kurzem einen Cryptostick 1.2 besorgt. Ich benutze Debian 6.0 und habe libccid sowie dieses UDEV-Skript für den Cryptostick installiert. Aufruf “gpg --card-status” funktioniert immer (gpg-agent wird dabei nicht benutzt) und gpg2 --card-status nur als root. Interessanterweise funktioniert letzteres aber, wenn ich es nicht in einem Terminal unter X ausführe, sondern auf den Terminals, die man mit Strg+Fx erreicht (wie sagt man dazu?). Was ist das Problem?
rauch@matilda:~$ gpg2 --card-status
gpg: selecting openpgp failed: Nicht unterstütztes Zertifikat
gpg: OpenPGP Karte ist nicht vorhanden: Nicht unterstütztes Zertifikat
Hallo Robert, leider kann ich Dir nicht helfen. Du könntest Deine Frage an die GnuPG User Mailingliste oder auch an ein Fedora spezifisches Forum stellen.
das Problem taucht identisch auch unter dem aktuellen Ubuntu 11.10 auf. Ein Fendora Forum wird also kaum helfen. Besonders die Tatsache dass es ohne X11 tut fand ich sehr interessant. Vergleicht man die System-Calls beider Aufrufe, so ist der erste wesentliche Unterschied dass die X11-Version auf
und die Text-Version auf
zugreift. Der Pfad /tmp/keyring-1DtEWt/gpg stammt von der Environment-Variablen GPG_AGENT_INFO die auf der Textconsole tatsächlich nicht gesetzt ist. Löscht man diese z.B. mit
funktioniert der Aufruf bei mir auch unter X11.
Interessanterweise taucht GPG_AGENT_INFO in der Datei .xsession-errors auf und dort unter der Zeile
Man könnte jetzt spekulieren dass sich das Problem eventuell vermeiden lässt, wenn statt dem ssh-agent nur der gpg-agent dafür aber mit “ssh support” läuft. Werde ich mal bei Gelegenheit testen.
Als hässlichen Workaround bis dahin kann man gpg2 mit einem shellscript oder alias so kapseln, dass die Environment-Variable GPG_AGENT_INFO jeweils vorher gelöscht wird. Die Zeile
in .bash_aliases reicht dafür z.B. schon. Auf Dauer sollte man aber des Pudels Kern schon mal ordentlich freilegen.
Hallo Manfred, vielen dank für die ausführliche Fehlerbeschreibung. Könntest Du hierzu einen Bugreport erstellen? Entweder an GnuPG direkt oder an das Debian- oder Ubuntu Paket.
genau soweit bin ich leider noch nicht. Daher auch nur der hässliche Workaround . Ich kann den Fehler im Moment noch nicht mal klar einer Komponente zuweisen und wüsste daher auch nicht wohin mit dem Bugreport (GnuPG direkt oder an das Debian- oder Ubuntu Paket). Im Moment kratze ich da auch nur an der Oberfläche, aber wenn ich mal soweit bin werde ich einen Bugreport erstellen.
Es wäre z.B. auch hilfreich wenn andere betroffene Leser dieses Threads die Funktion des Ansatzes bestätigen oder widerlegen könnten.
Die oben erwähnte Vermutung man könnte das beheben, indem man den ssh-agent außer Betrieb nimmt und den gpg-agent dafür mit –enable-ssh-support startet hat sich bei mir nicht bestätigt. Es ist trotzdem eine gute Idee nicht zwei Agenten zu betreiben. Nicht ohne Grund wurde dem gpg-agent die ssh-Funktion mit implementiert. Wie es geht siehe: wiki.kumina.nl/index.php/Managing_ssh_keys_with_gpg-agent
Das tut bei mir sehr gut löst aber leider nicht das vorliegende Problem.
Die betroffene Variable GPG_AGENT_INFO sollte eigentlich (laut manpage) von der Form :: sein. Bei mir steht statt der PID einfach 0 was schonmal falsch ist. Schaut man sich den laufenden gpg-agent Prozess an, so wird er (zumindest unter Ubuntu) mit der Option –write-env-file gestartet. Man kann also die korrekten Einstellungen in der dort angegebenen Datei finden. Bei mir ist das ${HOME}/.cache/gpg-agent-info. Tatsächlich steht dort der korrekte Wert mit dem das ganze dann auch tut ohne die Variable zu löschen. Damit haben wir schonmal den nächsten nichtmehr ganz zu hässlichen Workaround: Einfach diese Datei sourcen und schon ist das Environment so wie es die Clienten des gpg-agent benötigen. Man kann z.B. die bisherige Zeile in .bash_aliases
ersetzen durch
und bekommt einen deutlich hüpscheren Workaround der die hässliche Meldung über den scdaemon vermeidet und zudem schneller ist. Bei anderen Distributionen kann die Datei natürlich unter einem anderen Pfad mit einem anderen Namen stehen. Also bitte immer erst in der Prozessliste nachsehen.
Erklärt aber leider nicht woher die Fehlinformation eigentlich kommt und warum die korrekte nicht verwendet wird. Allerdings kann man jetzt von einem Konfigurationsproblem der Distribution ausgehen und nicht von einem Bug im gpg2.
ich habe mein Problem inzwischen auch gelöst, leider habe ich es nicht sofort hier dokumentiert und kann deshalb nur noch aus meiner Erinnerung berichten…
Also in der Tat bin ich dann auch darauf gekommen, dass gpg2 nicht korrekt funktioniert, da die Umgebungsvariable GPG_AGENT_INFO nicht korrekt definiert wird. Bei mir war es so, dass beim nach dem Starten von GNOME diese Variable auf Seahorse verweist, und gpg2 mit diesem offebar nicht funktioniert. Dies hat leider z.B. den Effekt, dass Enigmail nicht funktionieren wollte, obwohl gpg (version 1.4.x) auf der Konsole einwandfrei mit meinem Cryptostick funktionierte. Enigmail geht nämlich, sobald GPG_AGENT_INFO gesetzt ist, davon aus, dass der gpg-agent läuft.
Die Frage lautete also damit, warum der gpg-agent nicht korrekt gestartet wird. Unter meinem Debian 6.0 ist dafür anscheinend /etc/X11/Xsession.d/90gpg-agent zuständig:
if grep -qs ‘^:space:]]*use-agent’ “$GNUPGHOME/gpg.conf” “$GNUPGHOME/options” &&
test -x $GPGAGENT &&
{ test -z “$GPG_AGENT_INFO” || ! $GPGAGENT 2>/dev/null; }; then
if -r “$PID_FILE” ]; then
. "$PID_FILE"
fi
Invoking gpg-agent with no arguments exits successfully if the agent
is already running as pointed by $GPG_AGENT_INFO
if ! $GPGAGENT 2>/dev/null; then
STARTUP="$GPGAGENT --daemon --sh --write-env-file=$PID_FILE $STARTUP"
fi
fi[/code]
Leider bin ich nicht so gut im Skripte verstehen, aber irgendwie habe ich dann probiert die Option use-agent in ~/.gnupg/gpg.conf zu setzen, die dazu führte, dass der gpg-agent beim Starten von GNOME korrekt gestartet wird, und die Variable GPG_AGENT_INFO korrekt überschreibt.
danke dass du deinen Ansatz auch noch hier veröffentlicht hast.
Wir würfeln da m.E. nur gerade zwei Probleme durcheinander. Der Eintrag use-agent in .gnupg/gpg.conf löst lediglich das Problem dass gpg sonst selbst versucht (ohne agent) die SmartCard zu kontatktieren was zu einem Konflickt mit dem Agenten führt:
gpg: pcsc_connect failed: sharing violation (0x8010000b)
gpg: apdu_send_simple(0) failed: locking failed
Da gpg2 den Agenten voraussetzt muss auch gpg den Agenten nutzen sobalt gpg2 installiert ist.
Der Eintrag von use-agent löst den Konflickt mit dem Agenten führt aber zunächst nur dazu, dass beide gpg und gpg2 genau die Fehlermeldung zeigen mit der Du den Thread eröffnet hast:
$ gpg --card-status
gpg: selecting openpgp failed: unknown command
gpg: OpenPGP Karte ist nicht vorhanden: Allgemeiner Fehler
$ gpg2 --card-status
gpg: selecting openpgp failed: Nicht unterstütztes Zertifikat
gpg: OpenPGP Karte ist nicht vorhanden: Nicht unterstütztes Zertifikat
Der Eintrag use-agent führt wie der Name schon sagt nur zur Benutzung des Agenten. Gestartet sollte er bis dahin schon sein.
Kannst Du dich noch daran erinnern ob Du noch etwas anderes verändert hast damit die Variable GPG_AGENT_INFO stimmt?
Das denke ich nicht. Mir ist schon klar wofür die Option use-agent eigentlich gedacht ist. Was ich eigentlich geschrieben habe war jedoch folgendes:
[ul]1) gpg2 funktionierte nicht, weil GPG_AGENT_INFO auf irgendetwas, was mit Seahorse zu tun hat, verwiesen hat.
der gpg-agent wurde beim Start von GNOME erst dann korrekt (d.h. insbesondere, dass GPG_AGENT_INFO korrekt gesetzt wird) gestartet, nachdem in ~/.gnupg/gpg.conf die Option use-agent gesetzt wurde. Der Grund dafür war das “fehlerhafte” Startskript /etc/X11/Xsession.d/90gpg-agent[/ul]
Wie du schon geschrieben hast, handelt es sich hierbei offenbar nicht um ein Problem von GnuPG, sondern der Distribution und ich schlage vor, den Fehler in dem o.g. Startskript des gpg-agenten zu suchen.
Hallo Robert,
dann ist das Problem immerhin für Dich gelöst. Glückwunsch.
Allerdings ist diese Lösung bei mir nicht reproduzierbar. Das Skript /etc/X11/Xsession.d/90gpg-agent prüft tatsächlich den Eintrag use-agent in .gnupg/gpg.conf und könnte damit den Zusammenhang zwischen diesen an sich unabhängigen Themen bei dir herstellen. Vermutlich hat dieses Skript bei dir nach dem Eintrag von use-agent überhaupt erst mal was getan und dann das Problem für dich gelöst.
In meiner Konfiguration läuft der Agent allerdings bereits wenn dieses Skript zur Anwendung kommt und entsprechend wird nichts weiter unternommen. Ich kann 90gpg-agent vollständig entfernen und es ändert nichts. Entsprechend ändert der use-agent Eintrag auch nichts an GPG_AGENT_INFO.
Diese Dinge sind leider sehr stark von der jeweiligen Distribution abhängig und mit ein Grund warum sich kommerzielle Anbieter immer etwas schwer tun für Linux SW zu vermarkten. Linux gibt es nicht; es gibt nur ganz viele verschiedene Linuxe . @Jan: Wo man da welchen Bugreport machen müsste ist dann eben immer etwas verkorkst wie du siehst.
Unter Xubuntu wird der Agent offenbar in /etc/xdg/xfce4/xinitrc gestartet. Für diesen Fall ist die Beschreibung unter dem oben erwähnten Link mit der Umstellung von ssh-agent auf gpg-agent mit –enable-ssh-support auch nur bedingt richtig. Auch dort wird 90gpg-agent gepatched. Das Problem bleibt hier leider unverändert.
Zusätzlich bietet der gnome-keyring-daemon unter /tmp/keyring-*/ sockets für gpg und ssh an. Genau hierher zeigt auch der Wert in GPG_AGENT_INFO der nicht funktioniert (mit der PID=0). In diesem Dunstkreis muss das bei mir vorliegende Durcheinander wohl auch entstehen. Zu viele Köche …
Wenn hier noch jemand zugange ist bei dem das Problem auch nicht einfach mit use-agent aus der Welt ist, bitte melden. Danke
Das Problem fällt offenbar etwas in die Kategorie “Selber Schuld”
Xubuntu 11.10 hat in den Einstellungen für “Sitzung und Startverhalten” einen Reiter “Fortgeschritten” in dem man unter anderem eine “Laufzeitumgebung für Gnome beim Start laden” kann. Exakt das ist der Anfang von diesem Durcheinander mit den Agent, ihren Sockets und darauf verweisenden Variablen.
Lässt man das aus, ist die Welt in Ordnung.
Es ist auch etwas dreist nicht wirklich GNOME zu benützen sondern nur so zu tun als ob, dann noch e-Mails mit SmartCard zu verschlüsseln und ssh ohne Passwort und bei allem dann zu erwarten dass das out-of-the-box läuft. Also entweder richtig GNOME oder Finger weg von der Laufzeitumgebung. Das Problem vollends aufzuklären fehlt mir jetzt auch die Motivation da Xubuntu für mich nur die Übergangslösung ist bis es wieder ein Ubuntu mit richtigem GNOME gibt (Unity tut bei mir ergonomisch irgendwie garnicht ).
bis dahin kann man gpg2 mit einem shellscript oder alias so kapseln, dass die Environment-Variable GPG_AGENT_INFO jeweils vorher gelöscht wird. Die Zeile
.
).