É provável que o que está acontecendo é que o administrador de rede da rede de trabalho esteja bloqueando a saída TCP 22 da porta e a porta UDP 22 de saída, para bloquear o acesso SSH. Isso é feito para uma questão de segurança de dados sendo "enviados" da rede interna para um servidor que não é controlado pela organização. Isso também é feito como uma questão de política no local de trabalho.
Como profissional de segurança de TI, é meu dever NÃO fornecer respostas que comprometam a segurança do servidor compartilhado ou a segurança do local de trabalho, mas eu estou dando a você três opções aqui e identificando quais eu recomendo nas seções abaixo. Um viola a política do local de trabalho para a namorada provavelmente, e também diminui a segurança do seu servidor, os outros dois são potenciais outras opções.
Opção 1: experimente e execute um cliente de shell voltado para a Web ou defina sshd
para usar a porta 80.
NÃO RECOMENDADO
A única solução neste caso é executar algum tipo de cliente de shell voltado para a Web, mas é provável que você precise de um servidor da Web. A outra solução, proposta por Nitin J Mutkawoa de colocar seu servidor SSH na porta 80, é outra opção. Ambas as opções abrem vários riscos de segurança, incluindo, entre outros:
- Colocar o SSH em uma porta HTTP significa que MUITOS servidores podem tentar acessar uma página da web no endereço IP, mas em vez disso, atingirão uma conexão SSH, o que será um risco de segurança, pois os scanners de serviço veem isso.
- Colocar o que deve ser considerado um serviço "seguro" em uma porta da Web abrirá você para ataques baseados na Web contra a porta
- Colocar o SSH no sistema voltado para a web abrirá você para muitos vetores de ataque de força bruta.
- Colocar um cliente de shell baseado na Web voltado para a Web abrirá você também para tentativas de força bruta
- Colocar um cliente shell baseado na Web voltado para a web abrirá você para vetores de ataque de qualquer que seja o 'cliente' escrito (Java, PHP, etc.) que pode incluir, mas não está limitado a:
- Vulnerabilidades de execução remota de código
- Vulnerabilidades de escalonamento de privilégios
- Vulnerabilidades de negação de serviço.
Isso também abre a sua namorada a violações de políticas no local de trabalho, fazendo algo que a política do local de trabalho deve negar. Ela pode enfrentar medidas disciplinares até e inclusive ser demitida. Por esse motivo, além dos motivos de segurança acima, você não deve implementar essa opção.
Opção 2: Não tente contornar a política de TI no local de trabalho
RECOMENDADO
Como profissional de segurança de TI, que teve que encerrar o acesso à rede devido a violações de políticas de outros indivíduos em um local de trabalho no passado, minha recomendação é que sua namorada não tente e SSH em seu servidor compartilhado um ambiente de trabalho / rede . Se houver algum tipo de auditoria sendo realizada na rede, as auditorias de rede podem mostrar que alguém está tentando executar o SSH em um servidor não seguro e não-protegido. Embora você ou sua namorada possam individualmente não ter nenhuma intenção maliciosa, a maioria das "Políticas de Uso Aceitável de Rede / Computador" do local de trabalho incluirá que você não fará itens pessoais na rede sem autorização ou necessidade absoluta. Outra coisa é provável afirmar "Você não deve usar certos serviços, tais como: [lista]".
Eu recomendaria que você revisasse a política de uso aceitável do local de trabalho da namorada e determinasse se ela violaria essa política, o suficiente para que ela pudesse enfrentar medidas disciplinares, como remoção de acesso à rede, remoção de acesso ao computador, ou demissão em potencial. Não tente contornar a política, porque sua namorada pode ser demitida, contornando-a.
Opção 3: Se o SSH for necessário para tarefas relacionadas ao trabalho, entre em contato com supervisores / gerentes para ver se isenções de restrição podem ser dadas à namorada.
TAMBÉM RECOMENDADO
Se o acesso ao seu servidor SSH compartilhado for um requisito para o local de trabalho , sua namorada precisará conversar com seu supervisor para determinar se há uma violação da política permitindo o acesso como tal. Teria então de ser discutido pela gerência se eles podem ou não dar acesso, e então a partir daí determina se é seguro / são ou não permitir o acesso através da rede.
Esta é provavelmente a segunda opção mais segura