Eu tenho um servidor home do CentOS que uso para várias coisas, que fica na minha rede doméstica atrás do meu roteador. Normalmente, quando eu quero fazer algo remotamente eu vou VPN em (meu roteador tem uma função de servidor OpenVPN built-in que eu uso) e trabalhar a partir daí.
De qualquer forma, eu estava pensando em abrir a porta 22 em meu servidor para não precisar conectar primeiro com um cliente VPN. Eu tenho logins de senha desativados e conecto usando uma chave ssh.
Seria particularmente perigoso abrir a porta 22 para conexões SSH com a minha configuração, como descrevi? Eu sei que seria mais perigoso, mas eu não sou exatamente a NSA em que não há uma horda de pessoas ansiosas para entrar na minha rede, então estou apenas curioso sobre se o risco extra seria substancial.
Would it be particularly dangerous for me to open port 22 for SSH connections with my setup as I've described?
Não, tudo bem. Enquanto a senha auth estiver desativada, não se preocupe com isso.
Algumas pessoas preferem executar o SSH em uma porta não padrão. Isso não é muito uma medida de segurança, pois é uma maneira de reduzir o ruído em seus registros de autenticação, já que a grande maioria dos scripts de força bruta ssh só tenta se conectar à porta padrão.
Desde que seu sistema CentOS esteja atualizado sobre patches, ou seja, você não tem uma versão bastante antiga do sshd em execução no sistema, você deve estar bem. No que diz respeito ao seu comentário que "não há uma horda de pessoas apenas com vontade de entrar na minha rede", se você verifique as tentativas de conexão na porta 22 você pode se surpreender. Se você executar o SSH na porta padrão de 22, você deve esperar que todos os dias haja pessoas em todo o mundo tentando obter acesso ao seu sistema via SSH. Eu também tenho um servidor home do CentOS e vejo milhares de tentativas todos os dias; cerca de 14.000 tentativas de 109 endereços IP exclusivos nas últimas 12 horas. Quando eu verifico / var / log / secure, a maioria das tentativas são geralmente para um userid de root ou admin, apesar de eu ver tentativas de logins SSH para muitos outros userids também.
Quando eu também rodava um servidor FTP no sistema, eu monitorava os userids e as senhas usadas via KRIPP e pode-se ver ataques de dicionário todos os dias em que dicionários de nomes foram usados para userids e emparelhados com dicionários de inglês e comumente senhas usadas para senhas. Aqueles ocorriam diariamente e eu observava meia dúzia de sistemas em várias partes do mundo, por exemplo, Brasil, China, EUA, etc., conduzindo tais ataques de uma só vez.
Você não está permitindo o login de senhas, então não precisa se preocupar com qualquer conta no sistema que tenha uma senha fraca fornecer um ponto de entrada para o sistema para um invasor, mas você ainda deve estar ciente de que existem milhares de sistemas na Internet, varrendo vastos intervalos de IP em busca de um sistema vulnerável. Às vezes, eles estão procurando por um sistema com informações financeiras ou outras que possam explorar e outras vezes é para sistemas vulneráveis que podem ser usados como plataforma de lançamento para atacar outros sistemas, ocultando o verdadeiro ponto de origem para quaisquer atos nefastos que o invasor tenha planejado.
Se você tiver alguma coisa para proteger (o que parece lógico, considerando que você tem uma configuração de SSH baseada em chave e VPN configurada), proteja-a da melhor maneira possível. Mudar a porta reduz os ataques automatizados, então por que arriscar a chance quando é tão fácil de alterar e tão fácil de especificar ao conectar? Eu escolheria um ou outro (para reduzir os vetores de ataque) e usaria todos os meios possíveis para garantir a conexão com a qual você decide ficar. Ambos oferecem funcionalidade semelhante, então qual deles é mais fácil de usar?
Para uma configuração inicial, eu preferiria o SSH a uma máquina na rede da qual eu possa ramificar túneis. No que diz respeito à segurança, também coloco mais fé no SSH em uma caixa CentOS do que no OpenVPN em um roteador de varejo. Além disso, você não precisa se preocupar com a sua rede doméstica na mesma sub-rede de onde está se conectando, um problema comum de VPN.