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 "$@"
}