Respostas:
O motivo mais provável é dificultar as pessoas que tentam aleatoriamente fazer força bruta em qualquer login SSH que encontrarem. Minha máquina com acesso à Internet usa a porta SSH padrão e meus logs costumavam ser preenchidos com coisas como esta (extraídas de um arquivo de log real):
sshd[16359]: Invalid user test from 92.241.180.96
sshd[16428]: Invalid user oracle from 92.241.180.96
sshd[16496]: Invalid user backup from 92.241.180.96
sshd[16556]: Invalid user ftpuser from 92.241.180.96
sshd[16612]: Invalid user nagios from 92.241.180.96
sshd[16649]: Invalid user student from 92.241.180.96
sshd[16689]: Invalid user tomcat from 92.241.180.96
sshd[16713]: Invalid user test1 from 92.241.180.96
sshd[16742]: Invalid user test from 92.241.180.96
sshd[16746]: Invalid user cyrus from 92.241.180.96
sshd[16774]: Invalid user temp from 92.241.180.96
sshd[16790]: Invalid user postgres from 92.241.180.96
sshd[16806]: Invalid user samba from 92.241.180.96
Atualmente, eu uso o DenyHosts para bloquear IPs que não conseguem se autenticar muitas vezes, mas provavelmente é tão fácil trocar de porta; praticamente todos os ataques de força bruta desse tipo não incomodam a digitalização para ver se o seu sshd está escutando em outra porta, eles assumem que você não está executando uma e segue em frente
Não, é uma segurança por tática de obscuridade .
Se a sua configuração do sshd não for adequada o suficiente para enfrentar crianças idiotas de scripts tentando apenas a porta 22, você terá um problema.
Uma reação mais racional seria:
Algumas pessoas também podem se incomodar com o ruído que o sshd grava no log do sistema, por exemplo:
Jan 02 21:24:24 example.org sshd[28396]: Invalid user guest from 212.129.23.128
Jan 02 21:24:24 example.org sshd[28396]: input_userauth_request: invalid user guest [preauth]
Jan 02 21:24:24 example.org sshd[28396]: error: Received disconnect from 212.129.23.128: 3: com.jcraft.jsch.JSchException: Auth fail [preauth]
Jan 02 21:24:24 example.org sshd[28398]: Invalid user ubnt from 212.129.23.128
Jan 02 21:24:24 example.org sshd[28398]: input_userauth_request: invalid user ubnt [preauth]
Jan 02 21:24:24 example.org sshd[28398]: error: Received disconnect from 212.129.23.128: 3: com.jcraft.jsch.JSchException: Auth fail [preauth
Pode ser tentador obscurecer a porta sshd ou usar uma solução de bloqueio automático (como DenyHosts, Fail2ban ou BlockHosts) para aumentar novamente a taxa de sinal / ruído .
Mas existem melhores alternativas. Por exemplo, você pode configurar seu daemon syslog de modo que o ruído do log sshd seja gravado apenas para - digamos - /var/log/sshd-attempts.loge o sinal (ou seja, as restantes mensagens de log sshd) sejam gravados em /var/log/messagesetc., como antes.
A implantação de ferramentas de bloqueio automático deve ser considerada com cuidado, pois adicionar mais complexidade aos sistemas relevantes para segurança significa também aumentar o risco de exploração . E, de fato, ao longo dos anos, existem vários relatórios de vulnerabilidade de DoS para cada DenyHosts , Fail2ban e BlockHosts .
Alterar a porta SSH é principalmente um teatro de segurança . Dá a você uma sensação confusa de ter feito algo. Você ocultou a porta SSH sob o capacho.
Se você executar um servidor SSH na Internet, verá muitas tentativas de logon com falha em seus logs, de bots que procuram senhas estupidamente fracas, chaves fracas e explorações conhecidas nas versões mais antigas do servidor. As tentativas com falha são exatamente isso: tentativas com falha . Na avaliação de quão vulnerável você é, eles são completamente irrelevantes. Você precisa se preocupar com as tentativas bem-sucedidas de invasão e não as verá em seus logs.
Alterar a porta padrão reduzirá o número de acessos por esses bots, mas isso apenas evita os invasores menos sofisticados que são impedidos por uma segurança decente (atualizações de segurança aplicadas regularmente, senhas razoavelmente fortes ou autenticação de senha desativada). A única vantagem é reduzir o volume de logs. Se isso for um problema, considere algo como Denyhosts ou Fail2ban para limitar a taxa de conexão, mas também fará bem à sua largura de banda.
Alterar a porta padrão tem uma grande desvantagem: diminui a probabilidade de você fazer login por trás de um firewall. É mais provável que os firewalls deixem os serviços passarem em sua porta padrão do que em alguma outra porta aleatória. Se você não estiver executando um servidor HTTPS, considere também escutar o SSH na porta 443 (ou redirecione as solicitações TCP de entrada da porta 443 para a porta 22), pois alguns firewalls permitem o tráfego que eles não podem decodificar na porta 443 porque parece como HTTPS.