ssh da casa para a máquina por trás do firewall

Question

Semi-novato, então lança-chamas para "chamuscar apenas" por favor. ; -)

Eu tenho a máquina A no trabalho, que gostaria de usar SSH em uma máquina em casa (chame a máquina B) - a máquina A está atrás do nosso firewall corporativo, que tem apenas a porta 22 e a porta 80 abertas. Na máquina Do lado de algumas coisas, eu quero mudar a porta para SSH na máquina A de 22 para (digamos) 2200, para minimizar o número de script kiddies martelando na porta 22 (eu tenho outras políticas de endurecimento de SSH no lugar, mas gostaria de adicionar movendo a porta SSH padrão de 22 para (digamos) 2200. Isso é bastante fácil dentro da configuração SSHD, mas isso mata qualquer coisa de entrada desde a porta 2200 está bloqueada na borda.

Então, algum tipo de opção de encaminhamento / encapsulamento. Eu tentei algumas permutações tanto na máquina A quanto na máquina B, mas não encontrei a combinação mágica. Eu estava esperando que um dos tipos mais aprendidos neste fórum pudesse aconselhar:

1 \ o que eu preciso configurar para encaminhamento / configuração de porta na máquina A?

2 \ em termos de estabelecer o túnel a partir da máquina B, qual é a estrutura básica de comando SSH que preciso tentar?

Pedimos desculpas antecipadamente pelo nível extremamente "básico" das perguntas (e, se tiverem sido respondidas antes, peço desculpas novamente, porque as respostas que encontrei não eram totalmente acessíveis a alguém no meu nível).

Muito obrigado antecipadamente.

    

Answer 1

O seu firewall corporativo permite apenas as portas 22 e 80 ... então você só pode executar serviços nas portas 22 e 80. Se você quiser estabelecer o encaminhamento de porta através do ssh para acessar portas inacessíveis, primeiro você precisa se conectar ao remoto host, o que você não pode fazer a menos que seja capaz de atravessar o firewall corporativo.

Em outras palavras, você terá que deixar o ssh rodando na porta 22. Sua melhor aposta, se você está preocupado com as criativas escrituras, é simplesmente desabilitar a autenticação por senha e sempre usar as chaves ssh. Isso tornará o sistema amplamente invulnerável a ataques de força bruta baseados em senha. Obviamente, não ajuda se alguém descobrir algum tipo de vulnerabilidade ssh que possa ser explorada antes da autenticação, mas é provavelmente o melhor que você vai conseguir na sua situação.

    

Answer 2

Se o buraco no firewall estiver no TCP / 22, então algo tem que estar no TCP / 22 para escutar as conexões. Esse pode ser o seu processo sshd ou outra coisa. No entanto, se você quiser mergulhar na porta sem ter que bater na porta primeiro, você está praticamente preso a ter o ssd ouvindo no TCP / 22.

Outra opção é usar um script de porta-aldrava de algum tipo. Eu não usei isso antes, só sei que eles estão por aí. Tenha um serviço escutando no TCP / 22. Quando recebe a string mágica correta, ela descarrega-se e traz o SSHD em TCP / 22 por X minutos. Quando o processo do SSH fecha, o ouvinte da porta reaparece no TCP / 22 e aguarda a próxima batida na porta.

Mas, no final, a proteção do SSH deve ser boa o suficiente. Confie na chave pública e desabilite a senha auth e tudo o que o scriptkiddiez pode fazer é preencher seus arquivos de log. Barulhento, mas o tipo inofensivo.

    

Answer 3

Faça um túnel do trabalho para casa e faça um túnel que permita a conexão de casa.

A está no trabalho, B está em casa. Você deseja se conectar de B a A, mas o firewall o bloqueia. Em vez disso, conecte-se de A a B, criando um túnel de volta ao servidor. Isso pressupõe que você tenha um servidor ssh em execução em casa e tenha aberto a porta 22 em seu roteador. Se a sua máquina doméstica for Mac ou Linux, você provavelmente a executará; se windows, instale o cygwin e configure o sshd (link) .

No trabalho, coloque isso no seu arquivo .ssh / config:

host home
 hostname B      # replace with your FQDN or IP
 user homeuser   # user at home
 LocalForward 2222 localhost:22

Agora, quando você executar 'ssh home', a porta 2222 será um túnel para o servidor ssh da sua máquina local. Eu acho que se você deixar essa sessão em uma janela, a conexão pode ficar suspensa ocasionalmente, ou a filewall pode fechá-la depois de um tempo. Eu prefiro usar um comando como

while true; do ssh -n home sleep 600; sleep 3000; done &

Isso iniciará um túnel que dura dez minutos, fecha e inicia outro na próxima hora. Se houver conexões em túnel, quando o período de suspensão terminar, o comando ssh aguardará a conclusão. (dormir 3000 não é necessário; você pode mantê-lo aberto o tempo todo, é apenas algumas empresas não gostam de ver conexões persistentes freqüentes ou de longa duração para máquinas externas)

Agora, no lado da casa, coloque isso no seu arquivo .ssh / config:

host worktunnel
 hostname localhost
 user     workuser
 port     2222
 UserKnownHostsFile ~/.ssh/known_hosts.worktunnel

Salve e, quando o túnel estiver em sua máquina, você pode simplesmente digitar

ssh worktunnel

e você está dentro.

A linha UserKnownHostsFile não é necessária, mas impede avisos quando você usa vários túneis com portas diferentes para hosts diferentes, portanto, a entrada localhost no arquivo known_hosts padrão não corresponderá a todos os hosts.

Você pode adicionar várias linhas LocalForward ao arquivo de configuração em A; por exemplo.     LocalForward 2223 server2: 22 # outro servidor com ssh     LocalForward 5900 qa: 5900 # vnc     LocalForward 3389 troca: 3389 # área de trabalho remota     LocalForward 3128 internalProxy: 3128 # para navegar por hosts internos     # etc.

(Para conexões X de tunelamento, use 'ssh -X', não LocalForward.)

Nenhuma alteração dos números de porta do servidor ssh é necessária aqui.

Observe que esse tipo de acesso remoto pode ser contra as políticas da sua empresa. Alguns locais examinam ou auditam esse tipo de conexão e podem lhe dar um aviso sobre isso. Você pode executar o comando do túnel por cinco minutos, dormir por 55; ou ter um script na máquina doméstica que sai imediatamente quando você não precisa do túnel. Logmein é outra solução gratuita que funciona bem para permitir acesso remoto a desktops (windows, mac) por trás de firewalls

    

Answer 4

As outras respostas cobrem isso muito bem, mas eu queria mencionar que você poderia usar denyhosts na máquina A para reduzir o exposição bot. Os logs denyhosts tentaram solicitações ssh e, se uma máquina externa falhar muitas vezes, ela bloqueia o endereço IP vi /etc/hosts.deny. Assim, por exemplo, um bot que tenta ssh enquanto os usuários bobam 100 vezes será permanentemente bloqueado após a quinta tentativa falhada (todos esses parâmetros são ajustáveis).

Você também deve seguir boas práticas de segurança do servidor ssh, que eu tenho certeza que estão cobertas em outras respostas do serverfault. Desativar logins para root. Desativar logins para todos, mas um número muito pequeno de outros usuários autorizados. Desabilite logins de senha e permita somente conexões ssh de chave pública.