Se você tem um agente ssh
em execução, faça:
sudo SSH_AUTH_SOCK="$SSH_AUTH_SOCK" git clone...
Isso basicamente diz ao comando git
iniciado por root
(ou o comando ssh
iniciado pelo comando git
) para usar seu ssh
agent (como se conectar a ele, que root
deve poder como tem todo direito).
Se você não tem um agente ssh em execução, você pode começar um com:
eval "$(ssh-agent)"
(e adicione chaves a ele conforme necessário com ssh-add
).
Como alternativa, você pode usar
sudo -E git clone...
Para passar todas as variáveis de ambiente em sudo
, não apenas $SSH_AUTH_SOCK
.
Eu não recebi a sugestão do @ NgOon-Ee no comentário para adicionar $SSH_AUTH_SOCK
à lista env_keep
. Em geral, você não deseja poluir o ambiente de root
, pois esse é o usuário no qual você inicia os serviços. Por exemplo, sudo sshd
para iniciar um serviço sshd
significaria que todas as ssh
sessões iniciadas através desse serviço herdariam seu $SSH_AUTH_SOCK
, poluindo o ambiente dos usuários com algo que eles não podem e não deveriam usar. Mesmo para outros usuários de destino do que root
, transmitir essa variável não faria sentido, pois o usuário de destino não poderia fazer uso desse agente de autenticação.
Agora, isso só atende à autenticação de chaves. Se você também quisesse que root
herdasse suas configurações em ~/.ssh/config
, você não poderia fazer isso com ssh
de variáveis de ambiente, mas poderia fazer isso com git
de variáveis de ambiente. Por exemplo, definindo uma função sugit
como:
sugit() {
sudo "GIT_SSH_COMMAND=
exec ssh -o IdentityAgent='$SSH_AUTH_SOCK' \
-o User=$LOGNAME \
-F ~$LOGNAME/.ssh/config" git "$@"
}
Ou seja, diga git
para usar o comando ssh
que usa seu arquivo de configuração ssh e agente e nome de usuário em vez de root.
Ou talvez ainda melhor, diga git
para executar ssh
como o usuário original:
sugit() {
sudo "GIT_SSH_COMMAND=
exec sudo -Hu $LOGNAME SSH_AUTH_SOCK='$SSH_AUTH_SOCK' ssh" git "$@"
}