One place for hosting & domains

      chaves

      Como configurar a autenticação baseada em chaves SSH em um servidor Linux


      Introdução

      O SSH, ou shell seguro, é um protocolo criptografado usado para administrar e se comunicar com servidores. Ao trabalhar com um servidor Linux, existem boas chances de você gastar a maior parte do seu tempo em uma sessão de terminal conectada ao seu servidor através do SSH.

      Embora existam outras maneiras diferentes de fazer login em um servidor SSH, neste guia, iremos focar na configuração de chaves SSH. As chaves SSH oferecem uma maneira fácil e extremamente segura de fazer login no seu servidor. Por esse motivo, este é o método que recomendamos para todos os usuários.

      Como as chaves SSH funcionam?

      Um servidor SSH pode autenticar clientes usando uma variedade de métodos diferentes. O mais básico deles é a autenticação por senha, que embora fácil de usar, mas não é o mais seguro.

      Apesar de as senhas serem enviadas ao servidor de maneira segura, elas geralmente não são complexas ou longas o suficiente para resistirem a invasores persistentes. O poder de processamento moderno combinado com scripts automatizados torna possível forçar a entrada de maneira bruta em uma conta protegida por senha. Embora existam outros métodos para adicionar segurança adicional (fail2ban, etc), as chaves SSH são comprovadamente uma alternativa confiável e segura.

      Os pares de chaves SSH são duas chaves criptografadas e seguras que podem ser usadas para autenticar um cliente em um servidor SSH. Cada par de chaves consiste em uma chave pública e uma chave privada.

      A chave privada é mantida pelo cliente e deve ser mantida em absoluto sigilo. Qualquer comprometimento da chave privada permitirá que o invasor faça login em servidores que estejam configurados com a chave pública associada sem autenticação adicional. Como uma forma de precaução adicional, a chave pode ser criptografada em disco com uma frase secreta.

      A chave pública associada pode ser compartilhada livremente sem consequências negativas. A chave pública pode ser usada para criptografar mensagens que apenas a chave privada pode descriptografar. Essa propriedade é usada como uma maneira de autenticar usando o par de chaves.

      A chave pública é enviada a um servidor remoto de sua preferência para que você possa fazer login via SSH. A chave é adicionada a um arquivo especial dentro da conta de usuário em que você estará fazendo login chamado ~/.ssh/authorized_keys.

      Quando um cliente tenta autenticar-se usando chaves SSH, o servidor testa o cliente para verificar se ele tem posse da chave privada. Se o cliente puder provar que possui a chave privada, a sessão do shell é gerada ou o comando solicitado é executado.

      Como criar chaves SSH

      O primeiro passo para configurar a autenticação de chaves SSH para seu servidor é gerar um par de chaves SSH no seu computador local.

      Para fazer isso, podemos usar um utilitário especial chamado ssh-keygen, que vem incluso com o conjunto padrão de ferramentas do OpenSSH. Por padrão, isso criará um par de chaves RSA de 2048 bits, que é suficiente para a maioria dos usos.

      No seu computador local, gere um par de chaves SSH digitando:

      ssh-keygen
      
      Generating public/private rsa key pair.
      Enter file in which to save the key (/home/username/.ssh/id_rsa):
      

      O utilitário irá solicitar que seja selecionado um local para as chaves que serão geradas. Por padrão, as chaves serão armazenadas no diretório ~/.ssh dentro do diretório home do seu usuário. A chave privada será chamada de id_rsa e a chave pública associada será chamada de id_rsa.pub.

      Normalmente, é melhor manter utilizar o local padrão neste estágio. Fazer isso permitirá que seu cliente SSH encontre automaticamente suas chaves SSH ao tentar autenticar-se. Se quiser escolher um caminho não padrão, digite-o agora. Caso contrário, pressione ENTER para aceitar o padrão.

      Caso tenha gerado um par de chaves SSH anteriormente, pode ser que você veja um prompt parecido com este:

      /home/username/.ssh/id_rsa already exists.
      Overwrite (y/n)?
      

      Se escolher substituir a chave no disco, você não poderá autenticar-se usando a chave anterior. Seja cuidadoso ao selecionar o sim, uma vez que este é um processo destrutivo que não pode ser revertido.

      Created directory '/home/username/.ssh'.
      Enter passphrase (empty for no passphrase):
      Enter same passphrase again:
      

      Em seguida, você será solicitado a digitar uma frase secreta para a chave. Esta é uma frase secreta opcional que pode ser usada para criptografar o arquivo de chave privada no disco.

      Você pode estar se perguntando sobre quais são as vantagens que uma chave SSH oferece se ainda é necessário digitar uma frase secreta. Algumas das vantagens são:

      • A chave SSH privada (a parte que pode ser protegida por uma frase secreta), nunca é exposta na rede. A frase secreta é usada apenas para descriptografar a chave na máquina local. Isso significa que utilizar força bruta na rede não será possível contra a frase secreta.
      • A chave privada é mantida dentro de um diretório restrito. O cliente SSH não irá reconhecer chaves privadas que não são mantidas em diretórios restritos. A chave em si também precisa ter permissões restritas (leitura e gravação apenas disponíveis para o proprietário). Isso significa que outros usuários no sistema não podem bisbilhotar.
      • Qualquer invasor que queira decifrar a frase secreta da chave SSH privada precisa já ter acesso ao sistema. Isso significa que eles já terão acesso à sua conta de usuário ou conta root. Se você estiver nesta posição, a frase secreta pode impedir que o invasor faça login imediatamente em seus outros servidores. Espera-se que isso dê a você tempo suficiente para criar e implementar um novo par de chaves SSH e remover o acesso da chave comprometida.

      Como a chave privada nunca é exposta à rede e é protegida através de permissões de arquivos, este arquivo nunca deve ser acessível a qualquer um que não seja você (e o usuário root). A frase secreta serve como uma camada adicional de proteção caso essas condições sejam comprometidas.

      Uma frase secreta é uma adição opcional. Se você inserir uma, será necessário fornecê-la sempre que for usar essa chave (a menos que você esteja executando um software de agente SSH que armazena a chave descriptografada). Recomendamos a utilização de uma frase secreta, mas se você não quiser definir uma, basta pressionar ENTER para ignorar este prompt.

      Your identification has been saved in /home/username/.ssh/id_rsa.
      Your public key has been saved in /home/username/.ssh/id_rsa.pub.
      The key fingerprint is:
      a9:49:2e:2a:5e:33:3e:a9:de:4e:77:11:58:b6:90:26 username@remote_host
      The key's randomart image is:
      +--[ RSA 2048]----+
      |     ..o         |
      |   E o= .        |
      |    o. o         |
      |        ..       |
      |      ..S        |
      |     o o.        |
      |   =o.+.         |
      |. =++..          |
      |o=++.            |
      +-----------------+
      

      Agora, você tem uma chave pública e privada que pode usar para se autenticar. O próximo passo é colocar a chave pública no seu servidor para que você possa usar a autenticação baseada em chaves SSH para fazer login.

      Como incorporar sua chave pública ao criar seu servidor

      Se você estiver iniciando um novo servidor da DigitalOcean, é possível incorporar automaticamente sua chave pública SSH na nova conta raiz do seu servidor.

      No final da página de criação do Droplet, há uma opção para adicionar chaves SSH ao seu servidor:

      Incorporação de chaves SSH

      Se você já tiver adicionado um arquivo de chave pública à sua conta da DigitalOcean, verá ela aqui como uma opção selecionável (há duas chaves já existentes no exemplo acima: “Work key” e “Home key”). Para incorporar uma chave existente, basta clicar nela para que fique destacada. É possível incorporar várias chaves em um único servidor:

      Seleção de chaves SSH

      Caso ainda não tenha uma chave SSH pública carregada em sua conta, ou se quiser adicionar uma nova chave à sua conta, clique no botão “+ Add SSH Key”. Isso irá abrir um prompt:

      Prompt de chaves SSH

      Na caixa “SSH Key content”, cole o conteúdo da sua chave SSH pública. Se você tiver gerado suas chaves usando o método acima, é possível obter o conteúdo de sua chave pública em seu computador local digitando:

      cat ~/.ssh/id_rsa.pub
      
      ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDNqqi1mHLnryb1FdbePrSZQdmXRZxGZbo0gTfglysq6KMNUNY2VhzmYN9JYW39yNtjhVxqfW6ewc+eHiL+IRRM1P5ecDAaL3V0ou6ecSurU+t9DR4114mzNJ5SqNxMgiJzbXdhR+j55GjfXdk0FyzxM3a5qpVcGZEXiAzGzhHytUV51+YGnuLGaZ37nebh3UlYC+KJev4MYIVww0tWmY+9GniRSQlgLLUQZ+FcBUjaqhwqVqsHe4F/woW1IHe7mfm63GXyBavVc+llrEzRbMO111MogZUcoWDI9w7UIm8ZOTnhJsk7jhJzG2GpSXZHmly/a/buFaaFnmfZ4MYPkgJD username@example.com
      

      Cole este valor, em sua totalidade, na caixa maior. Na caixa “Comment (optional)”, você pode escolher um rótulo para a chave. Isso será exibido como o nome da chave na interface da DigitalOcean:

      Nova chave SSH

      Ao criar seu Droplet, as chaves SSH públicas que você selecionou serão colocadas no arquivo ~/.ssh/authorized_keys da conta do usuário root. Isso permitirá fazer login no servidor a partir do computador com sua chave privada.

      Como copiar uma chave pública para seu servidor

      Se você já tiver um servidor disponível e não incorporou chaves em sua criação, ainda é possível enviar sua chave pública e usá-la para autenticar-se no seu servidor.

      O método a ser usado depende em grande parte das ferramentas disponíveis e dos detalhes da sua configuração atual. Todos os métodos a seguir geram o mesmo resultado final. O método mais fácil e automatizado é o primeiro e cada método depois dele necessita de passos manuais adicionais se você não conseguir usar os métodos anteriores.

      Copiando sua chave pública usando o SSH-Copy-ID

      A maneira mais fácil de copiar sua chave pública para um servidor existente é usando um utilitário chamado ssh-copy-id. Por conta da sua simplicidade, este método é recomendado se estiver disponível.

      A ferramenta ssh-copy-id vem inclusa nos pacotes OpenSSH em muitas distribuições, de forma que você pode tê-la disponível em seu sistema local. Para que este método funcione, você já deve ter acesso via SSH baseado em senha ao seu servidor.

      Para usar o utilitário, você precisa especificar apenas o host remoto ao qual gostaria de se conectar e a conta do usuário que tem acesso SSH via senha. Esta é a conta na qual sua chave SSH pública será copiada.

      A sintaxe é:

      ssh-copy-id username@remote_host
      

      Pode ser que apareça uma mensagem como esta:

      The authenticity of host '111.111.11.111 (111.111.11.111)' can't be established.
      ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe.
      Are you sure you want to continue connecting (yes/no)? yes
      

      Isso significa que seu computador local não reconhece o host remoto. Isso acontecerá na primeira vez que você se conectar a um novo host. Digite “yes” e pressione ENTER para continuar.

      Em seguida, o utilitário irá analisar sua conta local em busca da chave id_rsa.pub que criamos mais cedo. Quando ele encontrar a chave, irá solicitar a senha da conta do usuário remoto:

      /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
      /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
      username@111.111.11.111's password:
      

      Digite a senha (sua digitação não será exibida para fins de segurança) e pressione ENTER. O utilitário se conectará à conta no host remoto usando a senha que você forneceu. Então, ele copiará o conteúdo da sua chave ~/.ssh/id_rsa.pub em um arquivo no diretório da conta remota home ~/.ssh chamado authorized_keys.

      Você verá um resultado que se parece com este:

      Number of key(s) added: 1
      
      Now try logging into the machine, with:   "ssh 'username@111.111.11.111'"
      and check to make sure that only the key(s) you wanted were added.
      

      Neste ponto, sua chave id_rsa.pub foi enviada para a conta remota. Continue para a próxima seção.

      Copiando sua chave pública usando o SSH

      Se não tiver o ssh-copy-id disponível, mas tiver acesso SSH baseado em senha a uma conta do seu servidor, você pode fazer o upload das suas chaves usando um método SSH convencional.

      É possível fazer isso resgatando o conteúdo da nossa chave SSH pública do nosso computador local e enviando-o através de uma conexão via protocolo SSH ao servidor remoto. Do outro lado, certificamo-nos de que o diretório ~/.ssh existe na conta que estamos usando e então enviamos o conteúdo recebido em um arquivo chamado authorized_keys dentro deste diretório.

      Vamos usar o símbolo de redirecionamento >> para adicionar o conteúdo ao invés de substituí-lo. Isso permitirá que adicionemos chaves sem destruir chaves previamente adicionadas.

      O comando completo ficará parecido com este:

      cat ~/.ssh/id_rsa.pub | ssh username@remote_host "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"
      

      Pode ser que apareça uma mensagem como esta:

      The authenticity of host '111.111.11.111 (111.111.11.111)' can't be established.
      ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe.
      Are you sure you want to continue connecting (yes/no)? yes
      

      Isso significa que seu computador local não reconhece o host remoto. Isso acontecerá na primeira vez que você se conectar a um novo host. Digite “yes” e pressione ENTER para continuar.

      Depois disso, você será solicitado a inserir a senha da conta na qual está tentando se conectar:

      username@111.111.11.111's password:
      

      Após digitar sua senha, o conteúdo da sua chave id_rsa.pub será copiado para o final do arquivo authorized_keys da conta do usuário remoto. Continue para a próxima seção se o processo foi bem-sucedido.

      Copiando sua chave pública manualmente

      Se o acesso SSH baseado em senha ao seu servidor ainda não estiver disponível, será necessário completar o processo acima manualmente.

      O conteúdo do seu arquivo id_rsa.pub precisará ser adicionado a um arquivo em ~/.ssh/authorized_keys em sua máquina remota de alguma maneira.

      Para exibir o conteúdo de sua chave id_rsa.pub, digite o seguinte em seu computador local:

      cat ~/.ssh/id_rsa.pub
      

      Você verá o conteúdo da chave, que deve ser parecido com este:

      ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCqql6MzstZYh1TmWWv11q5O3pISj2ZFl9HgH1JLknLLx44+tXfJ7mIrKNxOOwxIxvcBF8PXSYvobFYEZjGIVCEAjrUzLiIxbyCoxVyle7Q+bqgZ8SeeM8wzytsY+dVGcBxF6N4JS+zVk5eMcV385gG3Y6ON3EG112n6d+SMXY0OEBIcO6x+PnUSGHrSgpBgX7Ks1r7xqFa7heJLLt2wWwkARptX7udSq05paBhcpB0pHtA1Rfz3K2B+ZVIpSDfki9UVKzT8JUmwW6NNzSgxUfQHGwnW7kj4jp4AT0VZk3ADw497M2G/12N0PPB5CnhHf7ovgy6nL1ikrygTKRFmNZISvAcywB9GVqNAVE+ZHDSCuURNsAInVzgYo9xgJDW8wUw2o8U77+xiFxgI5QSZX3Iq7YLMgeksaO4rBJEa54k8m5wEiEE1nUhLuJ0X/vh2xPff6SQ1BL/zkOhvJCACK6Vb15mDOeCSq54Cr7kvS46itMosi/uS66+PujOO+xt/2FWYepz6ZlN70bRly57Q06J+ZJoc9FfBCbCyYH7U/ASsmY095ywPsBo1XQ9PqhnN1/YOorJ068foQDNVpm146mUpILVxmq41Cj55YKHEazXGsdBIbXWhcrRf4G2fJLRcGUr9q8/lERo9oxRm5JFX6TCmj6kmiFqv+Ow9gI0x8GvaQ== demo@test
      

      Acesse seu host remoto usando algum método que você tenha disponível. Por exemplo, se seu servidor for um Droplet da DigitalOcean, faça login usando o console Web no painel de controle:

      Acesso via console da DigitalOcean

      Assim que tiver acesso à sua conta no servidor remoto, certifique-se de que o diretório ~/.ssh foi criado. Este comando criará o diretório se necessário, ou não fará nada se ele já existir:

      mkdir -p ~/.ssh
      

      Agora, você pode criar ou modificar o arquivo authorized_keys dentro deste diretório. Você pode adicionar o conteúdo do seu arquivo id_rsa.pub ao final do arquivo authorized_keys, criando-o se for necessário, usando este comando:

      echo public_key_string >> ~/.ssh/authorized_keys
      

      No comando acima, substitua o public_key_string pelo resultado do comando cat ~/.ssh/id_rsa.pub que você executou no seu sistema local. Ela deve começar com ssh-rsa AAAA....

      Se isso funcionar, continue para tentar autenticar-se sem uma senha.

      Autenticar-se em seu servidor usando chaves SSH

      Se tiver completado um dos procedimentos acima, você deve conseguir fazer login no host remoto sem a senha da conta remota.

      O processo básico é o mesmo:

      ssh username@remote_host
      

      Se essa é a primeira vez que você se conecta a este host (caso tenha usado o último método acima), pode ser que veja algo como isso:

      The authenticity of host '111.111.11.111 (111.111.11.111)' can't be established.
      ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe.
      Are you sure you want to continue connecting (yes/no)? yes
      

      Isso significa que seu computador local não reconhece o host remoto. Digite “yes” e então pressione ENTER para continuar.

      Se não forneceu uma frase secreta para sua chave privada, você será logado imediatamente. Se forneceu uma frase secreta para a chave privada quando a criou, você será solicitado a digitá-la agora. Depois disso, uma nova sessão de shell deve ser-lhe gerada com a conta no sistema remoto.

      Caso isso dê certo, continue para descobrir como bloquear o servidor.

      Desativando a autenticação por senha no seu servidor

      Se conseguiu logar na sua conta usando o SSH sem uma senha, você configurou com sucesso a autenticação baseada em chaves SSH na sua conta. Entretanto, seu mecanismo de autenticação baseado em senha ainda está ativo, o que significa que seu servidor ainda está exposto a ataques por força bruta.

      Antes de completar os passos nesta seção, certifique-se de que você tenha uma autenticação baseada em chaves SSH configurada para a conta root neste servidor, ou, de preferência, que tenha uma autenticação baseada em chaves SSH configurada para uma conta neste servidor com privilégios sudo. Este passo irá bloquear os logins baseados em senha. Por isso, garantir que você ainda terá acesso de administrador será essencial.

      Assim que as condições acima forem verdadeiras, entre no seu servidor remoto com chaves SSH como root ou com uma conta com privilégios sudo. Abra o arquivo de configuração do daemon do SSH:

      sudo nano /etc/ssh/sshd_config
      

      Dentro do arquivo, procure por uma diretiva chamada PasswordAuthentication. Isso pode ser transformado em comentário. Descomente a linha e configure o valor em “no”. Isso irá desativar a sua capacidade de fazer login via SSH usando senhas de conta:

      PasswordAuthentication no
      

      Salve e feche o arquivo quando você terminar. Para realmente implementar as alterações que acabamos de fazer, reinicie o serviço.

      Em máquinas Ubuntu ou Debian, emita este comando:

      sudo service ssh restart
      

      Em máquinas CentOS/Fedora, o daemon chama-se sshd:

      sudo service sshd restart
      

      Após completar este passo, você alterou seu daemon do SSH com sucesso para responder apenas a chaves SSH.

      Conclusão

      Agora, você deve ter uma autenticação baseada em chaves SSH configurada no seu servidor, permitindo fazer login sem fornecer uma senha de conta. A partir daqui, há muitas direções em que você pode seguir. Se você quiser aprender mais sobre como trabalhar com o SSH, veja nosso Guia de Noções Básicas sobre SSH.



      Source link

      Como configurar as chaves SSH no Ubuntu 20.04


      Introdução

      O SSH, ou shell seguro, é um protocolo criptografado usado para administrar e se comunicar com servidores. Ao trabalhar com um servidor Ubuntu, existem boas chances de você gastar a maior parte do seu tempo em uma sessão de terminal conectada ao seu servidor através do SSH.

      Neste guia, nos concentraremos na configuração de chaves SSH para uma instalação do Ubuntu 20.04. As chaves SSH fornecem uma maneira fácil e segura de fazer login no seu servidor e são recomendadas para todos os usuários.

      Passo 1 — Criando o par de chaves

      O primeiro passo é criar uma par de chaves na máquina do cliente (geralmente seu computador):

      Por padrão, as versões mais recentes do ssh-keygen criarão um par de chaves RSA de 3072 bits, que é seguro o suficiente para a maioria dos casos de uso (você pode usar o sinalizador -b 4096 para criar uma chave maior de 4096 bits).

      Após digitar o comando, você deve ver o seguinte resultado:

      Output

      Generating public/private rsa key pair. Enter file in which to save the key (/your_home/.ssh/id_rsa):

      Pressione ENTER para salvar o par de chaves no sub-diretório .ssh/ no seu diretório home, ou especifique um caminho alternativo.

      Se você tivesse gerado anteriormente um par de chaves SSH, pode ser que veja o seguinte prompt:

      Output

      /home/your_home/.ssh/id_rsa already exists. Overwrite (y/n)?

      Se escolher substituir a chave no disco, você não poderá autenticar-se usando a chave anterior. Seja cuidadoso ao selecionar o sim, uma vez que este é um processo destrutivo que não pode ser revertido.

      Então, você deve ver o seguinte prompt:

      Output

      Enter passphrase (empty for no passphrase):

      Aqui você pode digitar uma frase secreta de forma opcional, o que é altamente recomendado. Uma frase secreta adiciona uma camada adicional de segurança para evitar que os usuários não autorizados façam login. Para aprender mais sobre segurança, consulte nosso tutorial sobre Como configurar a autenticação baseada em chaves SSH em um servidor Linux.

      Você deve ver um resultado parecido com o seguinte:

      Output

      Your identification has been saved in /your_home/.ssh/id_rsa Your public key has been saved in /your_home/.ssh/id_rsa.pub The key fingerprint is: SHA256:/hk7MJ5n5aiqdfTVUZr+2Qt+qCiS7BIm5Iv0dxrc3ks user@host The key's randomart image is: +---[RSA 3072]----+ | .| | + | | + | | . o . | |o S . o | | + o. .oo. .. .o| |o = oooooEo+ ...o| |.. o *o+=.*+o....| | =+=ooB=o.... | +----[SHA256]-----+

      Agora, você tem uma chave pública e uma chave privada que poderá usar para se autenticar. O próximo passo é colocar a chave pública no seu servidor para que você possa usar a autenticação baseada em chaves SSH para fazer login.

      Passo 2 — Copiando a chave pública para o seu servidor Ubuntu

      A maneira mais rápida de copiar sua chave pública para o host do Ubuntu é usar um utilitário chamado ssh-copy-id. Devido a sua simplicidade, este método é altamente recomendado se estiver disponível. Se não tiver o ssh-copy-id disponível na sua máquina do cliente, você pode usar um dos dois métodos alternativos fornecidos nesta seção (copiar através do SSH baseado em senha, ou copiar manualmente a chave).

      Copiando sua chave pública usando o ssh-copy-id

      Por padrão, a ferramenta ssh-copy-id vem incluída em muitos sistemas operacionais. Assim, você pode tê-la disponível em seu sistema local. Para que esse método funcione, você já deverá ter acesso ao seu servidor via SSH baseado em senha.

      Para usar o utilitário, especifique o host remoto ao qual gostaria de se conectar e a conta de usuário que você tem acesso por senha via SSH. Esta é a conta na qual sua chave SSH pública será copiada.

      A sintaxe é:

      • ssh-copy-id username@remote_host

      Pode ser que você veja a seguinte mensagem:

      Output

      The authenticity of host '203.0.113.1 (203.0.113.1)' can't be established. ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe. Are you sure you want to continue connecting (yes/no)? yes

      Isso significa que seu computador local não reconhece o host remoto. Isso acontecerá na primeira vez que você se conectar a um novo host. Digite “yes” e pressione ENTER para continuar.

      Em seguida, o utilitário irá analisar sua conta local em busca da chave id_rsa.pub que criamos mais cedo. Quando ele encontrar a chave, irá solicitar a senha da conta do usuário remoto:

      Output

      /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys username@203.0.113.1's password:

      Digite a senha (sua digitação não será exibida para fins de segurança) e pressione ENTER. O utilitário se conectará à conta no host remoto, usando a senha que você forneceu. Então, ele copiará o conteúdo da sua chave ~/.ssh/id_rsa.pub em um arquivo no diretório da conta remota home ~/.ssh chamado authorized_keys.

      Você deve ver o seguinte resultado:

      Output

      Number of key(s) added: 1 Now try logging into the machine, with: "ssh 'username@203.0.113.1'" and check to make sure that only the key(s) you wanted were added.

      Neste ponto, sua chave id_rsa.pub foi transferida para a conta remota. Você pode prosseguir para o Passo 3.

      Copiando a chave pública usando o SSH

      Se não tiver o ssh-copy-id disponível, mas tiver acesso SSH baseado em senha a uma conta do seu servidor, você pode fazer o upload das suas chaves usando um método SSH convencional.

      Podemos fazer isso usando o comando cat para ler o conteúdo da chave SSH pública no nosso computador local e passando isso através de uma conexão SSH ao servidor remoto.

      Por outro lado, podemos certificar-nos se o diretório ~/.ssh existe e se tem as permissões corretas sob a conta que estamos usando.

      Então, podemos entregar o conteúdo que foi passado em um arquivo chamado authorized_keys dentro deste diretório. Vamos usar o símbolo de redirecionamento >> para adicionar o conteúdo ao invés de substituí-lo. Isso permitirá que adicionemos chaves sem destruir chaves previamente adicionadas.

      O comando completo se parece com este:

      • cat ~/.ssh/id_rsa.pub | ssh username@remote_host "mkdir -p ~/.ssh && touch ~/.ssh/authorized_keys && chmod -R go= ~/.ssh && cat >> ~/.ssh/authorized_keys"

      Pode ser que você veja a seguinte mensagem:

      Output

      The authenticity of host '203.0.113.1 (203.0.113.1)' can't be established. ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe. Are you sure you want to continue connecting (yes/no)? yes

      Isso significa que seu computador local não reconhece o host remoto. Isso acontecerá na primeira vez que você se conectar a um novo host. Digite yes e pressione ENTER para continuar.

      Depois disso, você deve ser solicitado a digitar a senha da conta de usuário remoto:

      Output

      username@203.0.113.1's password:

      Após digitar sua senha, o conteúdo da sua chave id_rsa.pub será copiado para o final do arquivo authorized_keys da conta do usuário remoto. Continue para o Passo 3 se isso foi bem-sucedido.

      Copiando a chave pública manualmente

      Se não tiver acesso ao servidor disponível, via SSH baseado em senha, você terá que completar o processo acima manualmente.

      Vamos acrescentar o conteúdo do seu arquivo id_rsa.pub manualmente ao arquivo ~/.ssh/authorized_keys, em sua máquina remota.

      Para exibir o conteúdo de sua chave id_rsa.pub, digite o seguinte em seu computador local:

      Você verá o conteúdo da chave, que deve ser parecido com este:

      Output

      ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCqql6MzstZYh1TmWWv11q5O3pISj2ZFl9HgH1JLknLLx44+tXfJ7mIrKNxOOwxIxvcBF8PXSYvobFYEZjGIVCEAjrUzLiIxbyCoxVyle7Q+bqgZ8SeeM8wzytsY+dVGcBxF6N4JS+zVk5eMcV385gG3Y6ON3EG112n6d+SMXY0OEBIcO6x+PnUSGHrSgpBgX7Ks1r7xqFa7heJLLt2wWwkARptX7udSq05paBhcpB0pHtA1Rfz3K2B+ZVIpSDfki9UVKzT8JUmwW6NNzSgxUfQHGwnW7kj4jp4AT0VZk3ADw497M2G/12N0PPB5CnhHf7ovgy6nL1ikrygTKRFmNZISvAcywB9GVqNAVE+ZHDSCuURNsAInVzgYo9xgJDW8wUw2o8U77+xiFxgI5QSZX3Iq7YLMgeksaO4rBJEa54k8m5wEiEE1nUhLuJ0X/vh2xPff6SQ1BL/zkOhvJCACK6Vb15mDOeCSq54Cr7kvS46itMosi/uS66+PujOO+xt/2FWYepz6ZlN70bRly57Q06J+ZJoc9FfBCbCyYH7U/ASsmY095ywPsBo1XQ9PqhnN1/YOorJ068foQDNVpm146mUpILVxmq41Cj55YKHEazXGsdBIbXWhcrRf4G2fJLRcGUr9q8/lERo9oxRm5JFX6TCmj6kmiFqv+Ow9gI0x8GvaQ== demo@test

      Acesse seu host remoto usando algum método que você tenha disponível.

      Assim que tiver acesso à sua conta no servidor remoto, você deve garantir que o diretório ~/.ssh exista. Se necessário, o comando a seguir criará o diretório ou não fará nada, se ele já existir:

      Agora, você pode criar ou modificar o arquivo authorized_keys dentro desse diretório. Você pode adicionar o conteúdo do seu arquivo id_rsa.pub ao final do arquivo authorized_keys, criando-o – se necessário – usando este comando:

      • echo public_key_string >> ~/.ssh/authorized_keys

      No comando acima, substitua o public_key_string pelo resultado do comando cat ~/.ssh/id_rsa.pub que você executou no seu sistema local. Ela deve começar com ssh-rsa AAAA....

      Por fim, vamos garantir que o diretório ~/.ssh e o arquivo authorized_keys tenham as permissões apropriadas configuradas:

      Isso remove recursivamente todas as permissões “grupo” e “outras” para o diretório ~/.ssh/.

      Se você estiver usando a conta root para configurar chaves de uma conta de usuário, também é importante que o diretório ~/.ssh pertença ao usuário e não ao root:

      • chown -R sammy:sammy ~/.ssh

      Neste tutorial, nosso usuário se chama sammy, mas você deve substituí-lo pelo nome de usuário apropriado no comando acima.

      Agora, podemos tentar uma autenticação sem senha com nosso servidor Ubuntu.

      Passo 3 — Autenticando-se ao seu servidor Ubuntu usando chaves SSH

      Se tiver completado um dos procedimentos acima com êxito, você deve conseguir fazer login no host remoto sem fornecer a senha da conta remota.

      O processo básico é o mesmo:

      Se essa é a primeira vez que você se conecta a este host (caso tenha usado o último método acima), pode ser que veja algo como isso:

      Output

      The authenticity of host '203.0.113.1 (203.0.113.1)' can't be established. ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe. Are you sure you want to continue connecting (yes/no)? yes

      Isso significa que seu computador local não reconhece o host remoto. Digite “yes” e então pressione ENTER para continuar.

      Se não forneceu uma frase secreta para sua chave privada, você será logado imediatamente. Caso tenha fornecido uma frase secreta para a chave privada quando criou a chave, você será solicitado a digitá-la agora (note que sua digitação não será exibida na sessão do terminal como medida de segurança). Após a autenticação, uma nova sessão de shell deve abrir para você com a conta configurada no servidor Ubuntu.

      Se a autenticação baseada em chaves foi bem-sucedida, continue para aprender a proteger ainda mais o seu sistema, desativando a autenticação por senha.

      Passo 4 — Desabilitando a autenticação por senha em seu servidor

      Se conseguiu logar na sua conta usando o SSH sem uma senha, você configurou com sucesso a autenticação baseada em chaves SSH na sua conta. Entretanto, seu mecanismo de autenticação baseado em senha ainda está ativo, o que significa que seu servidor ainda está exposto a ataques por força bruta.

      Antes de completar os passos nesta seção, certifique-se de que você tenha uma autenticação baseada em chaves SSH configurada para a conta root neste servidor, ou, de preferência, que tenha uma autenticação baseada em senhas SSH configurada para uma conta não raiz neste servidor, com privilégios sudo. Este passo irá bloquear os logins baseados em senha. Dessa maneira,é fundamental assegurar que você ainda conseguirá obter acesso administrativo.

      Assim que você tiver confirmado que sua conta remota tem privilégios administrativos, acesse o seu servidor remoto com as chaves SSH, como root ou com uma conta com privilégios sudo. Então, abra o arquivo de configuração do daemon SSH:

      • sudo nano /etc/ssh/sshd_config

      Dentro do arquivo, procure por uma diretiva chamada PasswordAuthentication. Esta linha pode estar comentada com um # no começo dela. Descomente a linha removendo o # e defina o valor para no. Isso desativará sua habilidade de fazer login via SSH utilizando senhas de contas:

      /etc/ssh/sshd_config

      . . .
      PasswordAuthentication no
      . . .
      

      Salve e feche o arquivo quando terminar pressionando CTRL + X e, em seguida, Y para confirmar o salvamento do arquivo e, por fim, ENTER para sair do nano. Para ativar essas alterações, precisamos reiniciar o serviço sshd:

      • sudo systemctl restart ssh

      Como precaução, abra uma nova janela de terminal e teste se o serviço SSH está funcionando corretamente, antes de encerrar sua sessão atual:

      Assim que tiver verificado que seu serviço SSH está funcionando corretamente, você pode fechar todas as sessões atuais do servidor com segurança.

      O daemon SSH no seu servidor Ubuntu agora responde apenas às autenticações baseadas em chaves SSH. Os logins baseados em senha foram desativados.

      Conclusão

      Agora, você deve ter uma autenticação baseada em chaves SSH configurada no seu servidor, permitindo que você faça login sem fornecer uma senha da conta.

      Se você quiser aprender mais sobre como trabalhar com o SSH, veja nosso Guia de Noções Básicas sobre SSH.



      Source link

      Como Expirar Chaves no Redis


      Introdução

      O Redis é um datastore ou armazenamento de dados open-source de chave-valor na memória. As chaves Redis são persistentes por padrão, o que significa que o servidor Redis continuará armazenando-as, a menos que sejam excluídas manualmente. No entanto, pode haver casos em que você definiu uma chave, mas você sabe que deseja excluí-la após um certo período de tempo; em outras palavras, você deseja que a chave seja volátil. Este tutorial explica como definir as chaves para expirarem, verificar o tempo restante até a expiração de uma chave e cancelar a configuração de expiração de uma chave.

      Como Utilizar Este Guia

      Este guia está no formato de referência rápida com trechos de linha de comando independentes. Recomendamos que você pule para qualquer seção que seja relevante para a tarefa que você está tentando concluir.

      Os comandos mostrados neste guia foram testados em um servidor Ubuntu 18.04 executando a versão 4.0.9 do Redis. Para configurar um ambiente semelhante, você pode seguir o Passo 1 do nosso guia Como Instalar e Proteger o Redis no Ubuntu 18.04. Vamos demonstrar como esses comandos se comportam executando-os com redis-cli, a interface de linha de comando do Redis. Observe que se você estiver usando uma interface Redis diferente — Redli, por exemplo — a saída exata de certos comandos pode ser diferente.

      Como alternativa, você pode provisionar uma instância de banco de dados Redis gerenciada para testar esses comandos, mas observe que, dependendo do nível de controle permitido pelo seu provedor de banco de dados, alguns comandos neste guia podem não funcionar como descrito. Para provisionar um banco de dados gerenciado na DigitalOcean, siga nossa documentação de produto para Managed Databases. Então, você deve instalar ou o Redli ou configurar um túnel TLS para conectar-se ao banco de dados gerenciado por TLS.

      Definindo Chaves para Expirar

      Você pode definir um tempo de expiração para uma chave existente com o comando expire, que pega o nome da chave e o número de segundos até a expiração como argumentos. Para demonstrar isso, execute os dois comandos a seguir. O primeiro cria uma chave de string chamada key_melon com um valor de "cantaloupe", e o segundo a define para expirar após 450 segundos:

      • set key_melon "cantaloupe"
      • expire key_melon 450

      Se o tempo limite foi definido com sucesso, o comando expire retornará (integer) 1. Se a configuração de tempo limite falhar, ele retornará (integer) 0.

      Como alternativa, você pode definir a chave para expirar em um momento específico com o comando expireat. Em vez do número de segundos antes da expiração, ele precisa de um Unix timestamp ou registro de data e hora como argumento. Um Unix timestamp é o número de segundos desde a Unix epoch ou 00:00:00 UTC em 1 de janeiro de 1970. Há várias ferramentas on-line que você pode usar para encontrar o Unix timestamp de uma data e hora específicas, como o EpochConverter ou o UnixTimestamp.com.

      Por exemplo, para definir key_melon para expirar às 20:30 GMT em 1º de maio de 2025 (representado pelo Unix timestamp 1746131400), você poderia usar o seguinte comando:

      • expireat key_melon 1746131400

      Observe que se o timestamp passado para o expireat já tiver ocorrido, ele excluirá a chave imediatamente.

      Verificando Quanto Tempo Até uma Chave Expirar

      Sempre que você definir uma chave para expirar, poderá verificar o tempo restante até a expiração (em segundos) com o ttl, que significa “time to live” ou tempo de vida:

      Output

      (integer) 433

      Para informações mais detalhadas, você pode executar o pttl, que retornará a quantidade de tempo até que uma chave expire em milissegundos:

      Output

      (integer) 431506

      Ambos, ttl e pttl retornarão (integer) -1 se a chave não tiver sido configurada para expirar e (integer) -2 se a chave não existir.

      Chaves Persistentes

      Se uma chave foi configurada para expirar, qualquer comando que sobrescreva o conteúdo de uma chave — como set ou getset — limpará o valor de tempo limite da chave. Para limpar manualmente o tempo limite de uma chave, use o comando persist

      O comando persist retornará (integer) 1 se concluído com êxito, indicando que a chave não expirará mais.

      Conclusão

      Este guia detalha vários comandos usados para manipular e verificar a persistência de chave no Redis. Se houver outros comandos, argumentos ou procedimentos relacionados que você gostaria de ver descritos neste guia, peça ou faça sugestões nos comentários abaixo.

      Para obter mais informações sobre comandos Redis, consulte nossa série de tutoriais Como Gerenciar um Banco de Dados Redis.



      Source link