Estou tentando tornar possível controlar um shell em uma caixa linux atrás de um roteador que não está sob meu controle.
Minha primeira idéia foi transformar o cliente (a caixa atrás do roteador) em ssh para um servidor sob meu controle e encaminhar a porta ssh local, periodicamente do cron, assim:
client$ ssh -L 40000:localhost:22 root@server
Funciona com meu servidor privado e menos seguro, mas falha com o servidor de clientes, que é um CentOS, 2.6.24.5-grsec-xxxx-grs-ipv4-32 ([email protected]) ). Eu não sei nada sobre segurança e particularmente não sobre como ele está configurado neste servidor. A opção AllowTCPForwarding é sshd_config está em seu padrão, que é supostamente (como de RTFM) 'yes', e ssh -v me diz
debug1: Local connections to LOCALHOST:40000 forwarded to remote address localhost:22
debug1: Local forwarding listening on 127.0.0.1 port 40000.
mas tudo o que eu recebo ao tentar ssh de volta ao cliente deste servidor é 'Conexão recusada'.
Próxima ideia:
No cliente:
client$ bash -i <in >out 2>err &
client$ ssh root@server 'cat <client.in' >in &
client$ ssh root@server 'cat >client.out' <out &
client$ ssh root@server 'cat >client.err' <err &
No servidor:
server# cat client.out &
server# cat client.err &
server# cat >client.in
ls
Todos esses, {client.,} {in, out, err}, são pipes nomeados, feitos com mkfifo. Mas de alguma forma o ssh não funciona dessa maneira para mim, nada chega a acabar. Isso funciona parcialmente com arquivos normais (não pipes nomeados) e tail -f. Mas tenho a sensação de que não é assim que você faz isso. E as preocupações sobre os arquivos simples ficarem muito grandes, e sobrescrevendo ... isso simplesmente não parece bonito.
Alguma ideia? Eu tenho root no servidor de clientes, mas preferiria não instalar os kernels e causar estragos.
UPDATE
Esclarecimento: A caixa do cliente será instalada pelo cliente em algum local distante por trás de um roteador, do qual nem eu nem o cliente tenha controle. Portanto, nenhum encaminhamento de porta ou DNS dinâmico no roteador. Apenas uma simples caixa linux com um IP privado em algum lugar da rede. A primeira ideia que imaginei funcionaria com um servidor menos seguro que o servidor do cliente. Eu tenho que usar o que é grsecured. Eu sou capaz de ssh do servidor de clientes para outros locais, por isso não é um problema iptables. Eu também sou capaz de abrir portas de escuta (com nc -l) e conectar-se a elas.
Estou conectando do cliente por trás de um roteador para o servidor, encaminhando alguma porta de servidor alta (por exemplo, 40000) para a porta ssh no cliente, para que eu possa primeiro ssh de casa para o servidor e depois ssh do servidor para o cliente. Como eu disse, o cliente não está na minha rede e está atrás de um roteador que não está sob meu controle.
Eu não estou ssh'ing de volta para casa, o cliente não é a máquina Eu começo esta jornada maravilhosa de. Casa, servidor e cliente estão em três redes distintas.
Acho que você está fazendo o túnel SSH da maneira errada, então você está efetivamente tunelando a partir do cliente que está tentando acessar o servidor aberto, em vez do contrário. Você não poderá usar o -L, pois não poderá se conectar ao cliente para estabelecer o túnel.
O caminho a seguir, se o GatewayPorts estiver em sshd_config no servidor sob seu controle, é usar um túnel reverso, por exemplo:
ssh -N -R 40000:localhost:22 user@server_under_your_control
Apenas um pensamento sobre a sua primeira solução: você verificou IPTABLES não está bloqueando suas conexões? Talvez você só precise permitir esse tráfego no firewall do sistema.
O que James disse funciona perfeitamente com IP estático . se ele não tiver um, ele deve usar um serviço (digamos dyndns ) que indicará seu ip a cada vez.
Como exemplo, ssh -R blahblah user@thisIsMyIp
Então você deve fazer um script que irá verificar se a conexão está ativa, e se não estiver, você deve executar o comando acima
Você pode querer que a porta ssh encaminhe a outra direção. A saber:
client# ssh -R 40000:localhost:22 clientLogin@yourServer
Com algumas chaves SSH e outros, além de um wrapper para reiniciá-lo, caso ele seja descartado. Isso permitirá que você use o SSH em yourServer:40000 e obtenha um shell em client .