Há algum desenvolvimento que preciso fazer em alguma caixa remota. Felizmente, tenho acesso ao shell, mas preciso passar por um gateway que tenha AllowTcpForwarding definido como falso.
Dei uma olhada nos documentos e diz:
AllowTcpForwarding Especifica se o encaminhamento de TCP é permitido. O padrão é ''sim''. Observe que desabilitar o encaminhamento de TCP não melhora a segurança, a menos que os usuários também tenham acesso negado ao shell, pois eles sempre podem instalar seus próprios encaminhadores.
Como eu instalaria (ou construiria) meu próprio encaminhador? Meu objetivo aqui é configurar umintérprete remoto usando Pycharmvia SSH e vinculando-o a alguma porta local, os dados alimentados através do ssh, através do gateway e, em seguida, para a caixa de desenvolvimento onde o código é realmente executado. Imagino que poderia de alguma forma utilizar o nc ou algum outro utilitário unix que ajudaria a realizar o trabalho.
Eu sei que posso fazer ssh para minha caixa remota fazendo:
ssh -t user1@gateway ssh user2@devbox
Mas obviamente esta opção não está disponível no pycharm. Terei que ser capaz de abrir alguma porta local tal que
ssh -p 12345 localhost
(or variant)
irá me conectar a user2@devbox. Isso me permitirá configurar o intérprete remoto para usar a porta 12345
ativada localhost
para conectar-se à caixa remota.
Responder1
Contanto que alguém possa executarsocat
localmente e on gateway
(ou mesmo apenas bash
e cat
on gateway
, veja o último exemplo!) e tem permissão paranãouse um pty para ficar 8bits limpo, é possível estabelecer um túnel através do ssh. Aqui estão 4 exemplos, melhorando o anterior:
Exemplo básico funcionando uma vez
(ter um fork exigiria uma conexão ssh por túnel, o que não é bom). Ter que escapar do :
for socat para aceitar o comando exec:
- termo1:
$ socat tcp-listen:12345,reuseaddr exec:'ssh user1@gateway exec socat - tcp\:devbox\:22',nofork
- termo2:
$ ssh -p 12345 user2@localhost
- termo1:
user1@gateway's password:
- termo2:
user2@localhost's password:
A inversão do primeiro e do segundo endereço torna o soquete imediatamente disponível
socat
tem que ficar no comando, então não nofork
:
- termo1:
$ socat exec:'ssh user1@gateway exec socat - tcp\:devbox\:22' tcp-listen:12345,reuseaddr user1@gateway's password:
- termo2:
$ ssh -p 12345 user2@localhost user2@localhost's password:
Usando umControlMaster
ssh
Apermite bifurcar usando apenas uma única conexão SSH com o gateway, proporcionando assim um comportamento semelhante ao encaminhamento de porta normal:
- termo1:
$ ssh -N -o ControlMaster=yes -o ControlPath=~/mysshcontrolsocket user1@gateway user1@gateway's password:
- termo2:
$ socat tcp-listen:12345,reuseaddr,fork exec:'ssh -o ControlPath=~/mysshcontrolsocket user1@gateway exec socat - tcp\:devbox\:22'
- termo3:
$ ssh -p 12345 user2@localhost user2@localhost's password:
Tendo apenas bash
e cat
disponível emgateway
Usandobash
redirecionamento tcp integrado, e dois cat
comandos half-duplex (para um resultado full-duplex), nem é necessário um comando remoto socat
ou netcat
. O tratamento de múltiplas camadas de aspas aninhadas e de escape foi um pouco estranho e talvez possa ser feito melhor ou simplificado pelo uso de um bash
script remoto. Deve-se tomar cuidado para que o fork seja cat
apenas para saída:
- termo1 (sem alteração):
$ ssh -N -o ControlMaster=yes -o ControlPath=~/mysshcontrolsocket user1@gateway user1@gateway's password:
- termo2:
$ socat tcp-listen:12345,reuseaddr,fork 'exec:ssh -T -o ControlPath=~/mysshcontrolsocket user1@gateway '\''exec bash -c \'\''"exec 2>/dev/null 8<>/dev/tcp/devbox/22; cat <&8 & cat >&8"\'\'\'
- termo3:
$ ssh -p 12345 user2@localhost user2@localhost's password:
Responder2
Substitua ProxyJump por Bash
A ideia acima é boa! Aqui está minha versão genérica do ssh_config quandoProxy Jumpnão está funcionandoporquePermitirEncaminhamentoTcpdefinido como não e meu shell padrão é BASH:
ProxyCommand=ssh -T user1@gateway "exec 3<>/dev/tcp/%h/%p 2<&- ; cat <&3 & cat >&3 ; kill $!"
- -TDesabilitar alocação de pseudoterminal
- executivoNenhum novo processo (bash) será criado
- 3<>é simplesmente redirecionamento para um descritor de arquivo disponível
- /dev/tcp/...pedirá ao bash para abrir o soquete TCP correspondente.
- %he%pserá avaliado pelo seu cliente OpenSSH comocaixa de desenvolvimentoe22
- 2<&-fechará o STDERR (você também pode redirecioná-lo para/dev/null)
- gato <&3 &irá ler o descritor de arquivo selecionado 3 em segundo plano
- gato >&3escreveremos nosso descritor de arquivo em primeiro plano
- matar $!vai matar a "leitura"gato <&3comando em execução em segundo plano quando você fecha/interrompe a conexão. Caso contrário, ele continuaria funcionando.
Ele poderia substituir o ProxyJump para mim em situações em que estivesse desabilitado no servidor de salto, mas eu realmente não queria encaminhar minha chave privada para lá ou inserir senhas sem um nível extra de criptografia. Usar outros SSH_AUTH_SOCK como root ou gravar sessões de terminal completamente com pressionamentos de tecla são coisas reais.
Mas por favor, certifique-se sempre de não violar nenhuma política que se aplique a você!
Responder3
Ah não, quase esquecemos o Netcat!
Se houver Netcat (qualquer versão) em seu host de salto, você poderá usá-lo em vez de ProxyJump em sua configuração, geralmente como:
ProxyCommand=ssh -T user1@gateway "exec nc %h %p"
Ou na linha de comando:
ssh user2@devbox -oProxyCommand="ssh -T user1@gateway 'exec nc devbox 22'"
Responder4
Eu apenas configuraria outro sshd para rodar em uma porta diferente.
Edite as configurações para que o encaminhamento de tcp seja permitido.
cp /etc/ssh/sshd{,-second}_config
Editar sshd-second_config
Port 22220
cp /usr/lib/systemd/system/sshd.service /etc/systemd/system/sshd-second.service
Altere /etc/systemd/system/sshd-second.service da seguinte maneira:
Description=OpenSSH server second instance daemon
ExecStart=/usr/sbin/sshd -D -f /etc/ssh/sshd-second_config $OPTIONS
A linha ExecStart pode ser diferente, dependendo da versão.
systemctl daemon-reload
systemctl enable sshd-second.service --now
Mais informações podem ser encontradas aqui:
https://access.redhat.com/solutions/1166283
Agora você deve poder encaminhar o que quiser.