Deve funcionar bem, não é mais seguro do que usar uma porta diferente para o ssh (ou menos segura). E não, os soquetes TCP de saída não são os mesmos que os soquetes TCP de entrada - portanto, ele não deve interferir no tráfego de rede de saída.
Sou estudante e mantenho a maioria dos meus arquivos no meu computador pessoal. Infelizmente, não posso usar ssh ou scp do meu laptop que uso na escola por causa do firewall. Eu estava pensando em tentar usar a porta 443 porque isso pode ser aberto.
Minha pergunta é: eu tenho vários computadores em casa e por isso estou usando um roteador. Seria ruim se eu fosse portar 443 para o meu computador? Não tenho certeza se há algum problema de segurança relacionado a isso ou se ele estragaria tudo ao tentar usar https de meus outros computadores.
Se você vai fazer isso, no mínimo, por favor:
Você pode se abrir para o perigo de outra forma. E se alguém encontrar um bug de segurança que permita que eles efetuem login automaticamente quando receberem uma solicitação SSH? Sua lista de permissões reduzirá esse risco futuro.
Ao desabilitar os logins de senha para o SSH, se um ator mal-intencionado na lista de permissões conseguir acessar seu servidor, será muito mais difícil forçar o uso da força bruta.
Esta é uma boa higiene de segurança. Se você é um estudante universitário regular, as chances de ataque podem ser baixas, mas por que correr um risco desnecessário?
"HTTPS" é apenas um nome para o protocolo TLS (Transport Layer Security) quando está sendo usado para proteger o protocolo HTTP subjacente. Somente os pontos de extremidade precisam se preocupar com o protocolo subjacente, para que você possa enviar o tráfego desejado, desde que tenha estabelecido a conexão TLS segura, em qualquer porta disponível, sem ter que se preocupar com firewalls, hackers, espiões estrangeiros ou agências de segurança desonestos dentro do seu próprio país.
"SSH" tem seu próprio protocolo, portanto, se você executar ssh na porta 443, sempre haverá a possibilidade de um firewall ou outro agente de rastreamento detectar que o tráfego não é HTTPS (já que ele se desvia do TLS) e bloqueá-lo. A solução para este problema é envolver a sessão ssh dentro do protocolo TLS, o que é feito facilmente por meio do programa stunnel . No servidor, deixe stunnel ouvir na porta 443 e encapsulamento do tráfego para a porta 22. Em seguida, no cliente, você precisa executar outra instância do stunnel que ouve alguma porta local e depois encapsula o tráfego para a porta 443 no servidor.
Sem problemas, eu tive isso em 443 por um longo, longo tempo. Está bem. A única coisa é que você recebe estranhas entradas de log dos navegadores que tentam se conectar a ele, mas esses são completamente inofensivos.
Vale a pena mencionar que o aço é uma trapaça. Você pode usar 443 ou qualquer outra porta que você revelar, usando nmap ou alguma outra ferramenta, mas a conexão SSH foi proibida de propósito. Isso significa que você pode ser pego facilmente, já que não fará uma solicitação HTTPS, que é o tipo de protocolo que a porta acima mencionada geralmente fica em aberto.
Em geral, você pode acionar algum monitoramento fazendo isso. É uma violação de segurança e uma análise de pacote subseqüente mostrará informações abrangentes sobre essa tentativa. Apenas dizendo.
Tags ssh port-forwarding firewall