Meu caso de uso é que tenho um servidor sem cabeçalho no qual o desenvolvimento de software é executado. Eu usualmente habilito o encaminhamento X11 para as conexões SSH, mas não consigo para locais distantes com conexões lentas.
Eu preciso de armazenamento seguro e cache para minhas credenciais git desde que eu trabalho regularmente com 18-20 repositórios em uma árvore, então eu estou usando git credential-gnome-keyring como o git credential.helper, que se comunica usando o keyring libgnome para o gnome-keyring-daemon. Para testar as soluções, configurei um PC com um monitor, confirmei o funcionamento do chaveiro por padrão no sistema e tentei com o SSH. Ele funciona com o encaminhamento do X11, mas não funciona sem ele.
Quando estou conectado sem o encaminhamento do X11, o seguinte erro ocorre quando o anel de chaves é consultado e a ferramenta retorna ao prompt na linha de comando:
** (process:18305): CRITICAL **: Error communicating with gnome-keyring-daemon
A investigação revela que o problema básico é que o daemon do gnome-keyring está esperando que as conexões usem o dbus para conversar com ele. O dbus não é iniciado se não houver uma sessão X11, então não há um barramento dbus comum para o gnome-keyring-daemon e o keychain do libgnome para se conectar.
Eu encontrei duas soluções que outros postaram para este problema, embora nenhum dos dois funcione corretamente para mim.
Ao anexar a uma porta DBUS existente, o conceito base é encontrar o PID de uma sessão de login existente, despejar o ambiente para esse PID do procfs, procurá-lo pelo DBUS_SESSION_BUS_ADDRESS
e exportá-lo no ambiente atual . Como esta é a variável usada para publicar o barramento DBUS sendo usado por tudo nas sessões, definir isso deve permitir que tudo na sessão se comunique em um barramento DBUS comum, embora seja o barramento associado a uma sessão diferente.
Fontes aqui:
link
link
Código adicionado ao meu .bashrc sendo executado no login do ssh:
if [ -z "$DBUS_SESSION_BUS_ADDRESS" ] ; then
local myPID='pgrep "(.*session|fluxbox)" | head -n1'
if [ -n "$myPID" ] ; then
local myVar='cat /proc/${myPID}/environ | grep -z "^DBUS_SESSION_BUS_ADDRESS=" | sed -e 's/DBUS_SESSION_BUS_ADDRESS=//''
if [ -n "$myVar" ] ; then
export DBUS_SESSION_BUS_ADDRESS=$myVar
fi
fi
fi
O segundo método, lançando manualmente o DBUS para a sessão, envolve o uso de dbus-launch
para criar uma nova sessão e definir o DBUS_SESSION_BUS_ADDRESS
para o ambiente, em seguida, iniciar o daemon do gnome-keyring com todos os serviços necessários. veja o endereço do barramento DBUS que criamos em vez de um endereço de barramento vazio. Esta solução pode ou não exigir que o daemon do gnome-keyring seja alterado para executar uma instância por sessão em vez de uma instância por sistema, mas não está claro.
Fontes:
Começando com o número 8: https://support.wandisco.com/index.php?/Knowledgebase/Article/View/362/17/how-to-setup- criptografado-svn-password-storage-usando-gnome-keyring-em-um-ssh-session
Código adicionado ao meu .bashrc sendo executado no login do ssh:
# then DBUS wasn't started for this session and needs to be
if [ -z "$DBUS_SESSION_BUS_ADDRESS" ] ; then
# start a new dbus session and make sure the variables are exported (automatic output)
eval 'dbus-launch --sh-syntax'
# make sure gnome-keyring-daemon is using all the necessary components (it may not be by default)
# Capture the output, which is a series of variable setting commands, one on eachline, and
# export them while setting them
while read -r LINE
do
export $LINE
done <<< $(gnome-keyring-daemon --start --components=gpg,pkcs11,secrets,ssh)
fi
Ambas as soluções fornecem o mesmo resultado com falha. Em vez de produzir imediatamente o erro indicando que o daemon do anel de chaves-gnome não pode ser comunicado, o processo trava por um tempo e então produz esta saída:
Gkr-Message: secret service operation failed: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
** (process:31155): CRITICAL **: Error communicating with gnome-keyring-daemon
Não estou claro sobre como o daemon do gnome-keyring está interagindo com o DBUS, mas está claro a partir do segundo conjunto de resultados de erro que ele não pode ser acessado através de um barramento DBUS recém-criado, ou processo cruzado em um DBUS diferente ônibus. Algumas das descobertas sugerem que o gnome-keyring-daemon pode precisar do DBUS iniciado antes dele, mas não está claro se esse é o caso para o uso (libgnome-keyring) ou o daemon.
Como faço para que isso funcione?
Tags gnome-keyring x11 d-bus