O que você fez

Você usou três comandos ssh:

1. Enquanto dentro de um console B você fez:

   ssh -4 -N -f -R 18822:localhost:22 <user>@<vps>
   

   Comando sshd (o servidor) para abrir port 18822, uma porta remotavps:18822 conectada ao localhost (B) porta 22.

2. Enquanto em um console vps você fez:

   ssh -g -f -N -L 0.0.0.0:18888:localhost:18822 <user>@localhost
   

   Comando ssh (o cliente) para abrir a porta 18888disponível como uma porta externa ( 0.0.0.0) em ( vps) que se conecta à porta interna 18822.

   Isso abre uma porta visível na Internet vps:18888que redireciona o tráfego para o 18822qual, por sua vez, redireciona para B:22.

3. Enquanto estiver em um console A (e a única conexão em que A participa):

   Conecte-se do Cliente A diretamente ao Cliente B em vps:18888.

O que importa é essa última conexão.
Toda a segurança SSH depende da autenticação de A para B .

O que significa

O protocolo SSH

O SSH fornece um canal seguro em uma rede não segura

Usando criptografia de ponta a ponta

A criptografia de ponta a ponta (E2EE) é um sistema de comunicação onde apenas os usuários em comunicação podem ler as mensagens. Em princípio, ele evita que potenciais bisbilhoteiros – incluindo provedores de telecomunicações, provedores de Internet e até mesmo o provedor do serviço de comunicação – possam acessar as chaves criptográficas necessárias para descriptografar a conversa.

A criptografia de ponta a ponta é um conceito. SSH é um protocolo. O SSH implementa criptografia de ponta a ponta. Assim como https, ou qualquer outro número de protocolos com criptografia.

Se o protocolo for forte e a implementação estiver correta, as únicas partes que conhecem as chaves de criptografia são as duas partes autenticadas (final).

Não conhecendo as chaves e não podendo quebrar a segurança do protocolo, qualquer outra parte é excluída do conteúdo da comunicação.

Se , como você descreve: do Cliente A diretamente para o Cliente B , você está autenticando diretamente no sistema B, então , apenas o Cliente A e o cliente B possuem as chaves. Nenhum outro.

Q1

Caso A: O próprio VPS não é alterado, mas o tráfego e os arquivos são monitorados completamente.

Apenas o fato de que uma comunicação (dia, hora, IPs finais, etc.) está ocorrendo e que alguma quantidade de tráfego (kbytes, MBytes) pode ser monitorada, mas não o conteúdo real do que foi comunicado.

Q2

Caso B: O VPS está completamente comprometido, o conteúdo do sistema de arquivos pode ser alterado.

Não importa, mesmo que a comunicação seja redirecionada através de alguns outros sites/locais, as únicas duas partes que conhecem as chaves são A e B. Ou seja: Se a autenticação no início da comunicação foi entre A e B.

Opcionalmente, verifique a validade do IP ao qual A está se conectando, então: use autenticação de chave pública (use apenas uma vez um par de chaves privada-pública que apenas A e B conhecem), feito.

Entenda que você deve garantir que a chave pública utilizada seja transportada com segurança para o sistema B. Você não pode confiar no mesmo canal para transportar as chaves e depois carregar a criptografia. Existem ataques Man-in-the-middle que podem quebrar o protocolo .

Q3

Se eu agora enviar um arquivo do Cliente A para o Cliente B por SFTP, seria possível para a empresa que hospeda o VPS "interceptar" e ler o conteúdo do arquivo (não criptografado)?

Não, se as chaves públicas foram colocadas com segurança em ambas as extremidades, há uma probabilidade muito pequena de que isso aconteça.

Ande com o disco com a chave pública do outro lado para instalá-lo, nunca mais se preocupe.

Comente

Do seu comentário:

Q1

Então, basicamente, o VPS na minha configuração não faz nada além de encaminhar as portas e não está envolvido na conexão SSH real ou na autenticação acontecendo do Cliente A para o B, correto?

Tipo de. Sim, o VPS não deve estar envolvido na autenticação. Mas é "In-The-Middle", ou seja, recebe pacotes de um lado e os entrega (se estiver funcionando corretamente) para o outro lado. Mas há uma alternativa, o VPS (ou qualquer coisa no meio) pode optar por mentir e realizar um "ataque do homem no meio" . Poderia mentir para o Cliente-A fingindo ser o Cliente-B e mentir para o Cliente-B fingindo ser o Cliente-A. Isso revelaria tudo dentro da comunicação com o "Man-In-The-Middle". É por isso que enfatizo a palavra deveria acima.

Devo dizer também que :

...não há ferramentas implementando MITM em uma conexão SSH autenticada usando o método de chave pública...

A autenticação baseada em senha não é o método de chave pública.

Se você se autenticar com uma senha, poderá estar sujeito a um ataque man-in-the-middle. Existem várias outras alternativas, mas estão fora do escopo deste post.

Basicamente, use ssh-keygen para gerar um par de chaves (vamos supor no lado A) e (para segurança correta) carregue a parte pública dentro de um disco para o lado B e instale-a no arquivo Authorized-keys. Não use a rede para instalar a chave pública, ou seja: não use o ssh-copy-id pela rede a menos que você realmente saiba exatamente o que está fazendo e seja capaz de verificar a identidade do lado B. Você precisa ser um especialista para fazer isso com segurança.

Q2

Sobre a chave pública, porém, não é, bem, pública?

• Sim, é público.
  Bem, sim, a entidade que gerou o par público-privado poderia publicar a parte pública para qualquer um (todos) e não perderia nenhum segredo. Se alguém criptografar apenas com sua chave pública, poderia descriptografar qualquer mensagem com a chave privada correspondente (e secreta).

• Criptografia SSH.
  A propósito, a criptografia SSH é simétrica e não assimétrica (pública). A autenticação é assimétrica (seja DH ( Diffie-Hellman ) (para senhas) ou RSA, DSA, Ed25519 Key Strength ou outros (para chaves públicas)), então uma chave simétrica é gerada a partir dessa autenticação e usada como chave de criptografia de comunicação.

• Usado para autenticação.
  Mas para o SSH, a chave pública (gerada com ssh-keygen) carrega um segredo adicional: ela autentica o dono da chave pública.

  Se você receber uma chave pública da Internet: Como você sabe a quem ela pertence? Você confia no que a chave pública afirma ser? Você não deveria !!

  É por isso que você deve levar o arquivo de chave pública para o servidor remoto (de forma segura) e instalá-lo lá. Depois disso, você pode confiar nessa chave pública (já verificada) como um método para autenticá-lo para fazer login nesse servidor.

Q3

Eu me conectei do VPS, principalmente para teste, ao Cliente B antes também, isso já não troca a chave pública?

Ele troca um conjunto de chaves públicas (um conjunto de chaves públicas geradas por DH) usadas para criptografia. Não a chave pública de autenticação gerada com ssh-keygen. A chave usada nessa comunicação é apagada e esquecida assim que a comunicação é encerrada.

Bem, você também aceitou (e usou) uma chave para autenticar o IP do servidor remoto. Garantir que um IP seja seguro é ainda mais complexo do que uma simples autenticação de chave pública ( ?? ).

Minha impressão foi que a chave pública pode ser compartilhada, mas a chave privada ou senha deve ser mantida em segurança.

E sua impressão (geral) está correta, mas o diabo está nos detalhes...

Quem gerou um par de chaves poderia publicar sua chave pública sem qualquer diminuição de sua segurança.

Quem recebe uma chave pública deve confirmar de forma independente que a chave pública pertence a quem acredita que ela pertence.

Caso contrário, o receptor de uma chave pública pode estar se comunicando com um parceiro maligno.

Gere sua chave

Se você usar ssh para conectar A a C e depois C a B, então não é de ponta a ponta. É extremidade para C, e C para outra extremidade. C pode ver o que está sendo transmitido.

Para criptografia de ponta a ponta, você precisa de ssh para conectar as duas extremidades. Não importa o que você passa.

Se as duas extremidades não puderem ver uma à outra, mas puderem ver C, você poderá configurar as conexões (seguras ou não) A—C e B—C. Em seguida, use ssh para fazer uma conexão segura A—B.