assegurando o SSH e desabilitando a raiz direta

Question

Nestas instruções abaixo, o que aparece no meu terminal é diferente, por isso não tenho a certeza do que devo mudar. Após a porta 22 o meu diz #AddressFamily any e mais abaixo no protocolo ele tem uma linha mais longa dizendo #ativação do protocolo 1 e depois na linha abaixo do Protocolo 2 sem comentário. Além disso, se você desabilitar o login root direto, você usa o sudo com a mesma senha criada para o root?

Desça até a seção do arquivo que se parece com isso:

#Port 22
#Protocol 2, 1
#ListenAddress 0.0.0.0
#ListenAddress ::

Remova o comentário e altere

#Port 22 
to look like 
Port 5678 (choose your own 4 to 5 digit port number (49151 is the highest port number AND do not use 5678  lol )

Uncomment and change 
#Protocol 2, 1
to look like 
Protocol 2

Uncomment and change 
#ListenAddress 0.0.0.0
to look like 
ListenAddress 123.123.123.15 (use one of your own IP Addresses that has been assigned to your server)

Nota 1: Se você quiser desabilitar o Login direto da raiz, role para baixo até encontrar

#PermitRootLogin yes
and uncomment it and make it look like 
PermitRootLogin no

enquanto o meu é isso:

#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

# Disable legacy (protocol version 1) support in the server for new
# installations. In future the default will change to require explicit
# activation of protocol 1
Protocol 2

argh você tem que fazer um curso online apenas para trabalhar neste fórum: /

    

Answer 1

O OpenSSH segue a política "padrões comentados" . Isso significa que o arquivo de configuração (em todo o sistema) contém a maioria das opções disponíveis que - se não comentadas - teriam o mesmo valor que os padrões do aplicativo que estão conectados aos binários executáveis reais. Desde há algum tempo, o valor de configuração Protocol padrão foi alterado de 2, 1 para 2 apenas. Portanto, instruções baseadas em versões mais antigas não se aplicam literalmente hoje. Outra coisa a considerar é como uma determinada distribuição altera o arquivo em seu pacote.

Quanto às configurações:

• a menos que você esteja usando aplicativos antigos, mantenha Protocol definido como apenas 2 - com a frequência, a menos que você saiba o que isso significa, mantenha os padrões;

• alterar a porta não faz muito sentido, a menos que você tenha apenas algumas portas disponíveis devido a restrições impostas a você pela rede em que você está. Definitivamente não é uma medida de proteção de segurança.

• impedir o acesso direto ao root é uma boa ideia. Você também pode querer desabilitar os logins de senha e usar somente autenticação de chave privada, já que é muito mais difícil (impossível de ler) de quebrar pela força bruta. Ele também pode criar efetivamente uma autenticação de dois níveis para o acesso raiz (primeiro, a chave privada para efetuar login e, em seguida, a senha para su ou sudo ). Por outro lado, você não conseguiria fazer login sem a chave (o que pode representar um problema sério em algumas situações).

A vinculação de

• a um endereço específico não faz muito sentido, a menos que você realmente queira veiculá-lo apenas em uma interface de rede. Novamente - se você não tem certeza, não mude. Em uma máquina que possui endereço IP dinâmico, pode até causar indisponibilidade temporária do serviço.

Answer 2

Não tenho certeza se realmente entendi sua pergunta, mas aqui estão os pontos-chave que recebi:

• A ordem das entradas de configuração no arquivo de configuração é irrelevante. É por isso que você pode ter um layout diferente daquele nas instruções que você tem. Você deve apenas certificar-se de usar apenas cada parâmetro uma vez no arquivo.
• Como o @Mark afirmou, é uma questão do seu ambiente se você pode usar somente o protocolo 2. Se você quiser ativar as versões 1 e 2, a linha deve ler Protocol 1,2
• Alterar a porta é uma questão de gosto (ou convenção, em alguns casos) e não aumenta a segurança: um invasor pode facilmente fazer um portscan para descobrir em qual porta o SSHD está sendo executado. (Bem, você pode impedir o portscanning de algumas maneiras, mas é apenas uma questão de tempo e recursos para um atacante experiente descobrir).
• Permitir que root logins seja um problema de segurança: você não está apenas permitindo um nome de usuário que todos conhecem (para que um invasor possa se concentrar em forçar a senha para esse nome de usuário válido), mas também para a conta que é mais permissiva. A menos que haja boas razões, sugiro PermitRootLogin no e, em seguida, su ou sudo , dependendo da sua política.
• sudo exige que o usuário insira sua própria senha novamente, enquanto su solicita a senha de root . A diferença é que su na verdade abre um shell root para o usuário em que ele é root . sudo permite que o usuário execute determinados comandos como root . Uma configuração segura de sudo é uma questão de experiência (por exemplo, se você permitir que os usuários executem bash como root , basicamente permitirá root de acesso a cada sudoer ), então sudo faz não aumentar a segurança simplesmente ativando-a.
• Vincular o SSHD a um endereço IP específico por meio de ListenAddress é útil somente em hosts conectados a várias redes. Em tais sistemas, há um ganho de segurança se você limitar o acesso SSH às redes das quais você precisa de acesso SSH.

Answer 3

Tenha apenas respostas e sugestões parciais.

A partir dos comentários e do meu próprio arquivo de configuração sshd no Ubuntu 10.04, eu sugiro que você vá com o Protocolo 2. A menos que você tenha clientes ssh legados / pouco antigos.

O ListenAddress liga o daemon ssh a uma interface específica (correspondente ao ip). Deixá-lo como 0.0.0.0 se ligará a todas as interfaces (não apenas externas, mas também localhost / loopback), ao passo que a especificação de um endereço IP irá vinculá-lo a essa única interface.

PermitRootLogin no significa que você não pode usar root para efetuar login no ssh. Enquanto estiver logado, você ainda pode mudar para o usuário root, embora eu ache que a melhor prática é usar o sudo.

Mudar a porta obviamente mudará a porta ssh escuta. Não tenho certeza de onde você obteve o intervalo de portas disponíveis. Algumas portas estão reservadas consulte link para uma lista extensa. números de porta podem ir até 65535 e realmente portas acima de 1024 são um jogo justo contanto que você saiba que não está acertando nada.

Espero que ajude!

Marcar

    

Answer 4

A ordem das linhas em sshd_config é irrelevante, exceto por uma coisa: cada linha que começa com a palavra Match inicia uma nova seção e a organização dessas seções é importante.

As linhas que começam com # são comentadas: elas são ignoradas. Você pode vê-los no arquivo de configuração padrão como exemplos de coisas que você poderia escrever se quisesse. Você não precisa comentar a linha para alterar uma configuração, você pode escrever linhas extras como desejar.

Por exemplo, #Port 22 está lá porque a porta padrão é 22. Se você remover o caractere # , você explicitamente definirá a porta como 22, o que na verdade não altera nada. Se você remover o # e alterar o número, isso fará com que o servidor SSH escute em uma porta diferente. Você também pode deixar a linha comentada sozinha (se estiver presente) e escrever Port 1234 em uma linha separada.

Ouvir em uma porta diferente não é muito útil: os invasores sabem como encontrar servidores ouvindo em qualquer porta, o risco é apenas marginalmente reduzido. O único benefício em mudar a porta é que você terá menos tentativas automatizadas (caçando senhas fracas) em seus registros. Isso não vale a pena: a alteração da porta tornará seu servidor inacessível por trás de alguns firewalls que só permitem o tráfego criptografado em determinadas portas.

Ter Protocol 2 é uma boa ideia, a menos que você saiba que deseja usar clientes extremamente antigos.

ListenAddress é útil apenas para determinadas configurações em que você deseja que o servidor SSH ouça somente em uma placa de rede. Você não precisa disso.

PermitRootLogin no geralmente é uma boa ideia, mas não é o óbvio que algumas pessoas descobrem. Ele fornece apenas um benefício de segurança direta se sua senha root estiver fraca ou vazada (não é uma boa idéia) ou se você permitir que o root efetue login com uma chave fraca ou perdida (idem). Se o root não puder efetuar login diretamente, isso significa que os usuários precisam fazer login pela primeira vez com sua própria conta. Isso é bom para a prestação de contas, para saber o que aconteceu após o fato de os usuários legítimos terem se logado. Na maioria das configurações, os usuários mal-intencionados podem alterar os logs após o fato. ser visível.

Outra configuração de proteção comum é exigir que os usuários usem pares de chaves em vez de senhas para autenticação, ou seja, desative a autenticação de senha:

PasswordAuthentication no

Você só deve permitir a autenticação por senha se:

• todos os seus usuários podem ser confiáveis para escolher senhas strongs; e
• é possível confiar em todos os seus usuários para nunca efetuar login em máquinas confiáveis (onde eles têm certeza de que não há keyloggers ou similares).