Sim, existem diferenças quando localhost
e myserver.com
resolvem endereços diferentes (máquinas diferentes).
Como seus exemplos usam a porta 22
, que é uma porta padrão para SSH, alterei esse número para 222
em minha resposta. O objetivo é informar a diferença entre a conexão SSH da operadora (para a porta 22
por padrão) e o destino do túnel SSH.
The result seems to be the same for both of them.
Para deixar claro para os futuros leitores: os dois comandos fazem com que os dados que entram em localhost:2222
vão para o processo que escuta na porta 222
( 22
na pergunta original) na máquina myserver.com
. Estamos falando de portas TCP aqui.
1.
ssh -f -L 2222:myserver.com:222 localhost -N
Com este comando
- você precisa de acesso SSH ao
localhost
; - a conexão SSH é local, portanto, qualquer criptografia fornecida é apenas um trabalho computacional desnecessário;
- o servidor SSH transmite os dados para o remoto
myserver.com:222
exatamente quando entra na porta local2222
, então não há criptografia adicional neste estágio (os dados que entram na porta local2222
pode ou não ser criptografado de antemão, isso é independente); -
myserver.com
vê a conexão com sua porta222
como proveniente do exterior (de seu host local que não é deleslocalhost
), então a porta222
não deve ser bloqueada pelo firewall lá .
Se você fizer sua conexão diretamente com myserver.com:222
em vez de localhost:2222
, o resultado deverá ser o mesmo porque myserver.com
não indicará a diferença. É por isso que considero este primeiro comando quase inútil. (Por que "quase"? - Vou explicar no final.)
2.
ssh -f -L 2222:localhost:222 myserver.com -N
Neste caso
- você precisa de acesso SSH a
myserver.com
; - a conexão SSH vai para outra máquina, todos os dados são criptografados neste estágio ;
- o servidor SSH descriptografa os dados encapsulados e os transmite para seu próprio
localhost
, ou seja, localmente na mesma máquina; -
myserver.com
vê a conexão à sua porta222
como proveniente de si mesma (localmente) e isso deve passar pelo firewall porque é incomum bloquear conexões locais; o processo de escuta pode até ouvir apenas na interface de loopback.
Está bem claro para mim que este segundo comando é o superior.
Um cenário em que o primeiro comando pode ser útil: se outro (terceiro) computador precisar acessar myserver.com:222
e não tiver rota, conectando-se à porta 2222
de seu host local (que não é seu localhost
) pode ser uma solução. Observe que isso exige a opção -g
para o comando ssh
(consulte man ssh
para saber mais). Você pode usar qualquer um dos dois comandos para essa finalidade, mas se você não tiver acesso SSH a myserver.com
, o segundo comando não funcionará.
Bem, pode-se construir um túnel inteiramente a partir do terceiro computador. O comando seria:
ssh -f -L 2222:myserver.com:222 ssh-server -N
# then connect to their own localhost:2222
Obviamente, isso requer acesso SSH a ssh-server
(seu localhost
). Mas vamos supor que o terceiro computador pertence ao seu amigo sem acesso SSH a ssh-server
. Você (com o acesso) pode construir o túnel para eles com o primeiro comando e a opção -g
. Eles devem se conectar a ssh-server:2222
então.