ago 082020
 

Limpar todo Histórico do root via ssh (linha de comando) no CentOS

Fala pessoal, hoje vamos deixar mais essa dicar para nossos visitantes e clientes.

O comando é simples, veja:

cat /dev/null > ~/.bash_history && history -c && exit

Entendendo o comando:
~/.bash_history  – é responsável por armazenar todas as linhas de comando executadas;
cat /dev/null > ~/.bash_history  – você está nulificando o conteúdo do “bash_history“;
history -c  – você está limpando inclusive a linha usada para nulificar o histórico usada anteriormente;
exit – você desconecta do usuário sem deixar rastros.

Valeu pessoal, espero ter ajudado!

set 262017
 
Como fazer ssh com chaves pública e privada usando o programa PuTTY

Gerando as chaves publica e privada

Com a implantação da autenticação por chave, precisaremos usar o programa PuTTYGen para gerar a sua chave de acesso a sua conta.

  1. Baixe o programa PuTTYGen e salve em um local de sua preferência.
  2. Execute o programa. Você deverá ver a seguinte tela:

    Continue reading »

VPN – usando SSH

 Leitura Recomendada, Redes, Segurança, Vpn  Comentários desativados em VPN – usando SSH
abr 112014
 
Introdução e configuração do servidor

SSH normalmente é usado com a principal finalidade que é o acesso remoto, porém, com esta poderosa ferramenta, há mais coisas que podem ser feitas, uma delas é criar túneis encriptados temporários e uma VPN real.

Neste artigo irei abordar como configurar seu servidor SSH para rodar como um servidor VPN para conexão ponto a ponto. Não se trata de um configuração trabalhosa.

O túnel que será criado irá utilizar a interface TUN/TAP, nos exemplos utilizaremos a TAP para estabelecer a conexão entre cliente e servidor

Chega de papo e vamos à prática!!!!

O primeiro passo é editar o arquivo “/etc/ssh/sshd_config” no servidor (você pode usar o próprio SSH para acessar e depois editar o arquivo), adicionando a linha abaixo no arquivo:

PermitTunnel yes

É necessário também que a linha “PermitRootLogin = yes” esteja presente, já que, por segurança, apenas o ‘root’ pode criar a VPN.  Continue reading »

Backups remotos com rSync e chaves SSH

 Leitura Recomendada, Linux, Sistemas de Armazenamento  Comentários desativados em Backups remotos com rSync e chaves SSH
abr 062014
 

rSync e comandos / SSH e automatização

rSync e alguns comandos

rSync, assim como o SCP, são ótimas ferramentas para transferências de arquivos entre máquinas, porém, possuem uma deficiência, eles são inseguros.

Originalmente, o rSync não utiliza nenhuma forma de criptografia, o que o torna um tanto ineficaz para backups via Internet. Entretanto, este problema pode ser facilmente resolvido, utilizando o nosso “canivete suíço” SSH como meio de transporte, possibilitando automatizar a tarefa com um script básico.  Continue reading »

VPN Usando SSH

 Firewall, Linux, Redes, Segurança  Comentários desativados em VPN Usando SSH
out 022013
 
Introdução e configuração do servidor

SSH normalmente é usado com a principal finalidade que é o acesso remoto, porém, com esta poderosa ferramenta, há mais coisas que podem ser feitas, uma delas é criar túneis encriptados temporários e uma VPNreal.Neste artigo irei abordar como configurar seu servidor SSH para rodar como um servidor VPN para conexão ponto a ponto. Não se trata de um configuração trabalhosa.

O túnel que será criado irá utilizar a interface TUN/TAP, nos exemplos utilizaremos a TAP para estabelecer a conexão entre cliente e servidor

Chega de papo e vamos à prática!!!!

O primeiro passo é editar o arquivo “/etc/ssh/sshd_config” no servidor (você pode usar o próprio SSH para acessar e depois editar o arquivo), adicionando a linha abaixo no arquivo:

PermitTunnel yes

É necessário também que a linha “PermitRootLogin = yes” esteja presente, já que, por segurança, apenas o ‘root’ pode criar a VPN.

Se você não quer permitir logins como ‘root’ devido à questão da segurança, uma opção é combiná-la com a linha “PermitRootLogin = forced- commands-only”, como em:

PermitRootLogin = yes
PermitRootLogin = forced-commands-only Continue reading »

SSH – Tradução da man page

 Clusterweb, Leitura Recomendada, Linux  Comentários desativados em SSH – Tradução da man page
mar 082013
 
Sinopse / Descrição

Nome:

SSH – Cliente OpenSSH SSH (programa de login remoto)

Sinopse:

ssh [ -1246AaCfgKkMNnqsTtVvXxYy ] [ -b bind_address ][ -c cipher_spec ]
[ -D [bind_address:]port][ -e escape_char ][ -F configfile ][ -i identity_file ]
[ -L [bind_address:]port:host:hostport][ -l login_name ][ -m mac_spec ]
[ -O ctl_cmd ][ -o option ][ -p port ][ -R [bind_address:]port:host:hostport]
[ -S ctl_path ][ -w local_tun [:remote_tun]] [[email protected]]hostname [ command ]

Descrição:

O SSH (cliente SSH) é um programa para conectar-se e executar comandos em máquina remota. É proposital substituir o “rlogin” e o “rsh” e prover comunicações criptografadas de forma segura entre dois hosts não confiáveis sobre uma rede não segura. As conexões X11 e portas TCP arbitrárias, também podem ser encaminhadas através do canal seguro.

O SSH conecta-se e faz o login em um hostname específico (com nome de usuário opcional). O usuário deve provar sua identidade à máquina remota usando um dos vários métodos, dependendo da versão usada do protocolo (veja abaixo).

Se o comando é especificado, ele é executado em um host remoto ao invés de um acesso shell.

As opções estão a seguir:

-1 :: Obriga o SSH a tentar somente a versão 1 do protocolo;

-2 :: Obriga o SSH a tentar somente a versão 2 do protocolo;

-4 :: Obriga o SSH a usar somente endereços IPv4;

-6 :: Obriga o SSH a usar somente endereços IPv6;

-A :: Ativa o encaminhamento de uma conexão de autenticação de agente. Isto também pode ser especificado numa base por host em um arquivo de configuração.

O agente encaminhado deve ser ativado com cuidado. Usuários com a habilidade de ignorar arquivos de permissões em um host remoto (para o socket Unix-domain do agente) podem acessar o agente local pela conexão encaminhada.

Um atacante não pode obter material chave de um agente, porém, ele pode executar operações nas chaves que permite sua autenticação usando identidades carregadas no agente.

-a :: Desativa o encaminhamento da conexão da autenticação do agente;

-b bind_address :: Usa bind_address na máquina local como o endereço origem da conexão. É útil somente em sistemas com mais de um endereço.

-C :: Requer compressão de todos os dados (incluindo stdin, stdout, stderr, e dados encaminhados via X11 e conexões TCP). O algoritmo de compressão é o mesmo usado pelo gzip(1), e o “nível” pode ser controlado pela opção “CompressionLevel” da versão 1 do protocolo.

A compressão é desejada em linhas de modem e outras conexões mais lentas, mas irá somente diminuir as coisas em conexões rápidas. O valor padrão pode ser definido em uma base host-para-host nos arquivos de configuração.

Veja a opção compressão:

-c cipher_spec :: Seleciona a especificação de cifra para criptografar a sessão. A versão 1 do protocolo permite a especificação de uma cifra única.

Os valores suportados são “3des”, “blowfish”, e “des”:

  • O “3des” (triplo-des) é uma tripla (encripta-decripta-encripta) com três diferentes chaves. Acredita-se que seja seguro.
  • O “blowfish” é uma cifra de bloco rápida, parece ser muito seguro e bem mais rápido que o 3des.
  • O “des” é suportado somente no cliente ssh para interoperabilidade com a implementação do protocolo 1 que não suporta a cifra 3des. Seu uso é fortemente desencorajado devido às deficiências criptográficas. O padrão é o “3des”.

Para a versão 2 do protocolo, cipher_spec é uma lista de cifras separadas por vírgula listadas em ordem de preferência. Veja a palavra-chave “Ciphers” para mais informações.

-D [bind_address:]porta :: Especifica um encaminhamento de uma porta de nível de aplicação local “dinâmica”. Funciona alocando um socket para escutar a porta no lado local, opcionalmente limitado pelo específico “bind_address”.

Quando uma conexão é feita nessa porta ela é encaminhada sobre o canal seguro, e o protocolo da aplicação é depois usado para determinar onde se conectar na máquina remota.

Atualmente os protocolos SOCKS4 e SOCKS5 são suportados, e o SSH irá atuar como um servidor SOCKS. Somente o usuário root pode encaminhar portas privilegiadas. Encaminhamentos dinâmicos de portas podem ser especificados no arquivo de configuração.

Endereços IPv6 podem ser especificados com uma sintaxe alternativa:

[ bind_address/]porta

Ou colocando o endereço entre chaves. Somente o superusuário pode encaminhar portas privilegiadas. Por padrão a porta local é limitada de acordo com a configuração do GatewayPorts. Porém um “bind_address” explícito pode ser usado para ligar a conexão com o endereço específico.

O “bin_address” de “localhost” indica que a porta escutada pode ser limitada somente para o usuário local, enquanto um endereço vazio, ou ‘*’, indica que a porta deve estar disponível para todas as interfaces.

-e escape_char :: Define o caractere de escape para sessões com tty (default: “~”). O caractere de escape é somente reorganizado no começo de uma linha. Se o caractere de escape for seguido por um ponto (‘.’) fecha a conexão; seguido por Ctrl-Z suspende a conexão; e seguido por si mesmo envia o caractere de escape uma vez. Definindo o caractere como “none”/”nenhum” desativa quaisquer escapes e torna a sessão completamente transparente.

-F configfile :: Especifica um arquivo de configuração alternativo por usuário. Se um arquivo de configuração é passado por linha de comando, o arquivo de configuração de todo o sistema (/etc/ssh/ssh_config) será ignorado. O padrão para um arquivo de configuração por usuário é: ~/.ssh/config.

-f :: Pede para o SSH ir para background antes da execução do comando. É útil se o SSH vai perguntar por senhas ou frases secretas, mas o usuário o quer em background. Isto implica em “-n”. O modo recomendado para iniciar programas X11 em um site remoto é com alguma coisa do tipo: ssh -f host xterm.

Se a opção de configuração “ExitOnForwardFailure” for definida como “yes”, logo, um cliente iniciado com “-f” irá esperar por todos os encaminhamentos das portas remotas serem estabelecidas com sucesso antes de colocarem a si mesmos em background.

-g :: Permite hosts remotos conectarem-se à portas de encaminhamento locais.

-I smartcard_device :: Especifica o dispositivo que SSH deve usar para se comunicar com um smartcard usado para guardar a chave privada RSA dos usuários. Esta opção está disponível apenas se o suporte para dispositivos smartcards forem compilados (padrão não é suportado).

-i identity_file :: Seleciona um arquivo de onde cada identidade (chave privada) para autenticações RSA ou DAS são lidas. O padrão é ~/.ssh/identity para a versão 1 do protocolo, e ~/.ssh/id_rsa e ~/.ssh/id_dsa para a versão 2 do protocolo.

Arquivos de identidade devem ser especificados em uma base por host em um arquivo de configuração. É possível ter múltiplas opções “-i” (e múltiplas identidades especificadas em um arquivo de configuração).

-K :: Ativa a autenticação GSSAPI e encaminha (delegação) das credenciais GSSAPI para o servidor.

-k :: Desativa o encaminhamento (delegação) das credenciais GSSAPI para o servidor.

-L [bind_address:]port:host:hostport :: Especifica que a porta passada no host local (cliente) deve ser encaminhada para o host passado e porta no lado remoto.

Isso funciona basicamente alocando-se um socket para escutar uma porta no lado local, opcionalmente ligada ao “bind_address”. Sempre que uma conexão é feita nessa porta, a conexão é encaminhada sobre o canal seguro, e a conexão é feita na porta do host (host port) da máquina remota.

Encaminhamentos de portas podem ser especificados em um arquivo de configuração. Endereços IPv6 podem ser especificados com uma sintaxe alternativa:

[ bind_address/]port/host/hostport

Ou, colocando o endereço entre chaves. Somente o superusuário pode encaminhar portas privilegiadas. Por padrão, a porta local é ligada de acordo com a configuração GatewayPorts. Porém, um “bind_address” explícito pode se usado para ligar a conexão a um endereço específico.

O “bind_address” de um “localhost” indica que a porta que escuta seja ligada somente para o usuário local, enquanto um endereço vazio, ou ‘*’, indica que a porta deve estar disponível para todas as interfaces.

-l login_name :: Especifica o usuário a logar na máquina remota. Isto também pode ser especificado em uma base por host em um arquivo de configuração.

-M :: Coloca o cliente SSH no modo “master” para compartilhamento de conexão. Múltiplas opções “-M” coloca o SSH no modo “master” com confirmação necessária antes que conexões escravas sejam aceitas. Veja a descrição do ControlMaster em “ssh_config(5)” para mais detalhes.

-m mac_spec :: Adicionalmente, para o protocolo versão 2, uma lista de algoritmos MAC (código de autenticação de mensagem) separada por vírgulas pode ser especificada em ordem de preferência. Veja a palavra chave MAC para mais informações.

-N :: Não executa um comando remoto. Pode ser útil apenas para portas de encaminhamento (apenas protocolo versão 2).

-n :: Redireciona a saída “stdin” para /dev/null (na verdade, previne a leitura do “stdin”). Deve ser usado quando o SSH roda em background. Um truque comum é usar isso para executar programas X11 em uma máquina remota. Por exemplo:

$ ssh -n shadows.cs.hut.fi emacs &

Irá iniciar um Emacs em shadows.cs.hut.fi, e a conexão X11 será automaticamente encaminhada sobre um canal criptografado. O programa SSH irá ser colocado em background (isso não funciona se o SSH precisar perguntar por uma senha ou frase secreta. Veja também a opção: -f).

-O ctl_cmd :: Controla uma conexão ativa multiplexando processos mestre. Quando a opção “-O” é especificada, o argumento “ctl_cmd” é interpretado e passado para o processo mestre. Os comandos válidos são:

  • check :: Checa se o processo mestre está executando;
  • exit :: Solicita o mestre para sair.

-o option :: Pode ser usado para fornecer opções no formato usado no arquivo de configuração. Isto é útil para especificar opções que não são separadas por uma flag de linha de comando.

Para detalhes completos das opções listadas abaixo, e seus possíveis valores, veja o “ssh_config(5)”:

  • AddressFamily
  • BatchMode
  • BindAddress
  • ChallengeResponseAuthentication
  • CheckHostIP
  • Cipher
  • Ciphers
  • ClearAllForwardings
  • Compression
  • CompressionLevel
  • ConnectionAttempts
  • ConnectTimeout
  • ControlMaster
  • ControlPath
  • DynamicForward EscapeChar
  • ExitOnForwardFailure
  • ForwardAgent
  • ForwardX11
  • ForwardX11Trusted
  • GatewayPorts
  • GlobalKnownHostsFile
  • GSSAPIAuthentication
  • GSSAPIDelegateCredentials
  • HashKnownHosts
  • Host
  • HostbasedAuthentication
  • HostKeyAlgorithms
  • HostKeyAlias
  • HostName
  • IdentityFile
  • IdentitiesOnly
  • KbdInteractiveDevices
  • LocalCommand
  • LocalForward
  • LogLevel
  • MACs
  • NoHostAuthenticationForLocalhost
  • NumberOfPasswordPrompts
  • PasswordAuthentication
  • PermitLocalCommand
  • Port
  • PreferredAuthentications
  • Protocol
  • ProxyCommand
  • PubkeyAuthentication
  • RekeyLimit
  • RemoteForward
  • RhostsRSAAuthentication
  • RSAAuthentication
  • RemoteForward
  • RhostsRSAAuthentication
  • RSAAuthentication
  • SendEnv
  • ServerAliveInterval
  • ServerAliveCountMax
  • StrictHostKeyChecking
  • TCPKeepAlive
  • Tunnel
  • TunnelDevice
  • UsePrivilegedPort
  • User
  • UserKnownHostsFile
  • VerifyHostKeyDNS
  • VisualHostKey
  • XAuthLocation

-p porta :: Porta para conectar no host remoto. Isto pode ser especificado em uma base por host no arquivo de configuração.

-q :: Modo quieto. Faz com que a maioria das mensagens de aviso e diagnóstico sejam suprimidas. Apenas erros fatais são exibidos. Se um segundo “-q” é dado, então, mesmo erros fatais são suprimidos, exceto aqueles produzidos por argumentos errados.

-R [endereço_de_ligação:]porta:host:porta_do_host :: Especifica que a dada porta no host (servidor) remoto será direcionada para o host e porta dados no lado no local.

Isto funciona por meio de uma alocação de socket para escutar a porta no lado remoto, e quando a conexão é feita nesta porta, a conexão é direcionada sobre um canal seguro, e uma conexão é feita para host na porta “porta_do_host” da máquina local.

Direcionamento de portas pode também ser especificado no arquivo de configuração. Portas privilegiadas só podem ser direcionadas quando estiver logado como root na máquina remota. Endereços IPv6 podem ser especificados por meio de uma inclusão do endereço entre colchetes ou usando uma sintaxe alternativa:

[bind_address/]host/port/hostport

Por padrão o socket que está escutando no servidor será ligado para a interface de loopback somente. Isto pode ser sobrescrito especificando um endereço_de_ligação. Um endereço_de_ligação vazio, ou o endereço ‘*’, indica que o socket remoto deve escutar em todas as interfaces. Especificando um endereço_de_ligação remoto só irá ter sucesso se a opção GatewayPorts do servidor estiver habilitada (veja: ssh_config(5) ).

Se o argumento porta for ‘0’, a porta de escuta será dinamicamente alocada no servidor e reportada para o cliente em tempo de execução. Quando usado junto com “-O forward”, a porta alocada será impressa na saída padrão.

-S caminho_ctl :: Especifica a localização de um socket de controle para compartilhamento de conexão, ou a cadeia “none” para desabilitar o compartilhamento de conexão. Consulte a descrição de ControlPath e ControlMaster em ssh_config(5) para mais detalhes.

-s :: Pode ser usado para requisitar uma invocação de um subsistema no sistema remoto. Subsistemas são uma característica do protocolo SSH2 o qual facilita o uso do SSH como um transporte seguro para outras aplicações (ex.: sftp(1)). O subsistema é especificado como o comando remoto.

-T :: Desativa a alocação de pseudo-tty.

-t :: Força a alocação pseudo-tty. Isto pode ser usado para executar programas arbitrários baseados em tela em uma máquina remota, o qual pode ser muito útil, por exemplo, quando estiver implementando serviços de menu. Múltiplas opções “-t” forçam a alocação tty, mesmo se o SSH não tem um tty local.

-V :: Mostra o número da versão e sai.

-v :: Modo de detalhe. Faz o SSH imprimir mensagens de depuração sobre o seu progresso. Isto é útil para depurar problemas de conexão, autenticação e configuração. Múltiplas opções “-v” aumentam o detalhamento. O máximo é 3.

-w – local_tun[:remote_tun] :: Requisita um encaminhamento de dispositivo de encapsulamento com os dispositivos tun(4) especificados entre o cliente (local_tun) e o servidor (remote_tun).

Os dispositivos podem ser especificados por ID numérico ou pela palavra-chave “any” (qualquer), que faz utilizar o próximo dispositivo de encapsulamento disponível.

Se “remote_tun” não for especificado, “any” é utilizado por padrão. Veja também as diretivas Tunnel e TunnelDevice em ssh_config(5). Se a diretiva Tunnel estiver indefinida, será definido o modo de encapsulamento padrão, que é “point-to-point” (ponto-a-ponto).

-X :: Habilita o encaminhamento de X11. Isto pode ser especificado por host no arquivo de configuração.

O encaminhamento de X11 deve ser habilitado com cuidado. Usuários com a habilidade de contornar permissões de arquivos no host remoto (para o banco de dados de autorização X do usuário) podem acessar o display X11 local através da conexão encaminhada.

Uma pessoa pode atacar e conseguir fazer atividades como monitoramento de teclas pressionadas. Por esta razão, o encaminhamento X11 está sujeito, por padrão, à extensão de restrições X11 SECURITY (segurança).

Por favor, refira-se à opção “-Y” do SSH e a diretiva ForwardX11Trusted no “ssh_config(5)” para mais informações.

-x :: Desativa o encaminho de X11.

-Y :: Habilita o encaminhamento confiável de X11. O encaminhamento confiável de X11 não está sujeito aos controles de extensão X11 SECURITY.

-y :: Envia informações do log utilizando o módulo de sistema syslog(3). Por padrão, esta informação é enviada para stderr.

O SSH, adicionalmente, poderá obter dados de configuração de um arquivo de configuração por usuário e um arquivo abrangente do sistema. O formato do arquivo e as opções de configuração, são descritos em “ssh_config(5)”.

O SSH sai com o status de saída do comando remoto, ou com 255, se um erro ocorrer.

Autenticação

O cliente SSH do OpenSSH suporta os protocolos SSH 1 e 2. O protocolo 2 é o padrão, com SSH voltando para o protocolo 1 se detectar que o protocolo 2 não é suportado. Estas configurações podem ser alteradas usando a opção Protocol em “ssh_config(5)”, ou impostas usando as opções “-1” e “-2” (veja acima).

Ambos os protocolos suportam métodos semelhantes de autenticação, mas o protocolo 2 é preferível, pois proporciona mecanismos adicionais de confidencialidade (o tráfego é encriptado usando AES, 3DES, Blowfish, CAST128, ou Arcfour) e integridade (HMAC-MD5, HMAC-SHA1, UMAC-64, HMAC-RIPEMD160). O protocolo 1 carece de um forte mecanismo para assegurar a integridade da conexão.

Os métodos disponíveis para autenticação são:

  • Autenticação baseada em GSSAPI;
  • Autenticação baseada em host;
  • Autenticação por chave pública;
  • Autenticação desafio-resposta;
  • Autenticação por password.

Métodos de autenticação são tentados na ordem especificada acima, embora o protocolo 2 tenha uma opção de configuração para mudar a ordem padrão: “PreferredAuthentications”.

A autenticação baseada em host funciona da seguinte maneira. Se a máquina que o usuário logar estiver listada em /etc/hosts.equiv ou /etc/ssh/shosts.equiv na máquina remota, e o nome dos usuários é o mesmo em ambos os lados, ou, se os arquivos ~/.rhosts ou ~/.shosts existirem no diretório HOME do usuário na máquina remota e conter uma linha contendo o nome da máquina cliente e o nome do usuário naquela máquina, o usuário é considerado para logar.

Adicionalmente o servidor precisa ser capaz de verificar a chave de host do cliente (veja a descrição de /etc/ssh/ssh_known_hosts e ~/.ssh/known_hosts, abaixo) para o login ser permitido.

Este método de autenticação fecha buracos na segurança devido ao IP spoofing, DNS spoofing, e spoofing de roteamento.

** Nota para o administrador: /etc/hosts.equiv, ~/.rhosts e o protocolo rlogin/rsh, em geral, são inerentemente inseguros e devem ser desativados se a segurança é desejada.

A autenticação por chave pública funciona da seguinte maneira: O esquema é baseado na criptografia de chave-pública, usando criptosistemas onde a encriptação e decriptação são feitas usando chaves separadas, e é inviável derivar a chave de decriptação através da chave de encriptação.

A ideia é que cada usuário crie um par de chaves pública/privada para o propósito de autenticação. O servidor conhece a chave pública, e somente o usuário conhece a chave privada. O SSH implementa o protocolo de autenticação por chave pública automaticamente, usando o algoritmo RSA ou DAS.

O protocolo 1 é restringido a usar somente chaves RSA, mas o protocol 2 pode usar qualquer um. A seção HISTORY de “ssl(8)” (em sistemas não-OpenBSD, veja em HISTORY) contém uma breve discussão dos dois algoritmos.

O arquivo ~/.ssh/authorized_keys lista as chaves públicas que são permitidas para efetuar logon. Quando o usuário loga, o programa SSH diz ao servidor qual par de chaves gostaria de usar para a autenticação. O cliente prova que tem acesso à chave privada e o servidor checa que a chave pública correspondente está autorizada a aceitar a conta.

O usuário cria seu par de chaves executando ssh-keygen(1). Isto armazena a chave privada em ~/.ssh/identity (protocolo 1), ~/.ssh/id_dsa (protocolo 2 DSA), ou ~/.ssh/id_rsa (protocolo 2 RSA) e armazena a chave pública em ~/.ssh/identity.pub (protocolo 1), ~/.ssh/id_dsa.pub (protocolo 2 DSA), ou ~/.ssh/id_rsa.pub (protocolo 2 RSA) no diretório HOME do usuário.

O usuário deve, então, copiar a chave pública para ~/.ssh/authorized_keys em seu diretório HOME na máquina remota. O arquivo “authorized_keys” corresponde ao arquivo ~/.rhosts convencional, e tem uma chave por linha, embora as linhas podem ser muito longas. Depois disto, o usuário pode efetuar logon sem dar o password.

A maneira mais conveniente de usar autenticação por chave pública pode ser com um agente de autenticação. Veja “ssh-agent(1)” para mais informações.

A autenticação desafio-resposta funciona da seguinte maneira. O servidor envia um “desafio” arbitrário em texto, e espera por uma resposta. O protocolo 2 permite múltiplos desafios e respostas; o protocolo 1 é restrito a apenas um desafio/resposta. Exemplos de autenticação desafio-resposta incluem autenticação BSD (veja login.conf(5)) e PAM (para alguns sistemas não-OpenBSD).

Finalmente, se outros métodos de autenticação falharem, o SSH pede uma senha para o usuário. A senha é enviada para o host remoto para ser checada; entretanto, já que todas as comunicações são encriptadas, a senha não pode ser vista por alguém que esteja escutando a rede.

O SSH, automaticamente, mantém e checa um banco de dados contendo uma identificação de todos os hosts com que ele já foi usado. As chaves do host são armazenadas em ~/.ssh/known_hosts no diretório HOME do usuário.

Adicionalmente, o arquivo /etc/ssh/ssh_known_hosts é automaticamente checado para hosts conhecidos. Quaisquer novos hosts são automaticamente adicionados ao arquivo do usuário. Se a identificação de um host mudar, o SSH alerta sobre isto e desativa a autenticação por senha para prevenir ataques de spoof de servidor ou man-in-the-middle, que poderiam caso contrário ser usados para circundar a encriptação.

A opção StrictHostKeyChecking pode ser usada para controlar logins em máquinas cuja chave hospedeira não é conhecida ou tenha mudado.

Quando a identidade do usuário for aceita pelo servidor, ou o servidor executa o comando dado, ou loga na máquina e dá ao usuário um shell normal na máquina remota, todas as comunicações com o comando remoto ou shell vão ser automaticamente encriptados.

Se um pseudo-terminal foi alocado (sessão normal de login), o usuário poderá usar os caracteres de escape escritos abaixo.

Se nenhum pseudo-tty foi alocado, a sessão é transparente e pode ser usada para transferir dados binários confiavelmente. Na maioria dos sistemas, definindo o caractere de escape para “none”, também fará a sessão ser transparente mesmo se um tty for utilizado.

A sessão finaliza quando o comando, ou shell na máquina remota, sai e todas conexões X11 e TCP são fechadas.

Caracteres / Encaminhamento / Chaves de host

Caracteres de escape

Quando um pseudo-terminal for requisitado, o SSH suporta um número de funções através do uso de um caractere de escape.

Um simples til (~) pode ser enviado como “–“, ou colocando um caractere na frente no til que não esteja descrito abaixo. O caractere de escape deve sempre seguir uma quebra de linha para ser interpretado como especial.

O caractere de escape pode ser trocado nos arquivos de configuração usando a diretiva de configuração EscapeChar ou na linha de comando pela opção “-e”.

Os escapes suportados (assumindo o padrão ‘-‘) são:

  • -. :: Desconectar.
  • -^Z :: SSH em background.
  • -# :: Listar as conexões encaminhadas.
  • -& :: Coloca o SSH em background no logout quando estiver esperando conexões encaminhadas/ sessões X11 terminarem.
  • -? :: Mostra uma lista de caracteres de escape.
  • -B :: Envia um BREAK para o sistema remoto (só é útil para o procotolo SSH versão 2 e se o par suportar).
  • -C :: Abre a linha de comando. Atualmente, isto permite a adição de encaminhamento de portas usando as opções “-L”, “-R” e “-D” (veja acima). Também permite o cancelamento de encaminhamentos de porta remotos existentes usando “-KR[endereço_de_ligação:]porta”.
  • !command :: Permite o usuário executar um comando local se a opção PermitLocalCommand estiver habilitada em “ssh_config(5)”. Uma ajuda básica está disponível, usando a opção “-h”.
  • -R :: Requisita o rechaveamento da conexão (só é útil para o protocolo SSH versão 2 e se o par suportar).

Encaminhamento TCP

O encaminhamento de conexões TCP arbitrárias, sobre o canal seguro, podem ser especificadas ou na linha de comando ou no arquivo de configuração. Uma possível aplicação para o encaminhamento TCP é uma conexão segura para um servidor de correio eletrônico; outra é ir através de firewalls.

No exemplo abaixo deparamos com a encriptação da comunicação entre um cliente e servidor IRC, mesmo que o servidor IRC não suporte comunicações encriptadas diretamente.

Isto funciona da seguinte maneira. O usuário conecta no host remoto usando SSH, especificando uma porta para ser usada para encaminhar conexões para o servidor remoto. Depois disso pode-se iniciar o serviço o qual será encriptado na máquina cliente, conectando na mesma porta local, e o SSH irá encriptar e encaminhar a conexão.

O exemplo a seguir encapsula uma sessão IRC da máquina cliente “127.0.0.1” (localhost) para o servidor remoto “server.example.com”:

$ ssh -f -L 1234:localhost:6667 server.example.com sleep 10
$ irc -c ‘#users’ -p 1234 pinky 127.0.0.1

Isto encapsula uma conexão para o servidor IRC “server.example.com”, unindo ao canal “#users”, com nickname “pinky”, usando a porta 1234. Não importa qual porta é usada, desde que seja maior que 1023 (lembre-se: somente o root pode abrir sockets em portas privilegiadas) e não conflita com qualquer porta que já esteja em uso. A conexão é encaminhada para a porta 6667 no servidor remoto, já que esta é a porta padrão para serviços IRC.

A opção “-f” faz o SSH ficar em background e o comando remoto “sleep 10” é especificado para permitir uma quantidade de tempo (10 segundos, no exemplo) para iniciar o serviço que irá ser encapsulado. Se nenhuma conexão for feita no tempo especificado, o SSH sairá.

Encaminhamento X11

Se a variável ForwardX11 estiver definida como “yes” (ou veja acima a descrição das opções “-X”, “-x”, e “-Y”) e o usuário estiver usando X11 (a variável de ambiente DISPLAY está definida), a conexão para o display X11 é automaticamente encaminhada para o lado remoto, de tal maneira que, quaisquer programas X11 iniciados pelo shell (ou comando) irão através do canal encriptado, e a conexão para o verdadeiro servidor X será feita a partir da máquina local.

O usuário não deve definir DISPLAY manualmente. Encaminhamento de conexões X11 podem ser configuradas pela linha de comando ou nos arquivos de configuração.

O valor definido para DISPLAY pelo SSH irá apontar para a máquina servidor, mas com um número de display maior que zero. Isto é normal, e acontece porque o SSH cria um servidor X “proxy” na máquina servidor para encaminhar conexões sobre o canal encriptado.

O SSH também irá definir dados Xauthority automaticamente na máquina servidor. Para este fim, ele criará um cookie de autorização aleatória, armazená-lo em Xauthority no servidor, e verificar que as conexões encaminhadas que carregam esse cookie e substituí-lo pelo cookie real quando a conexão é aberta. O cookie de autenticação real nunca é enviado para a máquina servidor (e nenhum cookie é enviado na íntegra).

Se a variável ForwardAgent é definida como “yes” (ou veja a descrição das opções “-A” e “-a”, acima) e o usuário está usando um agente de autenticação, a conexão com o agente é automaticamente encaminhada para o lado remoto.

Verificando chaves de host

Ao se conectar a um servidor pela primeira vez, um fingerprint (impressão digital) da chave pública do servidor é apresentado ao usuário (a menos que a opção foi StrictHostKeyChecking desativada). Fingerprints podem ser determinados usando “ssh-keygen(1)”:

$ ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key

Se o fingerprint já é conhecido, ele pode ser comparado e a chave pode ser aceita ou rejeitada. Por causa da dificuldade de comparar chaves de host só de olhar para cadeias hexadecimais, também há suporte para comparar chaves de host visualmente, usando arte aleatória.

Ao definir a opção VisualHostKey para “yes”, um pequeno gráfico ASCII é exibido em cada login para um servidor, não importando se a sessão em si é interativa ou não.

Ao aprender o padrão que um servidor conhecido produz, um usuário pode facilmente descobrir que a chave de host mudou quando um padrão completamente diferente é exibido. Por causa que estes padrões não são ambíguos no entanto, um padrão que se parece com o padrão lembrado apenas dá uma boa probabilidade de que a chave de host é a mesma, e não uma prova garantida.

Para obter uma lista dos fingerprints, juntamente com sua arte aleatória para todos os hosts conhecidos, a seguinte linha de comando pode ser usada:

$ ssh-keygen -lv -f -/.ssh/known_hosts

Se o fingerprint é desconhecido, um método alternativo está disponível: “fingerprints de SSH verificados por DNS”. Um registro de recurso (RR) adicional, SSHFP, é adicionado a um zonefile (arquivo de zonas) e o cliente que está conectando poderá comparar o fingerprint com aquele da chave apresentada.

Neste exemplo, estamos conectando um cliente para um servidor (host.example.com). O registro de recurso SSHFP deve, primeiramente, ser adicionado ao zonefile para “host.example.com”:

$ ssh-keygen -r host.example.com

As linhas de saída terão de ser adicionadas ao zonefile. Para verificar que a zona está respondendo consultas de impressões digitais:

$ dig -t SSHFP host.example.com

Finalmente, o cliente conecta:

$ ssh -o “VerifyHostKeyDNS ask” host.example.com
[…]
Matching host key fingerprint found in DNS.

Are you sure you want to continue connecting (yes/no)?

Para mais informações, veja o VerifyHostKeyDNS, opção em “ssh_config(5)”.

Base Virtual / Ambiente / Files

SSH – Base Virtual de Redes Privadas

SSH contém suporte para Virtual Private Network (VPN) tunnelling usando tun(4) rede pseudo-device permitindo que duas redes se juntem de forma segura. O “sshd_config(5)”, opção de configuração PermitTunnel, controla se o servidor suporta isso, e em que nível (camada 2 ou 3 de tráfego).

O exemplo a seguir, iria ligar a rede cliente “10.0.50.0/24” com a rede remota “10.0.99.0/24” usando uma conexão ponto-a-ponto a partir de “10.1.1.1” a “10.1.1.2”, desde que o servidor SSH esteja rodando no gateway para a rede remota, em “192.168.1.15”, permitir.

No cliente:

# ssh -f -w 0:1 192.168.1.15 true
# ifconfig tun0 10.1.1.1 10.1.1.2 netmask 255.255.255.252
# route add 10.0.99.0/24 10.1.1.2

No servidor:

# ifconfig tun1 10.1.1.2 10.1.1.1 netmask 255.255.255.252
# route add 10.0.50.0/24 10.1.1.1

O acesso do cliente pode ser mais afinado através do arquivo /root/.ssh/authorized_keys (veja abaixo) e a opção do servidor PermitRootLogin. A entrada a seguir, permitirá conexões em tun(4) dispositivo 1 para o usuário “Jane” e em tun dispositivo 2 para o usuário “john”, se PermitRootLogin é definido para “forced-commands-only”:

tunnel=”1″,command=”sh /etc/netstart tun1″ ssh-rsa … jane
tunnel=”2″,command=”sh /etc/netstart tun2″ ssh-rsa … John

Desde que uma instalação SSH-based implica em certa quantidade de sobrecarga, pode ser mais adequado para instalações temporárias, como para VPNs sem fio. VPNs mais permanentes são melhores fornecidas por ferramentas, como “ipsecctl(8)” e “isakmpd(8)”.

Ambiente

SSH normalmente define as seguintes variáveis de ambiente:

  • DISPLAY – A variável DISPLAY indica a localização do servidor X11. É automaticamente definida por SSH para apontar a um valor na forma de “hostname:n”, onde “hostname” indica o host onde o shell é executado e ‘n’ é um inteiro “- 1. ssh” utiliza este valor especial para transmitir conexões X11 pelo canal seguro. O usuário normalmente não deveria definir DISPLAY explicitamente, como que vai tomar a conexão X11 insegura (e exigirá ao usuário copiar manualmente qualquer autorização necessária de cookies).
  • HOME – Definido para o caminho do diretório HOME do usuário.
  • LOGNAME: Sinônimo de USER – Definido para compatibilidade com sistemas que utilizam esta variável.
  • MAIL – Definido para o caminho da caixa postal (mailbox) do usuário.
  • PATH – Definido para o caminho (PATH) padrão, conforme especificado na compilação do SSH.
  • SSH_ASKPASS – Se SSH precisar de uma senha, ele irá ler a senha do terminal atual se ele foi executado a partir de um terminal. Se SSH não tem um terminal associado a ele, mas DISPLAY e SSH_ASKPASS estão definidos, ele irá executar o programa especificado por SSH_ASKPASS e abrirá uma janela X11 para ler a senha. Isso é particularmente útil quando se chama ssh de um “.xsession” ou escrita relacionada (note que em algumas máquinas, pode ser necessário redirecionar a entrada de /dev/null para fazer este trabalho).
  • SSH_AUTH_SOCK – Identifica o caminho de um domínio UNIX-soquete usado para se comunicar com o agente.
  • SSH_CONNECTION – Identifica as extremidades da conexão cliente e servidor. A variável contém quatro espaços de valores separados: endereço IP do cliente, número de porta do cliente, endereço IP do servidor e número de porta do servidor.
  • SSH_ORIGINAL_COMMAND – Esta variável contém a linha de comando original se um comando forçado é executado. Ele pode ser usado para extrair os argumentos originais.
  • SSH_TTY – Este é definido para o nome da tty (caminho para o dispositivo) associado com o shell atual ou comando. Se a sessão atual não tem tty, esta variável não está definida.
  • TZ – Esta variável é definida para indicar o fuso horário atual se ele foi definido quando o daemon (servidor) foi iniciado (i.e. o daemon (servidor) passa o valor para novas conexões).
  • User – Definido para o nome do usuário logado.

Além disso, o SSH lê ~/.ssh/environment, e adiciona linhas do formato “VARNAME = value” para o ambiente, se o arquivo existe, e os usuários têm permissão para mudar seu ambiente. Para mais informações, consulte o PermitUserEnvironment opção em “sshd_config(5)”.

Files

  • ~/.rhosts :: Este arquivo é utilizado para autentificação do host-based (veja acima). Em algumas máquinas este arquivo pode precisar ser de leitura à todos se o diretório home do usuário está em uma partição NFS, porque “sshd(8)” o lê como root. Além disso, este arquivo deve ser de propriedade do usuário, e não deve ter permissões de gravação para ninguém. A permissão recomendada para a maioria das máquinas é de leitura/escrita para o usuário, e não acessíveis por outros.
  • ~/.shosts :: Este arquivo é utilizado exatamente como “.rhosts”, mas permite a autenticação host-based sem permitir login com rlogin/rsh.
  • ~/.ssh/ :: Este diretório é o local padrão para todas as configurações específicas do usuário e informações de autenticação. Não há nenhuma exigência geral para manter todo o conteúdo do diretório em segredo, mas as permissões recomendadas são de leitura /escrita/execução para o usuário, e não acessíveis por outros.
  • ~/.ssh/authorized_keys :: Lista as chaves públicas (RSA/DSA) que podem ser usadas para fazer login como este usuário. O formato deste arquivo é descrito na página do manual do “sshd(8)”. Este arquivo não é altamente sensível, mas as permissões recomendadas são de leitura/escrita para o usuário, e não acessíveis por outros.
  • ~/.ssh/config :: Este é o arquivo de configuração por usuário. O formato de arquivo e opções de configuração são descritas em “ssh_config(5)”. Devido ao potencial para o abuso, este arquivo deve ter permissões restritas: leitura/escrita para o usuário, e não acessíveis por outros. Ele pode ser de um grupo-gravável desde que o grupo em questão tenha apenas o utilizador.
  • ~/.ssh/environment :: Contém definições adicionais para variáveis de ambiente; veja em AMBIENTE, acima.
  • ~/.ssh/identity, ~/.ssh/id_dsa e ~/.ssh/id_rsa :: Contém a chave privada para autenticação. Esses arquivos contêm dados sensíveis e devem ser legíveis pelo usuário mas não acessíveis por outros (ler/escrever/executar). O SSH irá simplesmente ignorar um arquivo de chave privada se for acessível por outros. É possível especificar uma senha ao gerar a chave que será usada para criptografar a parte sensível deste arquivo utilizando 3DES.
  • ~/.ssh/identity.pub, ~/.ssh/id_dsa.pub e ~/.ssh/id_rsa.pub :: Contém a chave pública para autenticação. Esses arquivos não são sensíveis e podem (mas não precisam) ser lidos por qualquer pessoa.
  • ~/.ssh/known_hosts :: Contém uma lista de chaves host para todos os hosts do usuário conectados que ainda não estão na lista de todo o sistema de chaves host conhecidos. Veja sshd(8) para mais detalhes sobre o formato deste arquivo.
  • ~/.ssh/rc :: Comandos deste arquivo são executados por ssh quando o usuário faz login, pouco antes do shell do usuário (ou comando) é iniciado. Veja a página de manual do sshd(8) para mais informações.
  • /etc/hosts.equiv :: Este arquivo é para autentificação do host-based (veja acima). Ele só deve ser escrito pelo root.
  • /etc/ssh/shosts.equiv :: Este arquivo é utilizado da mesma maneira como o hosts.equiv, mas permite a autenticação host-based sem permitir login com rlogin/rsh.
  • /etc/ssh/ssh_config :: Arquivo de configuração Systemwide. O formato de arquivo e opções de configuração são descritas em ssh_config (5).
  • /etc/ssh/ssh_host_key, /etc/ssh/ssh_host_dsa_key e /etc/ssh/ssh_host_rsa_key :: Estes três arquivos contêm as partes privadas das chaves host e são usados para a autentificação do host-based. Se a versão do protocolo 1 é usado, ssh deve ser setuid root, já que a chave do anfitrião é legível apenas pelo root. Para o protocolo versão 2, ssh usa ssh-keysign(8) para acessar as chaves host, eliminando a exigência do ssh ser setuid root quando o login é baseado em host de autenticação. Por padrão o ssh não é setuid root.
  • /etc/ssh/ssh_known_hosts :: Systemwide lista de chaves host conhecidas. Este arquivo deve ser preparado pelo administrador do sistema para conter as chaves host públicas de todas as máquinas da organização. Deve ser lido/visível por todos. Veja sshd (8) para mais detalhes sobre o formato deste arquivo.
  • /etc/ssh/sshrc :: Comandos deste arquivo são executados por ssh quando o usuário faz login, pouco antes que o shell do usuário (ou comando) é iniciado. Veja a página de manual do sshd (8) para mais informações.

Veja também

  • scp(1),sftp(1),ssh-add(1),ssh-agent(1),ssh-argv0(1),ssh-keygen(1), ssh-keyscan(1),ssh-vulnkey(1),tun(4),hosts.equiv(5),ssh_config(5), ssh-keysign(8),sshd(8)
  • The Secure Shell (SSH) Protocol Assigned Numbers, RFC 4250, 2006.
  • The Secure Shell (SSH) Protocol Architecture, RFC 4251, 2006.
  • The Secure Shell (SSH) Authentication Protocol, RFC 4252, 2006.
  • The Secure Shell (SSH) Transport Layer Protocol, RFC 4253, 2006.
  • The Secure Shell (SSH) Connection Protocol, RFC 4254, 2006.
  • Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints, RFC 4255, 2006.
  • Generic Message Exchange Authentication for the Secure Shell Protocol (SSH), RFC 4256, 2006.
  • The Secure Shell (SSH) Session Channel Break Extension, RFC 4335, 2006.
  • The Secure Shell (SSH) Transport Layer Encryption Modes, RFC 4344, 2006.
  • Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer Protocol, RFC 4345, 2006.
  • Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol, RFC 4419, 2006.
  • The Secure Shell (SSH) Public Key File Format, RFC 4716, 2006.
  • A. Perrig and D. Song, Hash Visualization: a New Technique to improve Real-World Security, 1999, International Workshop on Cryptographic Techniques and E-Commerce (CrypTEC ’99).

Autenticação por desafio e resposta no SSH

 Clusterweb, Linux, Redes  Comentários desativados em Autenticação por desafio e resposta no SSH
out 262012
 
Introdução

Acredito que o SSH não precise ser apresentado e tampouco detalhes de sua instalação. Até porque em praticamente todas as instalações ele já vem instalado por padrão, seja o cliente ssh ou o servidor. Em algumas o servidor precisa ser explicitamente instalado, como é o caso do Ubuntu. Mas não se apresse, é provável que você não precise de um servidor SSH em seu console, já que este é um recurso desejável justamente em servidores.

O SSH funciona sobre o protocolo SSL, da mesma forma que o HTTPS. Como o uso do SSH é feita por administradores e não por usuários leigos, é extremamente incomum o uso de certificados digitais neste caso. Afinal um administrador de redes experiente não irá cair na pegadinha do ataque do homem do meio (onde uma outra máquina se faz passar pelo teu servidor).

Durante o primeiro acesso seria prudente que o cliente verificasse se realmente é o servidor. Observe no exemplo a seguir as mensagens gerados pelo servidor no primeiro acesso:

$ ssh [email protected]
The authenticity of host ‘10.2.3.4 (10.2.3.4)’ can’t be established.

RSA key fingerprint is ff:7b:35:74:cd:4c:59:0b:4b:b5:cf:fe:eb:f4:ec:7a.

Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added ‘10.2.3.4,10.2.3.4’ (RSA) to the list of known hosts.

Observe que ele lhe pede que confirme que este é mesmo o servidor. Neste ponto, se tiver certeza (e pode verificar o fingerprint), ao digitar “yes” a chave do servidor será armazenada em ~/.ssh/know_hosts.

A partir deste momento, nenhuma outra mensagem de aviso ocorrerá, salvo se o servidor for reinstalado ou se estiver mesmo sobre um ataque do homem do meio. Mas aí a mensagem será de recusar a conexão.

Meu objetivo não é exatamente descrever o SSH em si, mas sim alguns recursos pouco usados do mesmo. Um deles é o login por desafio/resposta usando uma chave pública e privada.

Como funciona o desafio resposta

Basicamente consiste em o servidor enviar um desafio para você que somente você poderia resolver. Se você acertar o desafio, passou no teste e pode autenticar-se.

Para explicar melhor o que é o desafio resposta, costumo usar um exemplo didático, porém extremamente fraco. Serve para explicar a ideia, mas não deve jamais ser usado por ser frágil.

Suponha que o cliente possua um segredo que é um número inteiro. Podemos chamá-lo de senha. O servidor conhece este segredo e permitirá login para qualquer um que provar conhecê-lo. A autenticação poderia ser da forma clássica:

  1. o cliente conta para o servidor a sua senha;
  2. o servidor verifica se ele acertou a senha;
  3. servidor aceita ou não o login.

Porém o método anterior possui um problema: a senha é enviada pela rede e alguém poderá capturar ela e se logar no futuro como sendo o cliente.

A mesma solução anterior, porém baseada em desafio e resposta, poderia ser:

  1. servidor envia uma expressão matemática para cliente resolver usando o seu segredo;
  2. cliente resolve a expressão e envia apenas a resposta;
  3. servidor, que também conhece o segredo, vê se cliente acertou a resposta;
  4. se acertou, aceita login.

Pode parecer a mesma coisa, mas a ideia é que a expressão matemática mude aleatoriamente a cada solicitação. Se alguém estiver capturando o tráfego não poderá usar a resposta em um login futuro, pois o servidor irá solicitar outra expressão matemática. Esta expressão pode ser uma simples multiplicação, como demonstra a figura:

Linux: Autenticação por desafio e resposta no ssh

O exemplo da figura anterior ilustra como é a técnica, mas não deve ser usado. Isto porque um atacante conseguirá descobrir muito facilmente a chave, bastando dividir 4305 por 123, pois ele viu o desafio e viu a resposta. Operações matemáticas que possam ser revertidas não devem ser usadas (divisão reverte a multiplicação, soma reverte a subtração). Se usar outra operação mais complexa que não possa ser desfeita e com números realmente muito grandes a técnica poderá ser usada.

Um exemplo de uma operação matemática irreversível é a de módulo, usada no RSA. Apesar de fugir um pouco do foco deste artigo, pois ainda está na minha gaveta um artigo sobre RSA, vale o exemplo:

Linux: Autenticação por desafio e resposta no ssh

O exemplo anterior ainda não pode ser usado. Poderia se os números fossem realmente grandes, com um X em torno de 512 bits de tamanho e o desafio também. Com números pequenos um ataque de força bruta seria possível, isto é, o atacante tentaria todos os possíveis valores de X até achar um que encaixe na expressão.

Já me estendi demais neste conceito, já que o objetivo era apenas explicar o princípio do desafio e resposta. No que diz respeito ao ssh, o desafio e resposta é baseado em chaves públicas e privadas.

Desafio e resposta no ssh

O ssh é suficientemente seguro se bem usado. Se você tem certeza da idoneidade do servidor e se tem certeza de que realmente é o servidor, tudo bem. Não há qualquer problema você digitar sua senha de acesso. Ela não poderá ser lida por mais ninguém.

Isto porque toda a sessão ssh é protegida por um forte algoritmo de criptografia simétrico. Quando você digita sua senha ela é cifrada com este algoritmo e transmitida pela Internet. Alguém, em posição de capturar o tráfego, não conseguirá obter esta senha.

Porém existe ainda uma forma de executar o login sem precisar enviar a senha. E uma forma segura. Mas porque não enviar a senha? Vários motivos.

Primeiro uma segurança a mais, pois agora a senha sequer viaja pela Internet, nem mesmo cifrada. Na hipótese, mesmo remota, de alguém estar aplicando um ataque do homem do meio ou de que o servidor estar corrompido, o atacante realmente não terá sua senha, de forma alguma.

Um segundo motivo pode ser a facilidade de manutenção. As vezes é chato ter que ficar colocando várias vezes a senha, principalmente se todos fizerem a coisa certa, de não usar a mesma senha em todos os servidores (por experiência pessoal, sou cético quanto a isto!).

Para resolver este problema o ssh possui o login por desafio e resposta através do uso de um par de chaves pública e privada. Você primeiro deve criar um par de chaves para si, uma chave pública e privada. A chave privada você mantém em segredo, guarda-a em segurança. Já a chave pública você deposita no servidor e diz para o ssh aceitar conexões de qualquer um que prove ser o conhecedor da chave privada.

O conceito dos algoritmos assimétricos garante que tudo que foi cifrado com a chave pública, apenas a chave privada poderá abrir. Assim o desafio gerado pelo servidor passa a ser o seguinte:

  1. servidor escolhe aleatoriamente uma sequência de bits grande (exemplo: 2048 bits aleatórios);
  2. servidor cifra estes bits com a chave pública do suposto cliente e envia;
  3. cliente precisa dizer ao servidor qual era a sequência escolhida;
  4. cliente só pode fazer isto com sucesso se conhecer a chave privada.

Este método é ainda melhor que o descrito antes, pois não envolve a senha do usuário em nenhum momento, apenas a chave privada dele. Esta chave passará a ser a parte sensível e deve ser protegida. Como ninguém conseguirá decorar uma chave de milhares de bits, ela precisa ser armazenada.

Armazenar é um problema, pois pode-se supor até o roubo do HD onde um atacante teria a chave e se logaria em seus servidores. Para evitar isto, o ssh permite que você proteja sua chave com uma frase de passagem, que você poderá lembrar-se. Pode ser qualquer sequência de caracteres que será solicitada pelo seu programa cliente quando você fizer o login.

Configuração do ssh para autenticação por desafio e resposta

A autenticação por desafio resposta no ssh deve estar habilitada no ssh server. Por minha experiência, todos os servidores ssh já vem com isto habilitado, mas convém verificar. Apenas verifique se a informação PubkeyAuthentication no /etc/ssh/sshd_config não está em “no”. Normalmente ela está comentada no arquivo, o que significa que está ativa (o padrão é permitir):

# grep Pubkey /etc/ssh/sshd_config
#PubkeyAuthentication yes

Se ela estiver comentada ou com “yes”, tudo bem. Mas se estiver com “no”, comente a regra ou mude para “yes” e reinicie o ssh server.

Com o servidor configurado para aceitar esta forma de autenticação, deve-se ainda realizar os seguintes passos:

  1. criar um par de chaves
  2. instalar a tua chave pública no servidor

Usarei o usuário fulano como teste neste artigo.

Criação do par de chaves

Usuário fulano tem um login e senha no servidor 10.2.3.4. O cliente é a máquina didaké (nome do meu notebook). Primeiro ele se logou com seu usuário e senha, só para testar:

$ ssh 10.2.3.4
The authenticity of host ‘10.2.3.4 (10.2.3.4)’ can’t be established.
RSA key fingerprint is fb:a9:ac:b6:3d:3f:42:76:11:cc:44:2f:7f:55:49:97.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added ‘10.2.3.4’ (RSA) to the list of known hosts.
Password:
Have a lot of fun…

Voltando a máquina cliente, a didaké, ele cria seu par de chaves com o ssh-keygen. Os parâmetros indicam criar chaves usando o algoritmo dsa e com 1024 bits de tamanho. Se você não especificar o DSA, o algoritmo RSA será usado. O protocolo RSA não é usado por padrão no ssh e não funcionará a menos que você coloque o parâmetro RSAAuthentication yes no /etc/ssh/sshd_config. Este é desabilitado por padrão.

$ ssh-keygen -b 1024 -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/fulano/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/fulano/.ssh/id_dsa.
Your public key has been saved in /home/fulano/.ssh/id_dsa.pub.
The key fingerprint is:
4e:e4:ab:5c:5d:06:58:83:95:4a:77:1d:a0:7d:e7:ba [email protected]
The key’s randomart image is:

+--[ DSA 1024]----+ 
|         o+..o.. | 
|        ooo+. .  | 
|       .ooo.. . .| 
|       o.  . . o | 
|        S   o   .| 
|       o o o   . | 
|        + .   .  | 
|     . o       . | 
|      o       E  | 
+-----------------+

Quando ele perguntar “Enter file in which to save the key (/home/fulano/.ssh/id_dsa): ” simplesmente dê um enter aceitando esta sugestão.

Como frase de passagem eu coloquei “Viva o Linux 2009″. Pode ser qualquer coisa, mas tome cuidado pois você deve digitar exatamente a mesma coisa quando solicitado. Se digitar “Viva o LINUX 2009” já não será a mesma frase, pois Linux está tudo em caixa alta. Desaconselha-se deixar sem frase de passagem, mas é uma configuração possível.

Instalação da chave pública no servidor

A instalação da chave pública no servidor consiste em simplesmente colocar ela dentro do arquivo ~/.ssh/authorized_keys. Este arquivo pode ter várias chaves públicas, não apenas uma.

Para realizar esta tarefa o usuário fulano precisará logar-se no servidor, usando ainda sua senha. A chave pública criada está em ~/.ssh/id_dsa.pub no cliente e home do fulano. Ela é texto puro (base64) logo pode-se até dar um cat nela:

$ cat id_dsa.pub
ssh-dss AAAAB3NzaC1kc3MAAACBAKaOHlNYzozRRr0Ub1kAi/mBap55fQCda0t4T4rZnskdqX /gMnKvLP8B514b3Oq8exNCkTym6nyv1LyxxG1VmhpjKN8N8eDaErp/8qEif/GvH3HaFx4GJBWFed4Z6K9HkxsBy2yFwfcBmkvGFP3ggMwhBnKYFf7DSa9/0QzHDDx3AAAAFQDEb5c3RMsEo8xU6YsvVXnIlJteLQAAAIA+3Oa2X2oW2gprZkCRe7JE +KWvH+O9xjep/7l6iGFww9IDj35VgEHMzAr6LPvw+rAOB1P5qoXZr3hbTU6pzfHiSLy6UD G+LzHLRbyImZOH/p+n7hWtEfZs6mO5ZuJFxO3fStQKWy0r48XUEaduHY5PGQc+sa/fpjyS2BPToM46XgAAAIAzsUHfOZnFhGK5cmMGjEFyjQBIKqYxRo3pR2H0au/ObwrKan6rCEqWropJElI234AeIymOS2h4Hr3lHnbmyXsxxCt14xqE7ZQlq5X7DV2QCl 0PUcgGlbVSLNTGLXapW1KN2tiBv7u8Q0agNgZ3ek3XHTKtZ6jVm0eb/ACsg0D+Sw== [email protected]

Não faça o mesmo para a chave privada, pois ela não é em formato texto, é binário.

Então, basta pegar esta sequência esquisita de caracteres e copiá-la, assim como está, para o servidor. No Gnome pode-se até mesmo usar o recurso de copiar e colar do sistema, como demonstra a sequência de imagens.

Linux: Autenticação por desafio e resposta no ssh

Selecionando a chave pública no cliente, arquivo ~/.ssh/id_dsa.pub e usando o “Copy” do próprio Gnome.

Linux: Autenticação por desafio e resposta no ssh

Após, loga-se no servidor 10.2.3.4 ainda usando sua senha, e coloca-se a chave dentro do arquivo authorized_keys em ~/.ssh. No caso eu usei o simples cat com redirecionamento (cat >> authorized_keys).

Linux: Autenticação por desafio e resposta no ssh

Ao final, após colar, deve-se pressionar Control+D e o arquivo está com a chave pública. Na imagem, após o término, executei um cat para verificar.

Outras tantas formas podem ser usadas para obter-se o mesmo resultado, como simplesmente editar o arquivo authorized-keys com algum editor qualquer. O fato é que ele deve ter a chave pública.

Por fim, após a instalação, pode-se verificar se está funcionando. fulano sai do servidor e tenta-se logar novamente:

$ ssh 10.2.3.4
Enter passphrase for key ‘/home/fulano/.ssh/id_dsa’:
Last login: Mon Jul 27 13:40:02 2009 from 10.1.0.10
Have a lot of fun…

Agora ele pediu a frase de passagem que protege a chave pública. No caso eu tive que digitar o “Viva o Linux 2009” para poder me logar.

Conclusão

O uso desta forma de autenticação é considerado mais seguro que com usuário e senha. Porém a maior vantagem, na minha opinião, é ser bem mais prático.

Prático porque você pode colocar senhas diferentes em seus servidores e logar-se neles apenas por desafio e resposta, decorando apenas a sua frase de passagem. Pode colocar sua chave pública em todas as máquinas Linux que você deseja acessar.

Mais prático também porque hoje muitos chaveiros permitem armazenar a frase de passagem, solicitando-a apenas uma única vez por sessão e fazendo realmente um login sem senha nas conexões posteriores. É o caso do Gnome (e não uso KDE para testar).

Muitas coisas fantásticas podem ser realizadas com esta técnica, algumas com bastante cuidado, evidente. Eu, por exemplo, em um curso de Linux, criei um par de chaves e o coloquei no /root/.ssh/authorized_keys de todas as máquinas dos alunos. Assim, a partir do meu notebook, eu podia executar remotamente qualquer comando nas máquinas e sem senha, pois usava o lembrete de senhas do Gnome.

Para desligar uma máquina, bastou um:

$ ssh [email protected] “/sbin/shutdown -h now”

Isto dentro de um for, permite executar em todas as máquinas. Um exemplo mais interessante foi quando precisei que os alunos tivessem poderes de root as vezes, mas não sempre. Quando eu queria lhes dar esta permissão para todas as 20 máquinas, executava do meu notebook:

$ for IP in `cat ubuntu.txt`; do
ssh [email protected]$IP “/usr/sbin/adduser aluno admin”
done
echo OK

E dentro do arquivo ubuntu.txt tinha os IPs dos clientes, um por linha (nota: no ubuntu o adduser pode ser usado para inserir um usuário já existente em um grupo). Se, depois, não quero mais que o usuário aluno tenha poderes de root, então:

$ for IP in `cat ubuntu.txt`; do
ssh [email protected]$IP “/usr/sbin/deluser aluno admin”
done
echo OK

Isto porque no Ubuntu para poder usar o sudo basta estar no grupo admin (e no ubuntu o deluser pode ser usado para remover um usuário de um grupo. Nesta forma de uso, o usuário em si não é removido, apenas sai do grupo).

Se você gerencia dezenas de máquinas pode ser extremamente criativo e deixar os scripts trabalharem por você.