Se você é root dentro da máquina, provavelmente pode **acessar qualquer conexão ssh feita por qualquer agente** que você possa encontrar no diretório _/tmp_
Quando você define a variável `SSH_AUTH_SOCK`, você está acessando as chaves de Bob que foram usadas na conexão ssh de Bob. Então, se sua chave privada ainda estiver lá (normalmente estará), você poderá acessar qualquer host usando-a.
Como a chave privada é salva na memória do agente sem criptografia, suponho que se você for Bob, mas não souber a senha da chave privada, ainda poderá acessar o agente e usá-lo.
O SSH sem senhas torna a vida com sistemas operacionais semelhantes ao Unix muito mais fácil. Se sua rede requer sessões ssh encadeadas (para acessar uma rede restrita, por exemplo), o encaminhamento do agente se torna extremamente útil. Com o encaminhamento do agente, é possível para mim conectar do meu laptop ao meu servidor de desenvolvimento e de lá executar um checkout svn de outro servidor, tudo sem senhas, mantendo minha chave privada segura em minha estação de trabalho local.
Isso pode ser perigoso, no entanto. Uma rápida pesquisa na web revelará vários artigos indicando que isso só é seguro se os hosts intermediários forem confiáveis. Raramente, no entanto, você encontrará uma explicação do _porquê_ é perigoso.
Ao autenticar no modo normal, o SSH usa sua senha para provar que você é quem diz ser. O servidor compara um hash desta senha com um que ele tem em arquivo, verifica se os hashes correspondem e permite que você entre.
Se um invasor conseguir quebrar a criptografia usada para proteger sua senha enquanto ela está sendo enviada para o servidor, ele pode roubá-la e fazer login como você sempre que desejar. Se um invasor puder realizar centenas de milhares de tentativas, ele eventualmente poderá adivinhar sua senha.
Um método de autenticação muito mais seguro é a [autenticação de chave pública](http://www.ibm.com/developerworks/library/l-keyc/index.html), uma maneira de fazer login sem senha. A autenticação de chave pública requer um par correspondente de chaves pública e privada. A chave pública criptografa mensagens que só podem ser descriptografadas com a chave privada. O computador remoto usa sua cópia da sua chave pública para criptografar uma mensagem secreta para você. Você prova que é você descriptografando a mensagem usando sua chave privada e enviando a mensagem de volta para o computador remoto. Sua chave privada permanece segura em seu computador local o tempo todo, protegida contra ataques.
A chave privada é valiosa e deve ser protegida, portanto, por padrão, ela é armazenada em um formato criptografado. Infelizmente, isso significa inserir sua frase de senha antes de usá-la. Muitos artigos sugerem usar chaves privadas sem frase de senha (não criptografadas) para evitar esse inconveniente. Isso é uma má ideia, pois qualquer pessoa com acesso à sua estação de trabalho (por acesso físico, roubo ou hackeamento) agora também tem acesso gratuito a qualquer computador configurado com sua chave pública.
O OpenSSH inclui [ssh-agent](http://www.openbsd.org/cgi-bin/man.cgi?query=ssh-agent), um daemon que é executado em sua estação de trabalho local. Ele carrega uma cópia descriptografada de sua chave privada na memória, para que você só precise inserir sua frase de senha uma vez. Ele fornece um [socket](http://en.wikipedia.org/wiki/Unix\_domain\_socket) local que o cliente ssh pode usar para pedir que ele descriptografe a mensagem criptografada enviada de volta pelo servidor remoto. Sua chave privada permanece segura no processo do ssh-agent, permitindo que você faça ssh sem digitar senhas.
Muitas tarefas exigem sessões ssh "encadeadas". Considere meu exemplo anterior: eu faço ssh do meu laptop para o servidor de desenvolvimento. Lá, preciso executar uma atualização svn, usando o protocolo "svn+ssh". Como seria bobo deixar uma cópia não criptografada da minha chave privada supersecreta em um servidor compartilhado, agora estou preso com autenticação por senha. No entanto, se eu habilitar "ForwardAgent" na configuração ssh em meu laptop, o ssh usa suas capacidades de tunelamento embutidas para criar outro socket no servidor de desenvolvimento que é tunelado de volta para o socket ssh-agent em minha estação de trabalho local. Isso significa que o cliente ssh no servidor de desenvolvimento agora pode enviar solicitações de "descriptografar esta mensagem secreta" diretamente de volta para o ssh-agent em execução em minha estação de trabalho, autenticando-se para o servidor svn sem nunca ter acesso à minha chave privada.
Simplesmente, qualquer pessoa com privilégios de root no servidor intermediário pode fazer uso gratuito do seu ssh-agent para autenticá-los em outros servidores. Uma demonstração simples mostra o quão trivialmente isso pode ser feito. Os nomes de host e usuários foram alterados para proteger os inocentes.
Meu laptop está executando ssh-agent, que se comunica com os programas cliente ssh por meio de um socket. O caminho para este soquete é armazenado na variável de ambiente SSH\_AUTH\_SOCK:
Eu tenho "ForwardAgent yes" no \~/.ssh/config no meu laptop. Então, o ssh vai criar um túnel conectando o socket local a um socket local no servidor remoto:
Mesmo que minhas chaves não estejam instaladas em "seattle", os programas clientes ssh ainda são capazes de acessar o agente em execução na minha máquina local:
Existem várias maneiras para o root visualizar o ambiente de um processo em execução. No Linux, os dados estão disponíveis em /proc/\<pid>/environ. Como eles são armazenados em strings terminadas em NULL, usarei o comando tr para converter os NULLs em novas linhas:
Se eu tiver um alvo específico em mente, agora devo ser capaz de me conectar diretamente. Caso contrário, apenas observar a lista de processos ou pesquisar no arquivo de histórico de Bob deve apresentar muitos alvos de oportunidade. Neste caso, eu sei que Bob tem todos os tipos de arquivos super secretos armazenados no servidor chamado "boston":
Não permita que seu ssh-agent armazene suas chaves indefinidamente. No OS X, configure sua Keychain para bloquear após inatividade ou quando a tela é bloqueada. Em outras plataformas Unix, passe a opção -t para ssh-agent para que suas chaves sejam removidas após segundos.
- Você trabalha em uma **empresa de segurança cibernética**? Você quer ver sua **empresa anunciada no HackTricks**? ou quer ter acesso à **última versão do PEASS ou baixar o HackTricks em PDF**? Confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
- Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
- **Junte-se ao** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo do Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo do telegram**](https://t.me/peass) ou **siga-me** no **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
- **Compartilhe seus truques de hacking enviando PRs para o [repositório hacktricks](https://github.com/carlospolop/hacktricks) e [repositório hacktricks-cloud](https://github.com/carlospolop/hacktricks-cloud)**.
