O Manual SSH Secure Shell

Tutorial sobre este magnífico protocolo que iniciou as suas aventuras em 1997, oferecendo uma grande variedade de ferramentas que se destacam pela sua segurança, sendo muito extenso dividirei-o em várias entradas tentando abranger o mais importante tanto ao nível do cliente como do servidor.

O que é o protocolo Secure Shell?Secure Shell ou SSH é um protocolo de rede que permite a troca de dados em um canal seguro entre dois computadores. O SSH usa técnicas de criptografia que tornam ilegíveis as informações que trafegam pelo meio de comunicação e nenhuma terceira pessoa pode descobrir o nome de usuário e a senha da conexão ou o que é escrito durante toda a sessão. O SSH usa criptografia de chave pública para autenticar o computador remoto e permitir que ele autentique o usuário, se necessário.

SSH é geralmente usado para iniciar uma sessão em uma máquina remota, onde você pode executar comandos, mas também permite encapsulamento, encaminhamento arbitrário de portas TCP e conexões X11; As transferências de arquivos também podem ser realizadas usando os protocolos SFTP ou SCP associados.

Podemos perceber que seu grande atrativo é sua característica mais do que suficiente para deslocar o antigo protocolo TELNET, que carecia de criptografia de informações, comprometendo dados, inclusive credenciais de acesso.

O Servidor SSH, oferece a porta TCP 22. Um cliente SSH geralmente é usado para estabelecer conexões com um servidor sshd que aceita conexões remotas. Ambos são comumente encontrados na maioria dos sistemas operacionais modernos, incluindo Mac, Linux, Solaris e OpenVMS.

Espera-se que o suporte do Windows para sua versão de servidor seja lançado oficialmente este ano, enquanto no nível do cliente ele oferece uma ampla variedade de opções destacando o PuTTY em relação aos outros.

Aprenda a usar o Putty

OpenSSHOpenSSH (Open Secure Shell) é um conjunto de aplicativos que permitem a comunicação criptografada em uma rede, utilizando o protocolo SSH. Foi criado como uma alternativa livre e aberta ao protocolo SSH, é o mais utilizado no Linux e será o que utilizaremos ao longo dos verbetes.

1. Instalar Secure Shell SSH


Em quase todas as distribuições sua versão cliente é pré-instalada enquanto sua versão servidor está disponível por repositório, sua instalação deve ser muito simples.

Debian, Ubuntu, Linux Mint e derivados

 sudo apt-get install servidor openssh

Centos, Rhel, Fedora

 sudo yum install servidor openssh

Arch-Linux

 pacman -Syu openssh

Verificamos se ele está sendo executado com:

 curl localhost: 22
No caso de funcionar corretamente, deve retornar:

[cor = # 696969] [/Cor]

Conectando-se ao servidor
Usando o cliente, podemos nos conectar ao servidor que pode ser remoto, mesmo se tivermos as duas versões para conectarmos internamente usando localhost.

A maneira mais básica de se conectar seria:

 ssh usuário @ hostaddress
No caso de conexão interna seria:
 ssh usuário @ localhost
Temos uma grande variedade de opções de conexão, vou explicar algumas muito úteis, você pode listar todas as suas opções com:
 homem ssh
Aqui nós mostramos a eles:

Opções Man SSH
-CSolicite compactação de dados economizando largura de banda ou dados no caso de estar em uma rede móvel.

-euEspecifique o usuário com quem iremos nos conectar.

-ECrie um arquivo de log onde o erro padrão será desviado.

-FSelecionamos outro arquivo de configuração útil para servidores com opções incomuns.

-gObrigatório para tunelamento de portas.

-euEscolhemos a pasta que usaremos como chave privada alternativa.

-KAtive ao usar credenciais GSSAPI.

-nUsando-o em conjunto com o X11 desta forma, todo o log gerado pelo aplicativo é desviado para / dev / null.

-ouNecessário para usar opções mais avançadas, como ServerAliveInterval 30.

-pSelecione uma porta diferente de 22 para se conectar ao host.

-vMostra todos os passos necessários para estabelecer a conexão.Você pode obter ainda mais informações com -vv -vvv.

-XNecessário se quisermos usar o X11 Forwarding.

-YAtiva o encaminhamento X11 seguro.

Vamos nos conectar ao servidor test.solvetic.com com o usuário jcarrillo usando uma chave privada diferente localizada em nossa pasta / home / jcarrillo / keys-aws usando a porta 8022 de nossa instância no AWS.

 Exemplo → ssh -C -i “~ / keys-aws /” -p 8022 -l jcarrillo test.solvetic.com
Como podemos ver, é uma ferramenta extensa, mas muito completa, que merece mais entradas para poder cobrir suas funções necessárias para qualquer administrador de sistema de nível intermediário ou profissional.

Passamos agora à sua configuração ao nível cliente-servidor, gerando chaves públicas e privadas, utilização de port forwarding em situações reais, redireccionamento do servidor X através de X11 Forwarding, utilização de scp, sftp, ssh-agent entre outros .

2. Proteger servidor SSH


Continuamos com OpenSSH focando em protegendo nosso servidor SSH, para evitar todo tipo de Ataques que possam comprometer nosso Servidor. Todas essas configurações serão feitas no arquivo sshd_config localizado em / etc / ssh / que podemos modificar com qualquer editor de texto no meu caso, uso vim:
 sudo vim / etc / ssh / sshd_config
Agora vamos ver como modificá-lo.

Modificar sshd_config
Dentro, veremos um arquivo de configuração típico baseado em "Opção de valor" Se alguma das opções não for encontrada por padrão, devemos colocar a linha completamente, nos outros casos será apenas para mudar de 0 para 1 de Não para Sim ou descomentar uma linha.

Modificar a porta 22
É essencial mude a porta padrão para uma porta aleatória muitos scripts são configurados para atacar esta porta, é recomendado alterá-lo no variam de 1000 a 23000 garantindo que a porta não seja usada por outro serviço.

Nem devemos usar portas como 2222, 8022 ou 1022, elas são tão comuns quanto 22 e muitos scripts são configurados para atacá-las.

porta 2345

Sim, temos SELINUX habilitado, devemos usar um comando adicional para permitir o acesso de fora para a nova porta.

Semanage port -a -t ssh_port_t -p tcp 2345 # Alterando a porta 22 para segurança

Use o protocolo 2 padrão
Devemos ter certeza de que todas as nossas conexões são feitas sob o Protocolo 2, pois 1 tem muitas vulnerabilidades.

Protocolo 2

É hora de inserir as credenciais
Seção de pesquisa "Autenticação". Suas duas primeiras opções também são importantes. O primeiro é o número de segundos que o usuário remoto terá para fazer o login em sua máquina. Defina esse valor para alguns segundos, não demorará muito para fazer o login se soubermos a conta e a senha.

Dessa forma, evitamos certos scripts que aproveitam esse tempo. O valor típico em termos de segurança é 30, embora possa ser ainda menor.

LoginGraceTime 30

Desativar o acesso à raiz
Está É a opção mais importante ser vítima de um ataque, eles precisam de 3 coisas:

  • Do utilizador
  • porta
  • Senha

Se desativarmos o root, eles já terão um como root, um usuário comum em todos os sistemas. Além disso, este usuário pode causar estragos por ter todas as permissões habilitadas.

PermitRootLogin no

Habilitar acesso controlado
Podemos controlar qual usuário pode fazer o login através do SSH e até mesmo colocar uma cláusula para conectar apenas a partir de um determinado IP. Isso é semelhante ao que a AWS oferece para nos conectar às suas instâncias.

AllowUsers [email protected]

É importante permitir o acesso apenas a usuários que precisam de acesso remoto e, se possível, limitá-los a um IP conhecido.

Configure o número de tentativas falhadas
Se colocarmos a senha errada, o servidor nos dá várias tentativas para inseri-la novamente, isso deve ser limitado ou você pode ser vítima de um script de força bruta, podemos colocá-lo 2 ou 3 vezes.

MaxAuthTries 2

Número de conexões permitidas simultaneamente
Isso pode variar dependendo de como você usa o servidor, mas o ideal é que ele seja controlado, basta somar o número total de usuários permitidos pelo SSH.

MaxStartups X

Depois de fazer todas as alterações em nosso arquivo, devemos reinicie nosso serviço sshd, Pode variar dependendo do gerente de serviço.

SystemD

 systemctl restart sshd

Upstart / Sysinit

 reiniciar serviço sshd

Todas essas mudanças adicionam um nível extra de segurança mas devemos ter em mente:

  • Use senhas alfanuméricas.
  • Usar Autenticação por chaves públicas / privadas quando for possível.
  • Complemente a Segurança com SELINUX e Firewalls.
  • Controle o acesso ao qual os usuários precisam fazer login remotamente.

Autenticar chaves públicas / privadas SSH


Uso atualmente Chaves SSH É um requisito indispensável, esta autenticação é amplamente utilizada por Administradores para automatizar tarefas entre vários servidores e ainda é utilizada por desenvolvedores para acessar SCM como GIT, GITHUB, GITLAB entre outros.

Oferece grande segurança e possibilidade de criar tarefas automatizadas baseado em script como um Voltar ou Replicar alterações para vários nós ao mesmo tempo.

Ao usar uma chave SSH (público e privado), eles podem se conectar facilmente a um servidor ou a vários servidores, sem a necessidade de inserir uma senha a cada vez. É possível configurar suas chaves sem senha, porém isso seria imprudente, se alguém obtivesse sua chave, poderia usá-la. Falaremos sobre como gerar chaves, distribuí-las e usar ssh-agent para obter maior segurança.

Gerando chaves sem senha
Antes de mais nada, certifique-se de ter o OpenSSH instalado, não é necessário, o servidor apenas o cliente.

Começamos gerando uma chave do tipo DSA com segurança de 1024 bits, mais do que suficiente, embora você possa ir além e gerar uma chave do tipo RSA com um limite de 4096.

 ssh-keygen -b 1024 -t dsa
Ele nos pedirá o local onde salvará as chaves padrão ~ / .ssh
 Digite o arquivo no qual deseja salvar a chave (/home/test/.ssh/id_dsa)
Então pedirá uma frase por enquanto não usaremos nenhuma e deixaremos em branco e nos dirá que a chave foi criada e nos reflete.

A imagem sempre será diferente, ela é gerada de forma aleatória, então se formos para a pasta .ssh devemos ter 2 arquivos

id_dsa -----> Chave privada (não compartilhe com ninguém, é como o seu TDC).
id_dsa.pub ----> É o que compartilhamos para conectar.

Compartilhar chave pública
Caso desejemos compartilhar a chave pública no SCM ou Chef, Puppet, Jenkins, visualizamos o arquivo da chave pública, copiamos e colamos onde corresponder.

 mais id_dsa.pub ssh-dss AAAAB3NzaC1kc3MAAACBAN6SEI4Qqzb23pJYRXIAtPmGJHln5hFdthFq43ef + ifR29v2IknXCFwefKK8jorSDiUEY / 1F / yp0xao mjhFQu1jNXOgF0PAZTfivRVFn6Q9FRsyXU9s + fx + + L22sV7GkCHPxAAAAFQCyF1Gdh3 xQiW3mf3y4IX654O82SLGl7Vhh5UsvG8r8d8pV6R Cap4xr / J44xDDn 0gFArHmFwAxfQAAAIEAmVYjPYAdQ9DCNWP + + + 03anWgyoZqSPPs23djyVQ756U4VitM0GiIQQ89HCdvTFFpSagnfdVpWh4 Hxo4Y5skKihnPMtB bFNbP / 2SmGdPz1AOmb7tvRrTkj5VLtXeDeB3ulowUKarwiBVVvAvxtxmozoZHOADWqrEPizxIAAACAU2DF1ZGTiJMP OhVB7mlsVhhkq53OxKKJbZqsl9hkOiSxaLUfQBNu6Ae441ekIObqolWNCBIvCO3uQYOozyzNGBhqHE7FVq 1oXguj + + + 2GAQ UGNkee96D2by S7daieIKNmFer2hO / SBxzepMrWAiIUnUsP5irmYspkjGlQxP + AXL = teste @ solvetic 
Caso você queira compartilhá-lo para acessar um servidor, sempre recomendo usar ssh-copy-id que está incluído no OpenSSH e é muito fácil de usar:
 ssh-copy-id user @ remote-server-ip -i especifica a localização da chave a ser usada.
Existem outras maneiras como:
 ssh user @ remote-server-ip \ 'cat >> .ssh / authorized_keys2' <.ssh / id_dsa.pub
 scp ~ / .ssh / id_dsa.pub usuário @ remote-server-ip
A partir de agora as chaves estão conectadas e você só precisa entrar no host.
 ssh -l usuário ip remoto do servidor
Desta vez não pedimos senha e podemos usar scripts sem interação.

Gere a frase secreta e associe-se ao agente ssh
O Segurança de chave SSH Baseia-se na nossa chave privada que funciona como um cartão de acesso, mas se alguém roubar a nossa chave, poderá aceder a todos os locais a que temos acesso. Mas ao gerar uma frase secreta podemos ter um nível extra, não só a chave é necessária, mas não precisamos introduzir nossa frase.

Desta vez, criaremos uma chave rsa com maior segurança configurando uma frase.

 ssh-keygen -b 4096 -t rsa -C "Chave com senha" # -C Adicione um comentário. 
Sendo uma frase, podemos usar espaços, pontos e caracteres especiais
 exemplo ---> Esta é minha nova chave com Fr @ S3.
Compartilhamos a nova chave:
 scp ~ / .ssh / id_rsa.pub usuário @ remote-server-ip
Desta vez, precisamos da chave e da frase-senha, mas digitá-la várias vezes é tedioso, mas podemos complementá-la com ssh-agent, devemos iniciá-la.
 agente ssh
Nós adicionamos nossa chave
 ssh-add Insira a frase-senha para /home/user/.ssh/id_rsa: # Nós inserimos a frase que configuramos. 
Agora podemos nos conectar a qualquer servidor que use nossa chave sem ter que entrar em nosso frase-senha.

Recomendo este método se você estiver fora da intranet, cliente e servidor em diferentes pontos da Internet, e não utilizaremos tarefas automatizadas, mas sim se conectar ao servidor para fins de administração remota, é melhor indicar uma senha ou muito longa senha (15 ou mais caracteres, maiúsculas, minúsculas, números e símbolos) para a chave pública.

Desta maneira será praticamente impossível ser hackeado por este método, já que não só o hacker terá que saber a senha, mas também terá um certificado público válido no servidor para que possa ser autenticado. (Claro, assumindo que o servidor nunca foi comprometido e está completamente atualizado e com a melhor segurança possível).

Gostou e ajudou este tutorial?Você pode recompensar o autor pressionando este botão para dar a ele um ponto positivo

Você vai ajudar o desenvolvimento do site, compartilhando a página com seus amigos

wave wave wave wave wave