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)".