Xなしでgnome-keyring-daemonを使用できるかどうか疑問に思っています。通常、キーリングのパスワードを取得するために、グラフィカルなプロンプトが表示されます。これを回避する方法はありますか?グラフィカルセッションを開始してパスワードを入力しなくても、ubuntuを使用できるようにしたいのですが。
pam_gnome_keyring.so
を使用して、デーモンを起動およびロック解除できます。 GDMはすでにこれを行っています。 login
の場合は、手動で構成する必要があります。
これらの行を/etc/pam.d/login
に追加します。
auth optional pam_gnome_keyring.so session optional pam_gnome_keyring.so auto_start
パスワードなしでログインした場合(Kerberosまたは公開鍵を使用したSSH)、これはmayで機能します(テストしていません)。
echo -n "mypassword" | gnome-keyring-daemon-ログイン
(まだデーモンが実行されている必要があります-PAMまたは--daemonize
で開始されます。)
キーリングサポート付きのsvnのインストールとCollabnet keyring_toolアプリケーションのインストールに必要なジョブは、Linuxサーバーですでに実行されています。
1)キーリングを使用するようにSVNクライアントを構成します。
1.1)〜/ .Subversion/configを編集します
[auth]
password-stores = gnome-keyring
1.2)〜/ .Subversion/serversを編集します
[global]
store-passwords = yes
store-plaintext-passwords = no
2)パスワード用の鍵リングを作成します。キーリングのロックを解除するための新しいパスワードを作成するように求められます。これはあなたが望むものなら何でもよい:
keyring_tool --create=svn
3)新しいキーリングをデフォルトとして設定します。
keyring_tool --setdef=svn
4).bash_profileまたは.bash_login(端末としてbashを使用していると想定)
if [ -e /usr/bin/gnome-keyring-daemon ]; then
if [ ! -z "`kill -0 $GNOME_KEYRING_PID 2>&1`" ]; then
# Create dbus transport link for SVN to talk to the keyring.
eval `dbus-launch --sh-syntax`
# Start the keyring daemon.
# The use of export here captures the GNOME_KEYRING_PID, GNOME_KEYRING_SOCK
# env values echoed out at startup.
export `/usr/bin/gnome-keyring-daemon`
fi
fi
5).bash_logout
# Kill the message bus established for SVN / Keyring communication
if [ ! -z "`kill -0 $DBUS_SESSION_BUS_PID 2>&1`" ]; then
kill $DBUS_SESSION_BUS_PID > /dev/null 2>&1
fi
# Kill the Gnome Keyring Daemon prior to logout.
if [ ! -z "`kill -0 $GNOME_KEYRING_PID 2>&1`" ]; then
kill $GNOME_KEYRING_PID > /dev/null 2>&1
fi
承認されたユーザーが特定のSVNリポジトリにアクセスできるようにするための手間のかからない方法を確立しようとしているときに、同様の問題に遭遇しました。基本的に、ユーザーがサーバーにアクセスするたびに資格情報のチェックを強制する必要があるため、svn updateコマンドでも認証が必要になります。明らかにプレーンテキストのパスワードの保存ができなかったので、少しの調査を行って、承認されていないユーザーがリポジトリにアクセスできないようにしながら、一定の認証要求でユーザーベースに嫌がらせをする方法としてgnome-keyringを使用しました。
私たちの日々の作業の多くは、XサポートのないRedHatサーバーへのsshトンネルを介して行われるため、X11サポートを回避する方法を見つける必要がありました。いくつか検索した後、私はなんとかそれを回避する方法をここに見つけました:
ここで鍵となるのは、Collabnet keyring_toolを使用してgnome-keyring-managerクライアントなしで鍵リングを作成し、SVNにセットアップを処理させるのではなく、dbus-launchを自分で確立することです。 SVNはDBUSを使用してgnome-keyring-daemonに接続し、認証全体に影響を与えます。 -sh-syntaxを使用してdbusセッションを手動で開始および終了することにより、dbusの起動時にXクライアントに接続することを回避できます。 gnome-keyring-daemonを起動してSVNを使用しようとすると、キーリングパスワードの入力を求められますが、SVN資格情報の入力も求められます。 Xクライアントがないため、SVNが開始しようとするとdbusが失敗します。どうやら、SVNはdbusの起動時に特別なフラグを使用しません。
まず、本当にやりたいことは、厳密にコマンドラインからUbuntu Oneを実行することです。 buntu One FAQ をご覧ください。 FAQによると 現時点では不可能ですが、1sdtoolや1syncなどのCLIツールがいくつかあります。 LaunchpadのUbuntu Oneには FAQのセット もあります。コンテンツは、以前のwiki.ubuntu.comリンクと同じである場合があります。
gnome-keyring-daemonに関する実際の質問については、 FAQの提案 (1)自動ログインの設定と(2)キーリングパスワードとログインパスワードの同期。これは(理論的には)パスワードプロンプトを回避しますが、それは少なくとも基本的なXセッションが実行されている必要があります。
Launchpadに buntu Oneバグ/ウィッシュリスト があり、ヘッドレスシステムの処理を簡単にするように要求します。どうやら、ソースからのビルドは、軽量のインストールに推奨されます(すべてのGUIライブラリなどの必要性を回避するため)。 このコメント は古いですが、特に興味深いものです。
問題は、python-gnomekeyringを使用していることです。ヘッドレスをサポートするには、python-keyringに切り替えて、ヘッドレスディスプレイのgnome-keyring以外の場所にトークンを格納する必要があります。ただし、Karmicパッケージは凍結されているため、これは発生せず、この変更はSRUでは受け入れられません。
Lucidの場合、より堅牢な認証サービスが必要です。これにより、ヘッドレスディスプレイをより適切にサポートできるようになります。
この「より堅牢な認証サービス」が実際にLucidに導入されたかどうかはわかりません。パッケージの依存関係に基づいて、Ubuntu Oneクライアントはまだpython-gnomekeyringに依存しているようです。
X転送されたSSHセッションでmysql-workbenchをgnome-keyringと連携させることで、ある程度成功しました。これは、公開鍵認証(パスワードなし)を使用したアカウントです。
Sshセッションに接続したら、dbus-run-sessionを使用してこれを実現しました。
dbus-run-session bash -c 'GNOME_KEYRING_CONTROL=1 mysql-workbench --verbose'
うまくいけば、この情報は誰かに役立ちます!