Um caminho de gerenciamento baseado em Tor para o seu VPS

01Proteja a administração assim como o checkout

Pedir um servidor por meio de um navegador protegido não protege automaticamente uma sessão posterior de SSH. Um login direto pode revelar seu endereço de origem ao servidor e às redes ao longo do caminho. Decida como a administração funcionará antes da primeira conexão, incluindo acesso de emergência caso a rota preferida falhe.

Tor pode ocultar o IP direto do cliente do destino, mas não é um remédio para credenciais reutilizadas, dados de configuração identificáveis ou todos os ataques de correlação de tráfego. Também adiciona latência. O objetivo útil é um caminho de gerenciamento consistente cujo comportamento você entende e pode verificar.

02Comece com um cliente Tor local funcional

Um daemon Tor do sistema normalmente oferece SOCKS em 127.0.0.1:9050, enquanto o Tor Browser normalmente usa 9150. Verifique sua configuração real em vez de presumir qualquer uma das portas. O aplicativo deve enviar sua conexão por esse proxy; abrir o Tor Browser não roteia todos os programas do computador.

Em sistemas compatíveis, o torsocks envolve aplicativos como SSH e roteia chamadas de rede compatíveis por meio de Tor. Teste a configuração com um endereço de exemplo apenas para documentação substituído pelo endereço real do seu servidor. O comando a seguir pressupõe um daemon Tor do sistema em execução e uma conta administrativa dedicada.

torsocks ssh -i ~/.ssh/silentvps_ed25519 [email protected]

03Faça da rota parte da configuração do SSH

Para uso regular, uma configuração por host reduz a chance de esquecer um wrapper. O exemplo abaixo usa uma implementação de netcat com suporte a proxy SOCKS5. As implementações diferem, então confirme as opções -x e -X na sua versão instalada e verifique se a resolução de nomes de host é remota.

IdentitiesOnly limita as chaves oferecidas ao servidor; combine-a com uma chave nova usada para este projeto. Verifique e retenha a impressão digital da chave de host do servidor por meio de um canal de provisionamento confiável. Tor altera o caminho de rede, mas a autenticação de host SSH ainda é essencial.

Host silent-admin
    HostName 203.0.113.45
    User admin
    IdentityFile ~/.ssh/silentvps_ed25519
    IdentitiesOnly yes
    ProxyCommand nc -X 5 -x 127.0.0.1:9050 %h %p

04Mova SSH para trás de um serviço onion

Um endpoint onion permite administração sem uma porta SSH publicamente acessível e evita usar uma saída Tor para essa conexão. Instale e configure Tor no servidor, depois mapeie uma porta virtual onion para o serviço SSH local. O exemplo é uma configuração inicial; caminhos de serviço e comandos variam conforme a distribuição.

Depois que Tor criar o diretório de serviço, recupere seu arquivo de hostname de forma privada e teste uma conexão por meio do proxy do seu cliente. Mantenha as chaves de identidade do serviço onion privadas. Somente após um login independente bem-sucedido você deve restringir SSH ao localhost e remover o acesso público. Verifique se o seu console de recuperação funciona antes de fazer essa alteração.

HiddenServiceDir /var/lib/tor/silent-admin/
HiddenServicePort 22 127.0.0.1:22

05Adicione autorização de cliente para um endpoint privado

Sem autorização extra, qualquer pessoa que descubra o endereço onion pode alcançar o serviço e seu SSH prompt. Tor v3 autorização de cliente adiciona um portão criptográfico separado: o serviço tem a chave pública do cliente autorizado e o cliente possui a chave privada correspondente.

Siga as instruções atuais do Projeto Tor para formatos de chave e o diretório authorized_clients. Verifique se um cliente não autorizado não consegue se conectar. Mantenha também a autenticação por chave SSH e planeje como revogar a autorização de um dispositivo perdido sem perder seu próprio acesso restante.

06Teste DNS e evite vazamento de identidade

Uma consulta de nome de host feita pelo resolvedor local pode revelar seu alvo antes que a conexão chegue ao proxy. Usar o IP do servidor para um destino clearnet evita essa consulta específica; nomes onion exigem resolução dentro do Tor. Para outros nomes de host, confirme o comportamento de DNS remoto da aplicação em vez de confiar em uma configuração genérica de proxy.

O sistema convidado ainda pode manter carimbos de data e hora de autenticação, nomes de usuário e entradas de diário. Revise sua retenção intencionalmente em vez de desativar cegamente todos os diagnósticos. Inspecione também nomes de host locais, metadados de commit e configuração copiada em busca de detalhes identificadores. Tor não remove esses elementos do tráfego da aplicação.

• Use uma chave dedicada e um fluxo de trabalho de projeto isolado.
• Verifique a porta SOCKS esperada e o comportamento de DNS remoto.
• Mantenha o acesso de recuperação e um segundo login testado antes de alterar os listeners.
• Revise o serviço Tor e SSH após atualizações.
• Nunca compartilhe as chaves de identidade onion ou segredos de autorização de cliente.

07Mantenha sessões longas e manutenção futura prática

Execute tarefas administrativas longas dentro do tmux ou screen para que uma interrupção de conexão não destrua a sessão. Circuitos Tor e condições de rede podem mudar, então mantenha os comandos repetíveis e entenda como retomá-los. Um pouco de latência extra é mais fácil de tolerar quando a manutenção é planejada.

O mesmo padrão onion pode servir de front para um painel local ou serviço Git privado. Cada aplicação ainda precisa de autenticação, atualizações de software e configuração cuidadosa. Continue usando a rota protegida para suporte, renovação e backups onde seus requisitos de privacidade exigirem; a consistência importa tanto quanto a configuração inicial.