Suponho que você esteja efetuando login no host1 como MyUser e, em seguida, usando su - ou sudo para alternar para a raiz. Ambos os métodos removerão a maioria ou todas as variáveis de ambiente ao fazer a transição de uma conta de usuário para outra, por segurança.
(Por exemplo, se você tivesse permissão apenas para executar comandos específicos como root com sudo , poderia contornar essa restrição com uma configuração de variável LD_PRELOAD ou LD_LIBRARY_PATH incorreta se todas as variáveis de ambiente fossem repassadas automaticamente. )
Quando você usa um agente de autenticação SSH, uma variável de ambiente importante é criada para sua sessão SSH no host1: SSH_AUTH_SOCK . Quando você conecta SSH ao servidor como MyUser, a presença dessa variável informa ao cliente SSH do host1 que uma conexão do agente de autenticação está disponível. A variável aponta para um socket Unix, tipicamente localizado em um diretório sob / tmp, que é acessível apenas pelo seu dono. Esse soquete está conectado ao processo sshd que manipula sua conexão de sua estação de trabalho para host1 e, finalmente, para o agente de autenticação PuTTY em sua estação de trabalho.
Se essa variável não for repassada quando su ing ou sudo ing de uma conta de usuário para outra, o cliente SSH não poderá usar a conexão do agente de autenticação após a transição. Como resultado, ele precisa solicitar uma frase secreta para descriptografar todas as chaves privadas disponíveis por conta própria.
Além disso, se você fizer a transição para outra conta não raiz, as permissões de arquivo no soquete e no diretório contido o impedirão de usá-lo, a menos que você tome medidas para permiti-lo explicitamente antes de fazer a transição para outro usuário. (Isso não é um problema ao fazer a transição para o root, porque o root pode acessar tudo.)