回答:
pam_gnome_keyring.soデーモンを起動およびロック解除するために使用できます。GDMはすでにこれを行っています。の場合login、手動で構成する必要があります。
以下にこれらの行を追加し/etc/pam.d/loginます。
authオプションpam_gnome_keyring.so セッションオプションpam_gnome_keyring.so auto_start
パスワードなしでログインした場合（Kerberosまたは公開キーを使用したSSH）、これは機能する可能性があります（テストしていません）
echo -n "mypassword" | gnome-keyring-daemon --login
（まだデーモンを実行する必要があります-PAMまたはで起動し--daemonizeます。）
gnome-keyring-daemon --helpます。マンページと/ usr / share / docを確認しました。
read -rsp "Password: " pass; echo -n "$pass" | gnome-keyring-daemon --loginスクリプトで。
gnome-keyring-daemon --help良い概要を教えてくれますがman gnome-keyring-daemon、プログラム自体についての短い説明が含まれていますが、議論はありません。
キーリングサポート付きの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を起動しようとするとdbusは失敗します。どうやらSVNはdbusの起動時に特別なフラグを使用しません。
まず、本当にやりたいことは、Ubuntu Oneをコマンドラインから厳密に実行することです。見てみましょうUbuntuの一つのよくある質問。よくある質問は言うことが現在可能ではないですが、のようないくつかのCLIツールがあるu1sdtoolとu1syncが。Launchpadには、Ubuntu One に関するFAQのセットもあります。コンテンツは以前のwiki.ubuntu.comリンクと同じである可能性があります。
gnome-keyring-daemonについてのあなたの実際の質問に関して、FAQは（1）自動ログインを設定し、（2）キーリングパスワードをログインパスワードと同期することを提案しています。これは、（理論的には）パスワードプロンプトを避けるだろうが、それはでしょう、少なくとも基本的なX-セッションが実行されている必要があります。
Launchpadには、ヘッドレスシステムの処理を簡単にすることを要求するUbuntu Oneのバグ/ウィッシュリストがあります。どうやらソースからビルドすることは、軽量インストールの場合に推奨されます（すべてのGUIライブラリなどの必要性を回避するため）。 このコメントは古いですが、特に興味深いものです：
問題は、python-gnomekeyringを使用していることです。ヘッドレスをサポートするには、python-keyringに切り替えて、ヘッドレスディスプレイでgnome-keyring以外の場所にトークンを保存する必要があります。ただし、Karmicパッケージは凍結されているため、これは発生しません。SRUではこの変更は受け入れられません。
Lucidには、より堅牢な認証サービスが必要です。これにより、ヘッドレスディスプレイをより適切にサポートできるようになります。
この「より堅牢な認証サービス」が実際にLucidに導入されたかどうかはわかりません。パッケージの依存関係に基づいて、Ubuntu Oneクライアントはまだpython-gnomekeyringに依存しているようです。
--loginオプションは非常に便利ですが、ハッシュ化されていないパスワードをスクリプトに保持したり、コマンドラインに入力したりしたくないでしょう。（非シェル言語）スクリプト内から非エコーモードで読み取り、その入力を生成されたデーモンに渡すことは、おそらくこれを行うための良い方法でしょう。ブートごとにこのプロセスを開始する必要があるのは1回だけなので、パスワードを入力するのは理にかなっています。GTKダイアログ経由ではなく、コマンドラインで実行できるようにする必要があります。