Este é o daemon de controle da conexão encriptada via protocolo ssh,
transferência de arquivos e shell interativo. As opções de linha de comando
estão disponíveis em “Opções de linha de comando”. Seu arquivo de
configuração principal é /etc/ssh/sshd_config, um exemplo
e descrição das opções deste arquivo é encontrada em “Exemplo de sshd_config com explicações das diretivas”.
OBS1: É recomendável que o arquivo
/etc/ssh/sshd_config seja lido somente pelo dono/grupo,
por conter detalhes de acesso de usuários, grupos e intervalo entre a geração
de chave de seção.
OBS2: Se estiver ocorrendo falhas no acesso
ao servidor ssh, verifique as permissões nos arquivos
/etc/hosts.allow e /etc/hosts.deny (o
nome do serviço é sshd). Mesmo operando como daemon, o
servidor utiliza estes arquivos para fazer um controle de acesso adicional.
É definido pelas opções ListenAddress,
AllowUsers, DenyUsers,
AllowGroups, DenyGroups e
PermitRootLogin do arquivo de configuração
sshd_config (veja “Exemplo de sshd_config com explicações das diretivas”) e via tcpd (arquivos
hosts.allow e hosts.deny). Veja
“O mecanismo de controle de acessos tcpd”.
Este método de autenticação utiliza o par de chaves pública (que será
distribuído nas máquinas que você conecta) e outra privada (que ficará em seu
diretório pessoal) para autenticação. A encriptação e decriptação são feitas
usando chaves separadas e não é possível conseguir a chave de decriptação
usando a chave de encriptação. É possível inclusive gerar uma chave sem senha
para efetuar o logon em um sistema ou execução de comandos remotos (este
esquema é um pouco mais seguro que os arquivos ~/.rhosts e
~/.shosts).
Siga os seguintes passos para se autenticar usando RSA 1 - usada na versão 1 do ssh:
Gere um par de chaves pública/privada usando o comando:
ssh-keygen
Um par de chaves RSA versão 1 será gerado com o tamanho de 1024 bits por
padrão, garantindo uma boa segurança/performance, e salvas no diretório
~/.ssh com o nome identity e
identity.pub. Para alterar o tamanho da chave use a opção
-b tamanho. Depois de gerar a chave, o
ssh-keygen pedirá uma frase-senha (é
recomendável ter um tamanho maior que 10 caracteres e podem ser incluídos
espaços). Se não quiser digitar uma senha para acesso ao sistema remoto, tecle
<Enter> quando perguntado. Mude as permissões do diretório
~/.ssh para 750.
A opção -f especifica o diretório e nome das chaves. A
chave pública terá a extensão .pub adicionada ao nome
especificado.
ATENÇÃO Nunca distribua sua chave privada, nem armazene-a em servidores de acesso públicos ou outros métodos que permitem outros terem acesso a ela. Se precisar de uma cópia de segurança, faça em disquetes e guarde-a em um lugar seguro.
Instale a chave pública no servidor remoto que deseja se conectar, por exemplo,
www.sshserver.org:
ssh-copy-id -i ~/.ssh/identity gleydson@www.servidorssh.org
A função do utilitário acima é entrar no sistema remoto e adicionar a chave
pública local ~/.ssh/identity.pub no arquivo
/home/gleydson/.ssh/authorized_keys do sistema remoto
www.sshserver.org. O mesmo processo poderá ser feito
manualmente usando os métodos tradicionais
(ssh/scp). Caso o arquivo remoto
/home/gleydson/.ssh/authorized_keys não existe, ele será
criado. Seu formato é idêntico ao ~/.ssh/know_hosts e
contém uma chave pública por linha.
Agora utilize o ssh para entrar no sistema remoto usando o método de chave pública/privada. Entre com a senha que usou para gerar o par de chaves público/privado (ele entrará diretamente caso não tenha digitado uma senha).
Para autenticar em uma versão 2 do ssh (usando chave RSA 2 ou DSA):
Gere um par de chaves pública/privada usando o comando:
ssh-keygen -t rsa -f ~/.ssh/id_rsa ou ssh-keygen -t dsa -f ~/.ssh/id_rsa
Um par de chaves RSA 2/DSA será gerado. Para alterar o tamanho da chave use a
opção -b tamanho. Depois de gerar a chave, o
ssh-keygen pedirá uma frase-senha (é
recomendável ter um tamanho maior que 10 caracteres e podem ser incluídos
espaços). Se não quiser digitar uma senha para acesso ao sistema remoto, tecle
<Enter> quando perguntado. Mude as permissões do diretório
~/.ssh para 750.
ATENÇÃO Nunca distribua sua chave privada, nem armazene-a em servidores de acesso públicos ou outros métodos que permitem outros terem acesso a ela. Se precisar de uma cópia de segurança, faça em disquetes e guarde-a em um lugar seguro.
Instale a chave pública no servidor remoto que deseja se conectar copiando o arquivo com:
scp ~/.ssh/id_rsa.pub usuario@servidorremoto:~/.ssh/authorized_keys2 ou scp ~/.ssh/id_dsa.pub usuario@servidorremoto:~/.ssh/authorized_keys2 (caso tenha gerado a chave com a opção -t dsa)
Caso o arquivo remoto /home/gleydson/.ssh/authorized_keys2
não existe, ele será criado. Seu formato é idêntico ao
~/.ssh/know_hosts2 e contém uma chave pública por linha.
Agora utilize o ssh para entrar no sistema remoto usando o método de chave pública/privada. Entre com a senha que usou para gerar o par de chaves público/privado (ele entrará diretamente caso não tenha digitado uma senha).
OBS: Deverá ser levado em consideração a possibilidade de acesso físico ao seu diretório pessoal, qualquer um que tenha posse de sua chave privada poderá ter acesso ao sistema remoto. O tipo de chave criada por padrão é a rsa1 (compatível com as versões 1 e 2 do ssh). A opção -t [chave] poderá ser usada (ao gerar a chave) para selecionar o método de criptografia:
rsa1 - Cria uma chave rsa compatível com a versão 1 e 2 do
ssh (esta é a padrão).
rsa - Cria uma chave rsa compatível somente com a versão 2 do ssh.
dsa - Cria uma chave dsa compatível somente com a versão 2 do ssh.
Para trocar a senha utilize o comando: ssh-keygen -p -t tipo_chave -f
~/.ssh/identity - será pedida sua senha antiga e a nova senha (no
mesmo estilo do passwd). Opcionalmente você pode utilizar a
sintaxe: ssh-keygen -p -f ~/.ssh/identity -P senha_antiga -N
senha_nova, que troca a senha em um único comando (útil para ser
usado em scripts junto com a opção -q para evitar a
exibição de mensagens de saída do ssh-keygen).
Com o uso de chaves também é possível o uso do ssh para
execução de comandos específicos em máquinas remotas, isto é possível com os
novos recursos da versão 3 do ssh. Para fazer isto, siga os
passos “Usando autenticação RSA/DSA - chave pública/privada” para gerar um par de chaves
DSA (o par RSA não aceita execução de
comandos específicos) e copiar para authorized_keys2.
Após isto, entre no servidor remoto e edite a chave, inserindo o comando que
deverá ser executado antes da linha dds, por exemplo:
command="ls / -la" ssh-dss ABCAB3NzaC5555MAAACBAL3...
Com este método é possível restringir a execução de alguns comandos/serviços além de outras possibilidades como a mudança de variáveis específicas para o comando:
no-port-forwarding,no-X11-forwarding,no-agent-forwarding,command="ls / -la" ssh-dss ABCAB3NzaC1kc55355MAADBBYLp...
Imagine quando você deseja ter acesso a uma máquina de sua rede interna que esteja atrás de um gateway, isto é possível usando os recursos explicados em “Execução de comandos específicos usando chaves” fazendo um redirecionamento de acesso para seu usuário da seguinte forma:
command="ssh -t usuario@maquina.interna" ssh-dss DAK874CKLDSAUE83da9x...
Isto o acesso do usuário ser redirecionado automaticamente quando efetuar o logon. Caso tenha definido uma senha para a chave DSA, o usuário deverá fornecer a senha para entrar no gateway e outra para acessar sua estação de trabalho.
OBS: Não estou levando em conta as considerações de segurança que este exemplo tem em sua rede, bem como o que pode ou não ser redirecionado. A intenção foi manter a simplicidade para entender sem dificuldades como isto é feito.
Aplicações remotas podem ser abertas localmente com o uso desta técnica. Você poderá usar para acessar portas que estariam disponíveis somente através do endereço remoto, realizar conexões criptografadas ou com compactação (garantindo uma boa taxa de transferência para protocolos que usem mais texto).
Por exemplo, para redirecionar o tráfego da porta 80 do servidor remoto para a porta 2003 local:
ssh -l seu_login servidor -L2003:servidor_remoto:80 -f sleep 60
O sleep 60 tem a função de apenas deixar o tunel aberto por
60 segundos, tempo suficiente para realizarmos nossa conexão. Agora, entre no
seu navegador local e acesse a porta 2003:
http://localhost:2003
A opção -C também pode ser especificada junto ao ssh para usar compactação dos dados da conexão. Como notou, este recurso também é útil para fazer a administração remota de máquinas, porque o que está realizando a conexão será o IP do servidor remoto, não o seu. Da mesma forma, você poderá ter problemas caso não tenha uma boa política de distribuição de contas de máquinas em sua rede. Veja Capítulo 11, Gerenciamento de contas e cuidados para a proteção de senhas para detalhes .
Retirada da página de manual do sshd:
Cada servidor possui uma chave RSA específica (1024 bits por padrão) usada para
identifica-lo. Quando o sshd inicia, ele gera uma chave RSA do servidor (768
bits por padrão, valor definido por ServerKeyBits) que é recriada a cada hora
(modificado por KeyRegenerationInterval no sshd_config) e
permanece sempre residente na RAM.
Quando um cliente se conecta o sshd responde com sua chave pública da máquina e
chaves do servidor. O cliente ssh compara a chave RSA com seu banco de dados
(em ~/.ssh/know_hosts) para verificar se não foi
modificada.
Estando tudo OK, o cliente gera um número aleatório de 256 bits, o encripta usando ambas as chaves de máquina e chave do servidor e envia este número ao servidor. Ambos os lados então usam este número aleatório como chave de seção que é usado para encriptar todas as comunicações seguintes na seção.
O resto da seção usa um método de embaralhamento de dados convencional, atualmente Blowfish ou 3DES (usado como padrão). O cliente seleciona o algoritmo de criptografia que será usado de um destes oferecidos pelo servidor. Após isto o servidor e cliente entram em um diálogo de autenticação. O cliente tenta se autenticar usando um dos seguintes métodos de autenticação:
~/.rhosts ou ~/.shosts (normalmente
desativada).
~/.rhosts ou ~/.shosts combinado com
autenticação RSA (normalmente desativada).
Autenticação RSA por resposta de desafio.
Autenticação baseada em senha.
A autenticação usando Rhosts normalmente é desativada por ser muito insegura mas pode ser ativada no arquivo de configuração do servidor se realmente necessário. A segurança do sistema não é melhorada a não ser que os serviços rshd, rlogind, rexecd e rexd estejam desativados (assim, o rlogin e rsh serão completamente desativados na máquina).
A versão 2 funciona de forma parecida com a 1: Cada máquina possui uma chave RSA/DSA específica usada para se identificar. A diferença é que quando o sshd inicia, ele não gera uma chave de servidor. A segurança de redirecionamento é oferecida através da concordância do uso de uma chave Diffie-Hellman. Esta concordância de chave resulta em uma seção com chave compartilhada. O resto da seção é encriptada usando um algoritmo simétrico, como Blowfish, 3DES, CAST128, Arcfour, 128 bit AES, ou 256 bit AES.
O cliente que seleciona o algoritmo de criptografia que será usado entre os oferecidos pelo servidor. A versão 2 também possui integridade de seção feita através de um código de autenticação de mensagem criptográfica (hmac-sha1 ou hmac-md5). A versão 2 do protocolo oferece um método de autenticação baseado em chave pública (PubkeyAuthentication) e o método de autenticação convencional usando senhas.
Abaixo segue um exemplo deste arquivo que poderá ser adaptado ao seu sistema. O objetivo é ser ao mesmo tempo útil para sua configuração e didático:
# Modelo personalizado para o guia Foca GNU/Linux baseado na configuração # original do FreeBSD. # Autor: Gleydson Mazioli da Silva # Data: 20/09/2001. # Porta padrão usada pelo servidor sshd. Múltiplas portas podem ser # especificadas separadas por espaços. Port 22 # Especifica o endereço IP das interfaces de rede que o servidor sshd # servirá requisições. Múltiplos endereços podem ser especificados # separados por espaços. A opção Port deve vir antes desta opção ListenAddress 0.0.0.0 # Protocolos aceitos pelo servidor, primeiro será verificado se o cliente é # compatível com a versão 2 e depois a versão 1. Caso seja especificado # somente a versão 2 e o cliente seja versão 1, a conexão será descartada. # Quando não é especificada, o protocolo ssh 1 é usado como padrão. Protocol 2,1 # As 4 opções abaixo controlam o acesso de usuários/grupos no sistema. # Por padrão o acesso a todos é garantido (exceto o acesso root se # PermitRootLogin for "no"). AllowUsers e AllowGroups definem uma lista # de usuários/grupos que poderão ter acesso ao sistema. Os coringas # "*" e "?" podem ser especificados. Note que somente NOMES são válidos, # UID e GID não podem ser especificados. # # As diretivas Allow são processadas primeiro e depois Deny. O método que # estas diretivas são processadas é idêntico a diretiva # "Order mutual-failure" do controle de acesso do Apache: # O usuário deverá TER acesso via AllowUsers e AllowGroups e NÃO ser bloqueado # por DenyUsers e DenyGroups para ter acesso ao sistema. Se uma das diretivas # não for especificada, "*" é assumido como padrão. # Estas permissões são checadas após a autenticação do usuário, porque # dados a ele pelo /etc/passwd e PAM são obtidos após o processo de # autenticação. #AllowUsers gleydson teste? #DenyUsers root adm #AllowGroups users #DenyGroups root adm bin # Permite (yes) ou não (no) o login do usuário root PermitRootLogin no # Chaves privadas do servidor (as chaves públicas possuem um ".pub" adicionado # no final do arquivo. HostKey /etc/ssh/ssh_host_key HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key # Tamanho da chave. 768 bits é o padrão ServerKeyBits 768 # Tempo máximo para login no sistema antes da conexão ser fechada LoginGraceTime 600 # Tempo para geração de nova chave do servidor (segundos). O padrão é # 3600 segundos (1 hora). KeyRegenerationInterval 3600 # Ignora os arquivos ~/.rhosts e ~/.shosts IgnoreRhosts yes # Ignora (yes) ou não (no) os arquivos ~/.ssh/known_hosts quando for usado # para a opção RhostsRSAAuthentication. Se você não confia neste mecanismo # ajuste esta opção para yes. IgnoreUserKnownHosts no # Checa por permissões de dono dos arquivos e diretório de usuário antes de # fazer o login. É muito recomendável para evitar riscos de segurança # com arquivos lidos por todos os usuários. StrictModes yes # Permite (yes) ou não (no) o redirecionamento de conexões X11. A segurança # do sistema não é aumentada com a desativação desta opção, outros métodos # de redirecionamento podem ser usados X11Forwarding yes # Especifica o número do primeiro display que será usado para o redirecionamento # X11 do ssh. Por padrão é usado o display 10 como inicial para evitar conflito # com display X locais X11DisplayOffset 10 # Mostra (yes) ou não (no) a mensagem em /etc/motd no login. O padrão é "no". PrintMotd no # Mostra (yes) ou não (no) a mensagem de último login do usuário. O padrão é "no". PrintLastLog no # Permite (yes) ou não (no) o envio de pacotes keepalive (para verificar se o # cliente responde. Isto é bom para fechar conexões que não respondem mas # também podem fechar conexões caso não existam rotas para o cliente # naquele momento (é um problema temporário). Colocando esta opção como # "no" por outro lado pode deixar usuários que não tiveram a oportunidade # de efetuar o logout do servidor dados como "permanentemente conectados" # no sistema. Esta opção deve ser ativada/desativada aqui e no programa # cliente para funcionar. KeepAlive yes # Facilidade e nível das mensagens do sshd que aparecerão no syslogd SyslogFacility AUTH LogLevel INFO # Especifica se somente a autenticação via arquivos ~/.rhosts e /etc/hosts.equiv é # suficiente para entrar no sistema. Não é muito bom usar "yes" aqui. RhostsAuthentication no # Mesmo que o acima com o acréscimo que o arquivo /etc/ssh/ssh_known_hosts também # é verificado. Também evite usar "yes" aqui. RhostsRSAAuthentication no # Especifica se a autenticação via RSA é permitida (só usado na versão 1 do # protocolo ssh). Por padrão "yes". RSAAuthentication yes # Permite autenticação usando senhas (serve para ambas as versões 1 e 2 do ssh). # O padrão é "yes". PasswordAuthentication yes # Se a PasswordAuthentication for usada, permite (yes) ou não (no) login # sem senha. O padrão é "no". PermitEmptyPasswords no # Ativa senhas s/key ou autenticação PAM NB interativa. Nenhum destes é # compilado por padrão junto com o sshd. Leia a página de manual do # sshd antes de ativar esta opção em um sistema que usa PAM. ChallengeResponseAuthentication no # Verifica se o usuário possui emails ao entrar no sistema. O padrão é "no". # Este módulo também pode estar sendo habilitado usando PAM (neste caso # cheque a configuração em /etc/pam.d/ssh). CheckMail no # Especifica se o programa login é usado para controlar a seções de shell # interativo. O padrão é "no". UseLogin no # Especifica o número máximo de conexões de autenticação simultâneas feitas # pelo daemon sshd. O valor padrão é 10. Valores aleatórios podem ser # especificados usando os campos "inicio:taxa:máximo". Por exemplo, # 5:40:15 rejeita até 40% das tentativas de autenticação que excedam o # limite de 5 até atingir o limite máximo de 15 conexões, quando # nenhuma nova autenticação é permitida. MaxStartups 10 #MaxStartups 10:30:60 # Mostra uma mensagem antes do nome de usuário/senha Banner /etc/issue.net # Especifica se o servidor sshd fará um DNS reverso para verificar se o # endereço confere com a origem (isto é útil para bloquear conexões # falsificadas - spoofing). O padrão é "no". ReverseMappingCheck yes # Ativa o subsistema de ftp seguro. Para desabilitar comente a linha # abaixo Subsystem sftp /usr/lib/sftp-server
Copyright © 1999-2020 - Gleydson Mazioli da Silva