One place for hosting & domains

      servidor

      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 [email protected]
      

      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
      [email protected]'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 '[email protected]'"
      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:

      [email protected]'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 usar o servidor SMTP do Google


      O autor selecionou a COVID-19 Relief Fund para receber uma doação como parte do programa Write for DOnations.

      Introdução

      Um recurso pouco conhecido sobre o Gmail e o e-mail do Google Apps é o servidor SMTP portátil do Google. Ao invés de ter que gerenciar seu próprio servidor de e-mail de saída em seu Droplet da DigitalOcean ou Cluster Kubernetes, é possível definir as configurações do servidor SMTP do Google em qualquer script ou programa do qual você queira enviar e-mails. Tudo o que você precisa é (i) uma conta Gmail gratuita, ou (ii) uma conta G Suite paga.

      Benefícios

      Você tem a opção de deixar o Google lidar com a armazenagem e indexação dos e-mails enviados através do seu servidor SMTP, de forma que todos os seus e-mails enviados sejam pesquisáveis e tenham cópias de backup salvas nos servidores do Google. Se optar por também usar sua conta Gmail ou G Suite para os e-mails de entrada, você terá todos os seus e-mails em um lugar conveniente. Além disso, como o servidor SMTP do Google não usa a porta 25, a probabilidade de um ISP bloquear algum e-mail seu ou sinalizá-lo como spam será reduzida.

      Configurações

      O servidor SMTP do Google exige autenticação, então aqui está como configurá-la em seu cliente ou aplicativo de e-mail:

      Nota: Antes de começar, considere investigar a classificação de segurança do seu cliente ou aplicativo de e-mail, de acordo com o Google. Se você estiver usando um programa que o Google não considera seguro, seu uso será bloqueado a menos que você habilite aplicativos menos seguros (uma configuração de segurança que o Google não recomenda) ou gere uma senha de aplicativo específica do aplicativo. Para obter mais informações de segurança, consulte este link para determinar a melhor abordagem para seu cliente ou aplicativo de e-mail.

      1. Servidor SMTP (ou seja, servidor de e-mail de saída): smtp.gmail.com
      2. Nome de usuário SMTP: seu endereço de e-mail completo do Gmail ou G Suite (por exemplo, [email protected] ou example@your_domain)
      3. Senha SMTP: A senha do seu e-mail Gmail ou G Suite
      4. Porta SMTP: 465
      5. TLS/SSL necessário: sim do SMTP

      Para que o Google copie automaticamente seus e-mails enviados para a pasta enviados, também é necessário verificar se o acesso IMAP está habilitado para sua conta.

      Para fazer isso, vá para as configurações do Gmail e clique na guia Encaminhamento e POP/IMAP. Role para baixo até a seção Acesso IMAP e certifique-se de que o acesso IMAP está habilitado para sua conta.

      Nota: o Google irá substituir automaticamente a linha De de qualquer e-mail que você enviar através do seu servidor SMTP pelo endereço de e-mail padrão associado à conta se o endereço usado não estiver na lista de endereços Enviar e-mail como nas configurações do Gmail ou G Suite. Verifique a lista indo até a guia Contas e importação na tela de configurações.

      Esteja ciente desse detalhe, pois ele afeta a apresentação do seu e-mail do ponto de vista do destinatário, e pode também afetar a configuração Responder a de alguns programas.

      Limites de envio

      O Google limita a quantidade de e-mails que um usuário pode enviar através do seu servidor SMTP portátil. Esse limite restringe o número de mensagens enviadas por dia para até 99 e-mails; a restrição é removida automaticamente 24 horas após você atingir o limite.

      Conclusão

      Agora, você tem a opção de usar o servidor SMTP do Google. Se essa opção leve não for suficiente, considere instalar e configurar o postfix como um servidor SMTP apenas para envio.



      Source link

      Cómo usar SFTP para transferir archivos con un servidor remoto de manera segura


      Introducción

      FTP, o “File Transfer Protocol” (Protocolo de transferencia de archivos), era un método popular sin cifrar para transferir archivos entre dos sistemas remotos.

      SFTP, que significa Protocolo de transferencia de archivos SSH o Protocolo de transferencia segura de archivos, es un protocolo independiente empaquetado con SSH que funciona de forma similar pero a través de una conexión segura. La ventaja es la capacidad de aprovechar una conexión segura para transferir archivos y recorrer el sistema de archivos en los sistemas local y remoto.

      En casi todos los casos, es preferible usar SFTP, en vez de FTP, debido a sus características de seguridad subyacentes y a su capacidad para aprovechar una conexión SSH. FTP es un protocolo no seguro que solo debería utilizarse en casos limitados o en redes de confianza.

      Aunque SFTP está integrado en muchas herramientas gráficas, esta guía mostrará cómo utilizarlo en su interfaz de línea de comandos interactiva.

      Cómo conectarse con SFTP

      De forma predeterminada, SFTP utiliza el protocolo SSH para autenticarse y establecer una conexión segura. Por eso, están disponibles los mismos métodos de autenticación que en SSH.

      Aunque las contraseñas son fáciles de usar y se configuran de forma predeterminada, le recomendamos crear claves SSH y transferir su clave pública a cualquier sistema al que necesite acceder. Eso es mucho más seguro y puede ahorrarle tiempo a largo plazo.

      Consulte esta guía para configurar claves SSH para acceder a su servidor si aún no lo hizo.

      Si puede conectarse al equipo usando SSH, habrá completado todos los requisitos necesarios para usar SFTP para administrar archivos. Pruebe el acceso SSH con el siguiente comando:

      • ssh sammy@your_server_ip_or_remote_hostname

      Si esto funciona, salga de nuevo escribiendo:

      Ahora, podemos establecer una sesión SFTP ejecutando el siguiente comando:

      • sftp sammy@your_server_ip_or_remote_hostname

      Conectará el sistema remoto, y la entrada de su línea de comandos cambiará a una instrucción SFTP.

      Si está trabajando en un puerto SSH personalizado (no el puerto 22 predeterminado), puede iniciar una sesión SFTP de la siguiente manera:

      • sftp -oPort=custom_port sammy@your_server_ip_or_remote_hostname

      Eso lo conectará al sistema remoto mediante el puerto especificado.

      Cómo obtener ayuda en SFTP

      El comando más útil que debe conocer primero es el comando help. Este comando le da acceso a un resumen de la ayuda en SFTP. Puede invocarlo escribiendo cualquiera de estos en la instrucción:

      o

      Eso mostrará una lista de los comandos disponibles:

      Output

      Available commands: bye Quit sftp cd path Change remote directory to 'path' chgrp grp path Change group of file 'path' to 'grp' chmod mode path Change permissions of file 'path' to 'mode' chown own path Change owner of file 'path' to 'own' df [-hi] [path] Display statistics for current directory or filesystem containing 'path' exit Quit sftp get [-Ppr] remote [local] Download file help Display this help text lcd path Change local directory to 'path' . . .

      En las siguientes secciones, exploraremos algunos de los comandos que verá.

      Cómo navegar con SFTP

      Podemos navegar a través de la jerarquía de archivos del sistema remoto usando varios comandos que funcionan de forma similar a sus contrapartes de shell.

      Primero, orientémonos averiguando en qué directorio estamos actualmente en el sistema remoto. Al igual que en una sesión típica de shell, podemos escribir lo siguiente para obtener el directorio actual:

      Output

      Remote working directory: /home/demouser

      Podemos ver el contenido del directorio actual del sistema remoto con otro comando familiar:

      Output

      Summary.txt info.html temp.txt testDirectory

      Tenga en cuenta que los comandos en la interfaz SFTP no son los comandos de shell normales y no cuentan con la misma cantidad de funciones, pero implementan algunos de los indicadores opcionales más importantes:

      Output

      drwxr-xr-x 5 demouser demouser 4096 Aug 13 15:11 . drwxr-xr-x 3 root root 4096 Aug 13 15:02 .. -rw------- 1 demouser demouser 5 Aug 13 15:04 .bash_history -rw-r--r-- 1 demouser demouser 220 Aug 13 15:02 .bash_logout -rw-r--r-- 1 demouser demouser 3486 Aug 13 15:02 .bashrc drwx------ 2 demouser demouser 4096 Aug 13 15:04 .cache -rw-r--r-- 1 demouser demouser 675 Aug 13 15:02 .profile . . .

      Para llegar a otro directorio, podemos ejecutar este comando:

      Ahora, podemos recorrer el sistema de archivos remotos, pero ¿qué pasa si necesitamos acceder a nuestro sistema de archivos local? Podemos dirigir los comandos al sistema de archivos locales precediéndolos con una l que hace referencia a “local”.

      Todos los comandos examinados hasta ahora tienen equivalentes locales. Podemos imprimir el directorio local de trabajo:

      Output

      Local working directory: /Users/demouser

      Podemos enumerar el contenido del directorio actual en el equipo local:

      Output

      Desktop local.txt test.html Documents analysis.rtf zebra.html

      También podemos cambiar el directorio con el que deseamos interactuar en el sistema local:

      Cómo transferir archivos con SFTP

      Navegar por los sistemas de archivos locales y remotos es muy poco útil si no se puede transferir archivos entre ambos.

      Transferencia de archivos remotos al sistema local

      Si queremos descargar archivos de nuestro host remoto, podemos hacerlo ejecutando el siguiente comando:

      Output

      Fetching /home/demouser/remoteFile to remoteFile /home/demouser/remoteFile 100% 37KB 36.8KB/s 00:01

      Como puede ver, de forma predeterminada, el comando get descarga un archivo remoto a un archivo con el mismo nombre en el sistema de archivos locales.

      Podemos copiar el archivo remoto a un nombre diferente especificando el nombre después:

      El comando get también toma algunos indicadores de opción. Por ejemplo, podemos copiar un directorio y todo su contenido especificando la opción recursiva:

      Podemos indicarle a SFTP que mantenga los permisos y los tiempos de acceso adecuados utilizando el indicador -P o -p:

      Transferencia de archivos locales al sistema remoto

      Transferir archivos al sistema remoto es tan fácil como utilizar el comando correctamente llamado “put”:

      Output

      Uploading localFile to /home/demouser/localFile localFile 100% 7607 7.4KB/s 00:00

      Los mismos indicadores que funcionan con get se aplican a put. Para copiar un directorio local completo, puede ejecutar:

      Nota: Actualmente, hay un error en las versiones de OpenSSH incluidas en las versiones actuales de Ubuntu (al menos de la versión 14.04 a la 15.10) que impide que el comando anterior funcione correctamente. Cuando se ejecuta el comando anterior para transferir contenido a un servidor utilizando la versión con errores de OpenSSH, se producirá el siguiente error: Couldn't canonicalise: No such file or directory (No se pudo canonizar: no existe tal archivo o directorio).

      Para resolver este problema, primero cree el directorio de destino en el extremo remoto escribiendo mkdir localDirectory. Luego, el comando anterior debería completarse sin errores.

      Una herramienta familiar que es útil para descargar y cargar archivos es el comando df, que funciona de forma similar a la versión de la línea de comandos. Al utilizarla, puede verificar que tiene suficiente espacio para completar las transferencias que le interesan:

      Output

      Size Used Avail (root) %Capacity 19.9GB 1016MB 17.9GB 18.9GB 4%

      Tenga en cuenta que no hay ninguna variación local de este comando, pero podemos solucionarlo ejecutando ! como comando.

      El comando ! nos lleva a un shell local, donde podemos ejecutar cualquier comando disponible en nuestro sistema local. Podemos verificar el uso del disco escribiendo lo siguiente:

      y luego

      Output

      Filesystem Size Used Avail Capacity Mounted on /dev/disk0s2 595Gi 52Gi 544Gi 9% / devfs 181Ki 181Ki 0Bi 100% /dev map -hosts 0Bi 0Bi 0Bi 100% /net map auto_home 0Bi 0Bi 0Bi 100% /home

      Cualquier otro comando local funcionará de la manera esperada. Para volver a su sesión SFTP, escriba lo siguiente:

      Ahora, debería ver el retorno de la instrucción de SFTP.

      Manipulaciones de archivos simples con SFTP

      SFTP le permite realizar el tipo de mantenimiento básico de archivos que es útil cuando se trabaja con jerarquías de archivos.

      Por ejemplo, puede cambiar el propietario de un archivo en el sistema remoto con:

      Observe cómo, a diferencia del comando chmod del sistema, el comando SFTP no acepta nombres de usuario, sino que utiliza UID. Lamentablemente, no hay una manera sencilla de saber el UID adecuado desde la interfaz SFTP.

      Se puede realizar una solución alternativa más compleja con:

      • get /etc/passwd
      • !less passwd

      Output

      root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/bin/sh bin:x:2:2:bin:/bin:/bin/sh sys:x:3:3:sys:/dev:/bin/sh sync:x:4:65534:sync:/bin:/bin/sync games:x:5:60:games:/usr/games:/bin/sh man:x:6:12:man:/var/cache/man:/bin/sh . . .

      Observe cómo en vez de utilizar el comando ! en sí, lo utilizamos como prefijo para un comando de shell local. Eso funciona para ejecutar cualquier comando disponible en nuestro equipo local y podría haberse utilizado anteriormente con el comando local df.

      El UID se encuentra en la tercera columna del archivo, delimitado por caracteres de dos puntos.

      De manera similar, podemos cambiar el propietario del grupo de un archivo con:

      De nuevo, no existe una forma sencilla de obtener una lista de los grupos del sistema remoto. Podemos solucionarlo con el siguiente comando:

      • get /etc/group
      • !less group

      Output

      root:x:0: daemon:x:1: bin:x:2: sys:x:3: adm:x:4: tty:x:5: disk:x:6: lp:x:7: . . .

      La tercera columna contiene el ID del grupo asociado con el nombre en la primera columna. Eso es lo que buscamos.

      Por suerte, el comando chmod funciona correctamente en el sistema de archivos remotos:

      Output

      Changing mode on /home/demouser/publicFile

      No existe ningún comando para manipular permisos de archivo locales, pero puede quitar la máscara local para que todos los archivos que se copien al sistema local tengan los permisos adecuados.

      Eso se puede lograr con el comando lumask:

      Output

      Local umask: 022

      Ahora, todos los archivos regulares descargados (siempre que no se utilice el indicador -p) tendrán 644 permisos.

      SFTP permite crear directorios en sistemas locales y en sistemas remotos con lmkdir y mkdir, respectivamente. Estos funcionan de la manera prevista.

      El resto de los comandos del archivo solo apuntan al sistema de archivos remotos:

      Estos comandos replican el comportamiento básico de las versiones del shell. Si necesita realizar estas acciones en el sistema de archivos local, recuerde que puede ingresar a un shell ejecutando este comando:

      O ejecutar un comando único en el sistema local anteponiendo ! al comando de esta manera:

      Cuando termine con la sesión SFTP, utilice exit o bye para cerrar la conexión.

      Conclusión

      Aunque SFTP es una herramienta simple, es muy útil para administrar servidores y transferir archivos entre ellos.

      Por ejemplo, puede usar SFTP para permitir que determinados usuarios transfieran archivos sin acceso SSH. Para obtener más información sobre este proceso, consulte nuestro tutorial Cómo habilitar SFTP sin acceso de shell.

      Si está acostumbrado a utilizar FTP o SCP para realizar sus transferencias, SFTP es una buena forma de aprovechar las ventajas de ambos. Si bien no es adecuado para todas las situaciones, es útil tenerlo en su repertorio por ser una herramienta flexible.



      Source link