A principal fonte de dados está disponível em:

• http://the.earth.li/~sgtatham/putty/0.66/htmldoc/

Este artigo não cobre a versão PuTTY para Linux.

O painel SSH

O painel SSH (seta verde) está inserido na categoria Connection e possui opções relacionadas com a criação de uma conexão remota a um servidor SSH. Dentre as múltiplas funções de PuTTY, talvez a mais utilizada seja a função de agir como um cliente SSH no Windows. Essa função permite a emulação de um terminal de acesso remoto virtual.

SSH é um protocolo aberto e possui as versões 1 e 2. A implementação mais utilizada no GNU/Linux é OpenSSH. Esse software é derivado do projeto BSD. Muitas das configurações de PuTTY dependem da ativação de certas funcionalidades no servidor SSH para serem válidas.

Uma das propriedades mais interessantes de PuTTY é a possibilidade de usar o terminal remoto virtual como um canal para gerenciamento do servidor. PuTTY permite que a conexão SSH execute um comando remotamente. No campo "Remote command" podemos declarar um comando que será executado após o estabelecimento da conexão e da autenticação.

Após a execução do comando a conexão será encerrada. Nesta modalidade, não há execução de um shell remoto e apenas o comando deve ser executado.

Normalmente, o uso de PuTTY como um terminal virtual remoto permite a execução de um shell para interação entre o usuário e o interpretador de comandos (BASH, sh, ksh, etc). Em "protocol options" podemos definir que o shell não deve ser inicializado ativando a opção "Dont start a shell or command at all" - número 1. Isto é útil se estiver utilizando PuTTY apenas como um encaminhador (port forwarding), ou se o usuário em questão não tem capacidade de iniciar um shell válido. Essa propriedade está disponível somente na versão 2. A versão 1 presume que um shell sempre será executado.

Se pretende utilizar PuTTY para grandes trocas de dados a opção "Enable compression" pode ser útil para reduzir o impacto na largura de banda da rede. Essa opção ativa a compressão dos dados transmitidos reduzindo seu tamanho.

A opção "Preferred SSH protocol version" permite configurar qual versão de SSH o cliente prefere.

• Se marcar 1, o cliente tentará primeiro a versão ssh-1 e depois a versão ssh-2.
• Se marcar 2, o cliente tentará primeiro a versão ssh-2 e depois a versão ssh-1.
• Se marcar only 1, somente a versão ssh-1 é utilizada. (inseguro)
• Se marcar only 2, somente a versão ssh-2 é utilizada. (recomendado)

Observe que a versão SSH-1 está em desuso e é considerada insegura devido as várias fraquezas na criptografia utilizada nessa versão. A implementação SSH-1 existe apenas para fins de compatibilidade com antigos sistemas ainda em uso.

Em "Sharing an SSH connection between PuTTY tools" é possível ajustar o compartilhamento da conexão de PuTTY, se possível. O protocolo SSH-2 permite executar múltiplos canais de dados sobre a mesma conexão SSH. É possível logar apenas uma vez e reutilizar a conexão em mais de uma janela de terminal aberta. Cada instância de PuTTY executa uma sessão de terminal isolada de outra.

Todavia, ativando essas caixas de controle você pode configurar PuTTY para checar se outra instância já está conectada ao servidor e, se estiver, a conexão TCP será compartilhada entre as sessões de PuTTY. Ao ativar "Share SSH connection if possible" e utilizar a opção "Duplicate Session" (no menu de PuTTY) a conexão será compartilhada entre essas sessões. No caso do compartilhamento ser ativado, apenas a primeira sessão é real (upstream) as demais sessões reusam a conexão (downstreams).

As conexões virtuais se conectam ao PuTTY upstream através de métodos de comunicação inter-processos via local. Neste cenário, ambas instâncias de PuTTY devem ser configuradas para compartilhar a conexão.

Observe que PuTTY pode agir como um upstream ou um downstream, ou como ambos. Essas opções somente fazem efeito se o compartilhamento da conexão estiver ativo. Por padrão, ambas opções são ativadas, caso tenha uma necessidade específica, pode desmarcar uma ou outra opção.

Onde citamos PuTTY compartilhando a conexão entenda que qualquer uma das ferramentas da família PuTTY (PSCP, PSFTP) pode funcionar como downstream e nunca como upstream.

O painel Kex

O painel Kex (seta verde) é uma abreviação de "Key exchange" e permite configurar opções relacionadas com a troca de chaves realizada pelo protocolo SSH-2 durante a criação da sessão. A troca de chaves ocorre no início da conexão SSH (em poucos casos um pouco mais tarde) e estabelece um segredo compartilhado que é utilizado como base para todas as funcionalidades de segurança de SSH-2. Em relação a segurança de SSH-2 o momento da troca de chaves é considerado crítico.

A troca de chaves é um processo criptográfico intenso; se o cliente ou o servidor for uma máquina lenta esse processo pode levar décimos de segundos para ser concluído. Neste caso, se a conexão for muito lenta para inicializar ou cai nesse ínterim, mudar os valores desses parâmetros pode ajudar. Se você não compreende completamente todas as opções da troca de chaves deixar o servidor negociar automaticamente com o cliente pode ser uma boa ideia. Observe que todas as opções deste painel afetam exclusivamente as conexões SSH-2.

A opção "Algorithm selection policy" - número 1 - permite escolher um método para a troca de chaves. O método escolhido precisa ser oferecido pelo servidor, senão a sessão não se completa. PuTTY suporta uma variedade de métodos de troca de chaves. Atualmente PuTTY suporta principalmente as seguintes variações do método Diffie-Hellman.

• Grupo 14 - Um grupo bem conhecido de 2048 bits.
• Grupo 1 - Um grupo bem conhecido de 1024 bits. É menos seguro que o grupo 14, mas é útil para máquinas lentas e pode ser o único método suportado por sistemas antigos.
• Grupo exchange - Com essa opção, em vez de usar um grupo fixo, PuTTY requisita ao servidor que sugira um grupo. Esse comportamento é o recomendado, se possível.

Em adição, PuTTY suporta a troca de chaves RSA. Esse algoritmo requer menos esforço computacional por parte do cliente, e um pouco menos de esforço por parte do servidor que os métodos Diffie-Hellman.

O campo -- warn below here -- é um seletor, que pode ser ajustado com os botões Up e Down, e que permite limitar os métodos considerados aceitáveis pelo cliente PuTTY. Caso o servidor ofereça um método abaixo deste limite, uma mensagem é emitida para que o usuário aceite ou descarte a conexão.

Repetindo a troca de chaves

Uma vez que a chave é negociada no começo da conexão, quando essa é utilizada por muito tempo ou para transferir grande quantidade de pacotes, é teoricamente viável montar um ataque a conexão. O protocolo SSH-2 define que uma nova troca de chaves deve ocorrer após um dado intervalo de tempo ou após um certo volume de dados serem trocados. Observe que a iniciativa para uma renovação do segredo (a chave) pode partir tanto do cliente como do próprio servidor.

Enquanto a renegociação de uma nova chave se dá, nenhum dado pode ser transmitido pela conexão SSH, o usuário pode perceber esse momento como um congelamento (freeze) da conexão. O evento de renovação da chave pode ser conferido no arquivo de log. O algoritmo da renovação é o mesmo da negociação inicial, inclusive com sua conhecida sobrecarga (overhead).

Os valores definidos em "Options controlling key re-exchange" funcionam como um gatilho que dispara a renegociação da chave. Entretanto, essa renovação pode ser forcada a qualquer momento por PuTTY. O valor em "Max minutes before rekey" define o limite (em minutos) para que a chave seja renovada. Definir esse campo como zero desativa a renovação da chave. O protocolo SSH-2 recomenda 60 minutos como uma sugestão ideal. Uma razão para desativar essa renovação é semelhante aos motivos para desativar keepalive, pois há casos em que ela não é útil e pode até atrapalhar.

O uso de proxy e firewall no caminho da conexão pode ser um impeditivo para a renovação da chave, pois ela é acompanhada pela renovação da conexão TCP. Isso leva a conexão anterior a ser abandonada em alguns casos. Observe que independente dos valores definidos em PuTTY o servidor ainda pode renovar a chave a qualquer momento.

O valor em "Max data before rekey" define o limite (em volume de dados) para que a chave seja renovada. O valor é totalizado pelo tráfego total independente da direção do encaminhamento. Definir esse campo como zero desativa a renovação da chave. O protocolo SSH-2 recomenda 1 GiB como uma sugestão ideal. Desativar a renovação da chave baseada no volume de dados não é boa ideia. Observe que a confidencialidade do protocolo SSH-2 está intimamente ligada às limitações do IPv4. É indispensável que a renovação da chave ocorra antes de TCP alcançar seu limite de 32 bits para numeração dos pacotes TCP.

Ao contrário da renovação por tempo, a renovação por volume de dados não pode ocorrer quando a conexão SSH está em estado inativa (idle), ou causará problemas.

Observe que sem a renovação da chave o protocolo SSH-2 se torna tão fraco quanto SSH-1!

Em algumas situações, se o gerenciamento automático da renovação da chave por PuTTY não for suficiente para alguma necessidade particular, você pode configurar manualmente uma chave ou lista de chaves que PuTTY pode utilizar.

Observe que um cenário de uso para essa opção é quando você está utilizando um servidor SSH que está sujeito a rotação na resolução de nomes (round-robin) pelo servidor DNS. Neste caso, pode ser que o servidor retornado pela resolução de nomes DNS não seja o mesmo que estava conectado. Se esses servidores possuem listas de chaves diferentes, pode ser necessário manter essa lista de chaves em arquivo.

Outro cenário possível é aquele onde o gerenciamento das chaves por PuTTY (ou qualquer ferramenta da família) está indisponível em um ambiente sem acesso ao registro do Windows.

Uma chave pode ter os seguintes formatos:

Uma impressão digital (Fingerprint) no formato MD-5. As impressões digitais são registradas em log de eventos e possuem sessenta caracteres no formato hexadecimal no formato de dois dígitos separados por dois-pontos. Um BLOB - Binary Large OBject - formatado na base-64 descrito popularmente como uma chave pública no formato SSH-2.

Se esta caixa contém, pelo menos, uma chave ou impressão digital quando PuTTY fizer a conexão SSH, o mecanismo de gerenciamento da chave é contornado (bypassed). Neste caso, a conexão será autorizada se, e somente se, a chave deste host estiver presente na lista de chaves e a chave do host armazenada no Registro do Windows será apenas somente-leitura.