Por DJBongHit
Artigo original em http://www.kuro5hin.org/story/2001/10/21/134817/35, publicado em 21/10/2001
As redes de computadores são uma mídia inerentemente insegura. A menos que você tem certeza que seus pacotes nunca irão passar por um roteador ou computador que você não controle direto sobre, seus dados não estão seguros. Eles podem ser visualizados por sysadmins pouco confiáveis ou por um script kiddie, ele pode ser alterado em trânsito, ou pode ser interceptado e trocado por dados completamente diferentes. Com a nova legislação, que está sendo proposta no Congresso em nome do combate ao terrorrismo, a situação ficará pior. Agora, mais que nunca, criptografia forte e autenticação são de suma importância. Neste artigo eu irei introduzir as bases da criptografia e mostrar o uso básico e avançado do OpenSSH, uma implementação livre dos protocolos SSH.
Como eu mencionei na introdução, você não pode simplesmente confiar em qualquer dado que passe pela Internet sem algum método para garantir que o dado que você envia é o mesmo dado que é recebido do outro lado. Isto parece paranóico, e na maioria dos casos é, mas é sempre melhor estar seguro que ter problemas. É muito fácil para qualquer um falsificar os seus dados durante o trânsito. E se você tem dados que são sensíveis ou privados, certamente você não vai querer que J. Random Hacker ou H. Bored Sysadmin leia o mesmo. É aqui onde a criptografia e a assinatura digital entram.
Vejamos um exemplo concreto de um problema típico de segurança. Suponha que o servidor A deseje envia uma mensagem ao servidor B. Se a mensagem for enviada descriptografada e passa pelo roteador C, qualquer informação enviada é visível a root@C. Se root@C é hostil, ele pode resolver ler o que o servidor A está tentando enviar para o servidor B, e, em vez de repassar a mensagem, enviar uma mensagem falsa para B, e fazer a mesma coisa no retorno de B para A. Este é o ataque conhecido como "man-in-the-midle" ou "intermediário".
Tipicamente os pacotes enviados pela Internet viajam por vários roteadores antes de chegar a seu destino. Cada um destes roteadores é um perigo potencial e possui completo acesso a seus dados. Esta é, claramente, uma situação inaceitável para muitos dados importantes ou sensíveis. Infelizmente as pessoas constantemente estão enviando segredos da empresa, informações pessoais, senhas, números de cartão de crédito, e outros dados privados não criptografados pela internet. Ou elas não percebem o perigo disto ou simplesmente não acreditam que valha o esforço a própria proteção. Não esteja neste grupo - eles estão pedindo por problemas.
Outra área em que a técnica de criptografia é usada é na área de autenticação - como eu fico sabendo que você é quem você diz ser? Um nome de login e senha podem ter sido seguros há 20 anos atrás, mas eles são facilmente roubados ou violados. E um esquema de login e senha pode fornecer um serviço básico de autenticação, mas uma vez autenticado, eles não garantem que os dados recebidos sejam exatamente os mesmos que foram enviados. Criptografia e assinaturas digitais são extremamente importantes para resolver estes problemas (particularmente sistemas de chave pública).
Tradicionalmente a criptografia têm se baseado em um segredo compartilhado, conhecido como chave. Esta chave é usada em uma fórmula matemática para embaralhar a informação em questão de forma que ela não possa ser desembaralhada facilmente sem o conhecimento da chave secreta[1]. Enquanto esta técnica pode ser bem segura quando estiver em uso um bom algoritmo e uma chave de tamanho razoável, ela introduz o problema da troca de chaves. Como você pode se comunicar com um host remoto na Internet quando você não tem um canal seguro de comunicação que você possa utilizar para transferir a chave de criptografia em primeiro lugar? Este problema tem sido resolvido tipicamente pela transferência das chaves pessoalmente.
A presunção que a criptografia requer o compartilhamento do conhecimento de uma chave está tão entranhado que ele geralmente não é reconhecido. Simplesmente é assumido pela maioria que este é um defeito das técnicas de criptografia. Entretanto, tudo mudou em 1976 quando Martin Hellman, Whitfield Diffie, e Ralph Merkle apresentaram a idéia da criptografia de chave pública na Stanford University [2].
A criptografia de chave pública aborda o problema de um ângulo completamente diferente. Aqui temos 2 chaves - uma chave privada, que é protegida cuidadosamente, e uma chave pública, que pode ser passada a quem a quiser. A chave pública pode ser derivada da chave privada, mas não vice-versa. Os algoritmos de chave pública possuem a propriedade que os dados criptografados pela chave pública podem ser somente descriptografados pela chave privada correspondente [3].
Com esta descoberta, o problema da troca de chaves está praticamente resolvido. Não há mais necessidade de uma mídia segura para a transferência inicial de chaves, mas você pode simplesmente criptografar os dados com a chave pública do recipiente e ter certeza que os dados só podem ser recuperados com a chave privada dele, a qual nunca precisa sair do controle dele. Isto também resolve o problema mencionado acima da autenticação - se você quer ter certeza que alguém é quemdiz ser, simplesmente criptografe uma pequena quantia de dados (conhecida como "desafio") usando sua chave pública, e envie a esta pessoa. Esta pessoa então descriptografa a mesma com sua chave privada e envia de volta (possivelmente criptografada com tua chave pública). Se os dados que você receber são idênticos aos dados originalmente enviados, você sabe que ele é quem diz ser [4].
Então por quê a criptografia de chave privada ainda é utilizada? A razão tem a ver com eficiência. Os métodos atuais de criptografia com chave pública são muito mais lentos que os métodos de chave privada, tornando, desta forma, impraticável a criptografia de enormes quantias de dados. Frequentemente, (como com o SSH), um método de chave pública pode ser utilizado para autenticação e para a troca de uma chave privada. Se tudo der certo com estes dois passos, a criptografia de chave privada pode ser usada.
Uma função de Hash é simplesmente uma função que pega uma enorme quantia de dados e encolhe a mesma para um tamanho bem menor. É uma função de uma via (ou seja, a informação original não pode ser determinada a partir do hash resultante). Funções criptográficas de hash tem a propriedade adicional que uma pequena alteração nos dados originais resulta em uma grande alteração no hash resultante, o que torna extremamente difícil alterar os dados e manter o mesmo hash resultante [5].
Assinaturas digitais fazem uso das funções de hash criptográficas para mostrar que o que o recipiente vê é, de fato, a informação que foi originalmente enviada. Algoritmos de assinatura digital típicos são baseados na criptografia de chave pública, e uma visão simplificada de como funcionam é mostrada no seguinte exemplo.
A pessoa A compõe um email para a pessoa B. Quando o email está pronto para ser enviado, ele é passado por um algoritmo criptográfico de hash e o hash resultante é criptografado com a chave privada de A e anexado ao email. Quando a pessoa B recebe o email, ela descriptografa a assinatura com a chave pública de A e passa o email pelo mesmo algoritmo de hash. Se o hash resultante é idêntico ao hash descriptografado, a pessoa B pode confiar que o email não foi adulterado durante o transporte. Mesmo pequenas alterações, como o acréscimo de pontuações ou espaços irá resultar em um hash completamente diferente.
Assinaturas digitais são uma exigência legal em alguns estados por que são (praticamente) impossíveis de serem forjadas - certamente são muito mais difíceis de forjar que uma assinatura física. Uma aplicação popular para a criação e verificação de assinaturas digitais (bem como criptografar e descriptografar) é o PGP, ou sua alternativa livre, o GnuPG.
O OpenSSH é uma implementação livre dos protocolos SSH, versão 1 e 2. O nome secure shell é um pouco equivocado, uma vez que o mesmo não é um shell da mesma forma que o bash ou do tcsh são shell, mas é mais do tipo do rsh. Ele é usado quando é preciso fazer um acesso remoto seguro a uma máquina Unix, mas devido à prevalência de script kiddies que adorariam conseguir sua senha e ober acesso livre a teus servidores, é uma boa idéia usar o mesmo sempre que você precisar fazer algum acesso remoto.
O uso mais básico do ssh, e a forma que ele é usado pela maioria das pessoas, é como substituto do telnet. O telnet transmite toda comunicação, incluindo o login e senha, em texto plano, e esta informação pode facilmente ser interceptadapor qualquer um que tenha acesso físico a qualquer rede ou roteador em que os seus pacotes passarem [6]. Qualquer coisa transmitida pela Internet em texto plano é jogo fácil para qualquer um, por isto você tem que ser cuidadoso. Usar o ssh ao invés do telnet torna muito mais difícil sua informação ser capturada.
O uso básico do ssh é simples. Se você quer logar em um servidor de nome "fignewton" com o username "bob", você pode usar o seguinte comando:
bash$ ssh bob@fignewton
Se esta é a primeira vez que você se conecta a este host em particular, você verá uma mensagem parecida com a abaixo:
Host key not found from the list of known hosts.
Are you sure you want to continue connecting (yes/no)?
Dependendo de sua versão do ssh, você pode também ver uma mensagem mostrando a fingerprint da chave do host remoto. Esta está ligada a um hash da chave, e se você estiver sendo extremamente cuidadoso você vai trocar as fingerprints com o administrador do host remoto através de uma linha segura (tipo um telefone ou pessoalmente) antes de fazer a conexão, e então verificar se as fingerprints são idênticas. Isto é para proteger-se de um ataque "man-in-the-middle" que eu discuti acima, onde alguém fica entre você e o servidor, trocando as chaves e criptografando e descriptografando suas comunicações de uma forma que é transparente tanto para você quanto para o servidor, mas permitindo-o ver (e alterar) toda a comunicação.
Uma vez que o ssh tenha feito a conexão, ele irá pedir pela sua senha. Esta é a senha associada à conta de usuário na máquina remota que é idêntica ao username que você forneceu ao ssh (se você não fornecer um username, o ssh assume que você quer usar o username no qual você está logado atualmente na sua máquina). Quando você informar a senha, o ssh criptografa a mesma e a envia para o servidor remoto. Se a senha for idêntica à senha associada à conta remota, o ssh cria um login shell e loga você na máquina remota. A partir deste ponto, você pode usar a máquina como se estivesse logado no console.
Existem duas versões diferentes do protocolo ssh - ssh1 e ssh2 (ambos são suportados pelo OpenSSH). Várias vulnerabilidades foram descobertas no ssh1, e a recomendação em geral é que se use o ssh2.
O telnet e outros mecanismos de login estão longe de serem os únicos protocolos de rede que tem o mau hábito de transmitir informações descriptografadas. Muitos protocolos comuns, como HTTP, POP3, ou IMAP, transmitem as informações em texto plano, possivelmente incluindo logins e senhas. Enquanto cada um destes protocolos tem uma versão protegida pelo SSL[8], as versões seguras não são tão comuns quanto as versões não protegidas. Além disto, a instalação de versões protegidas pelo SSL requer o uso de privilégios de superusuário, e se, por exemplo, você lê seu email via IMAP de um servidor remoto para o qual você não tem controle dieto, você não pode instalar o IMAP-S.
O SSH vem para o resgate aqui. Desde que você tenha acesso shell ao servidor que você deseja se conectar, o SSH pode criar um tunel criptografado para você usar como canal para suas conexões de rede. Ele faz isto criando uma conexão segura ao servidor, abrindo uma porta na sua máquina local, e canalizando tudo que recebe na porta local para uma porta específica no servidor remoto.
Vamos usar o IMAP com exemplo, já que é ele que eu uso para verificar meu email. Digamos que você queira recuperar seus emails de um servidor de nome "vacuum". vacuum está rodando um servidor IMAP, mas não um protegido pelo SSL, e você prefere não transmitir seu username e senha descriptografados. Você pode chamar o ssh com o seguinte comando (assumindo que você esteja usando o OpenSSH):
bash$ ssh -L2001:vacuum:143 bob@vacuum
Este comando diz ao ssh para abrir a porta local 2001 e repassar a conexão para a porta 143 em vacuum, e logar em vacuum como bob para isto. Uma vez que você consiga fazer o login com sucesso no servidor remoto, você tem um tunel ssh para brincar. Para checar seu email agora, simplesmente informe seu cliente IMAP (eu uso o fetchmail para isto, mas você pode usar qualquer cliente IMAP que queira) para ler seu email a partir de localhost, porta 2001. O ssh irá fazer uma conexão transparente para o servidor remoto.
Um uso comum para port forwarding (repasse de porta), é um que o ssh faz sem que você precise especificar, é o repasse de X11. Uma das belezas do sistema X11 é que ele é transparente à rede - você pode rodar uma aplicação em um servidor do outro lado do mundo e ter sua janela apresentada em sua máquina local como se estivesse rodando localmente (desde que você tenha largura de banda para isto, mas este é outro problema). Infelizmente, os projetistas do X não tinham em mente a segurança quando escreveram o mesmo, e os dados transmitidos podem ser examinados atrás de coisas como teclas pressionadas. Se você rodar um xterm de um computador remoto e então fizer um ssh para um terceiro computador, sua conexão para aquele computador será criptografada, mas a conexão da máquina local para o servidor remoto ainda estará em texto plano, e sua senha pode ser roubada desta forma.
Novamente, o ssh vem para o salvamento. Desde que o administrador da máquina remota não desabilitou explicitamente isto, quando você faz ssh a um servidor e está rodando o X11 na máquina local, o ssh irá criar um tunel criptografado para conexões X viajarem de volta à sua máquina [9]. Desta forma, você pode rodar um programa X na máquina remota e ele será mostrado com segurança em sua máquina local (você terá que informar a opção -X na linha de comando do ssh para habilitar esta função se ela não está ligada por padrão).
Enquanto usar o ssh com uma senha é muito mais seguro que o telnet ou rsh, ainda não o é sem algumas armadilhas. Ao mesmo tempo que sua senha é criptografada e mantida segura de outros olhos durante o trânsito pela rede, uma vez que ela chegue no servidor remoto ela é descriptografada novamente para texto plano antes da autenticação. Se o servidor remoto foi comprometido, um atacante pode substituir o sshd[7] por uma versão corrompida que funciona como um cavalo-de-tróia, coletando senhas. Um método muito mais seguro de autenticação é a autenticação baseada em chaves.
A autenticação de chaves SSH é baseada nos princípios da criptografia de chave pública. Você tem uma chave privada que você mantém protegida e que é posteriormente criptografada com uma senha de acesso, e você tem uma chave pública que é mantida em cada servidor que você deseja acessar. Quando você desbloqueia sua chave privada e tenta conectar a um servidor para o qual você tenha dado a sua chave pública, sua chave é usada para autenticação em vez de sua senha. Isto significa que suas senhas nunca são enviadas à máquina remota, removendo desta forma toda a possibilidade de ataques de roubo de senha.
Aqui temos uma visão básica de como este processo funciona (simplificadamente, mas você vai entender a idéia básica). Quando você conecta-se a um servidor remoto, o servidor checa para ver se sua chave pública está no arquivo authorized_keys da sua conta remota (mais sobre isto mais tarde). Se ele está, então o servidor criptografa algum dado aleatório com sua chave pública e o envia a você. Você descriptografa estes dados, criptografa o mesmo com a chave pública do servidor remoto, e manda-os de volta. Se o servidor descriptografar e ver que é idêntico ao que ele enviou originalmente a você, então ele sabe que você é quem você diz ser, e deixa você entrar sem precisar de senha.
Para criar um par de chaves ssh (um conjunto de chaves, uma pública, e uma privada), tudo que você precisa fazer é executar o seguinte comando:
bash$ ssh-keygen
Este comando vai pedir por uma senha para criptografar a chave primária e vai salvar a mesma por padrão em ~/.ssh/identity. Mantenha esta chave cuidadosamente guardada! Se alguém conseguir pegar a chave e a senha que você usou para criptografar a mesma, este alguém pode fazer logon como se fosse você em todos os servidores que estiverem configurados para aceitar suas chaves! Depois que o comando é enviado:
Generating public/private rsa1 key pair.
Enter file in which to save the key (/home/bob/.ssh/identity):
Created directory '/home/bob/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/bob/.ssh/identity.
Your public key has been saved in /home/bob/.ssh/identity.pub.
The key fingerprint is:
e8:96:e0:80:06:b5:e5:e4:22:30:3b:76:47:93:95:73 bob@my.computer.com
Isto é tudo que você precisa fazer! Uma vez que seu keypar tenha sido gerado, você pode pegar o conteúdo de identity.pub e acrescentar ao seu ~/.ssh/authorized_keys no servidor remoto[10]. Uma vez que ele tenha sido acrescentado, tente conectar-se ao servidor remoto novamente. Quando você faz a conexão, em vez de pedir sua senha, ele irá perguntar pela senha que você usou para proteger sua chave privada:
bash$ ssh bob$fignewton
Enter passphrase for RSA key 'bob@my.computer.com':
Quando você informar a senha para desbloquear sua chave, o ssh usará então sua chave para fazer sua autenticação com o servidor remoto - sua senha nunca é transmitida, e nenhuma informaçõ é transmitida pela linha que possa ser mais tarde usada por um atacante para obter acesso a sua conta. Desde que você mantenha sua chave privada em segurança, sua conta está segura.
A autenticação de chaves tem outros benefícios, como a possibilidade de várias pessoas utilizarem a conta root sem conhecer a senha de root. Simplesmente acrescente as chaves públicas de cada usuário a ~/.ssh/authorized_keys, e elas poderão fazer o login como aquele usuário.
A autenticação baseada em chaves também traz outras possibilidades interessantes. Por exemplo, se você está certo que ninguém que não seja de confiança irá usar sua sessão de login atual, você pode usar um programa chamado ssh-agent para manter uma cópia desbloqueada de sua chave privada na memória, de forma que você não precise escrever sua senha toda vez que faz um ssh para algum lugar. É consideravelmente mais seguro que simplesmente usar uma chave privada sem senha pois, mesmo quando sua chave está desbloqueada, o ssh-agent não irá dar a chave privada para você - ele somente assina ou descriptografa dados com ela (como no caso do desafio do servidor). Além disso, outras pessoas que estejam logadas em seu servidor (fora o root, é claro) não tem acesso ao seu ssh-agent.
O ssh-agent é usado conforme abaixo:
bash$ ssh-agent
SSH_AUTH_SOCK=/tmp/ssh-XXvknpQ6/agent.23799; export
SSH_AUTH_SOCK;
SSH_AGENT_PID=23800; export SSH_AGENT_PID;
echo Agent pid 23800;
A saída do ssh-agent foi feita para ser examinada pelo seu shell para acrescentar as variáveis de ambiente apropriadas. Ou copie e cole a saída na mesma janela de terminal, ou execute algo assim (assumindo que você está usando um shell bash):
bash$ eval `ssh-agent`
Agent pid 23800;
O ssh-agent está agora rodando e as variáveis de ambiente apropriadas foram configuradas de forma que o ssh e os vários utilitários ssh podem agora acessar o mesmo. Uma vez que o agente esteja rodando você pode acrescentar suas chaves privadas com comandos semelhantes ao abaixo:
bash$ ssh-add
Need passphrase for /home/bob/.ssh/identity
Enter passphrase for bob@my.computer.com
Identity added: /home/bob/.ssh/identity (bob@my.computer.com)
Agora, quando você fizer um ssh a um servidor remoto que está configurado para aceitar sua chave, você não precisa fornecer uma senha, você simplesmente faz a conexão. Obviamente, neste ponto você precisa ser extremamente cuidadoso sobre deixar pessoas que não são de confiançausar sua sessão de login (ssh-add -D faz o ssh-agent esquecer a senha se você precisar deixar o computador).
Se você rodar o ssh-agent antes, por exemplo, de rodar o startx, toda a tua sessão X terá acesso ao agente, o que é bastante útil.
O método tradicional de transferência de arquivos de uma máquina para outra por uma rede é usando o protocolo FTP. O FTP, como o IMAP e outros, transfere as informações de autenticação em texto plano, que pode não ser desejável. Infelizmente, devido à estrutura do protocolo FTP, é muito difícil fazer um tunel para o mesmo através de uma conexão ssh[11].
O SSH vem com um programa chamado 'scp', que significa 'secure copy' (cópia segura). Ele vem bem a calhar quando você quer transferir arquivos de um computador para outro de forma segura (ele também pode usar compressão se você usar a opção -C, que é boa para transferência de teto ou outro formato de dado que pode ser comprimido). Ele não usa um protocolo separado, mas envia os dados através de uma conexão ssh normal, e por causa disto ele aceita authorized_keys e conversa com o ssh-agent.
O uso do scp é bem simples. A sintaxe é:
scp file1 file2 file3 ... destination
Cada um dos argumentos pode ser um arquivo local ou remoto. Por exmeplo, pra compiar seu arquivo .bashr do servidor vacuum para o computador local:
scp vacuum:.bashrc .
vacuum:.bashrc é a sintxe que você usa para copiar de ou para um host remoto - host:arquivo. Se você não especificar um diretório, ele utiliza por padrão o diretório home. O destino é dado como ".", que significa o diretório atual.
Ao mesmo tempo em que o ssh é uma ferramenta muito útil para comunicações criptografadas em tempo real, ele não funciona muito bem em situações em que você precisa criptografar algo agora e permitir que alguém descriptografe mais tarde, ou para criar e verificar assinaturas digitais. Uma ferramenta popular para tratar estes casos é a Gnu Privacy Guard, uma implementação livre do Pretty Good Privacy (que, apesar do nome, é realmente bom).
Eu tinha a intenção de cobrir o GnuPG em profundidade como eu fiz com o OpenSSH, mas então eu tropecei com um conjunto de artigos que Inoshiro escreveu para o kuro5hin cobrindo o mesmo. Portanto, eu vou apenas apontar os artigos para vocês:
Gnu Privacy Guard Tutorial, Part I
Gnu Privacy Guard Tutorial, Part II
Estes arquivos tem um ano e meio de idade, mas ainda cobrem informações relevantes e o uso do GnuPG, e foram bem escritos. Eu sugiro a leitura deles.
Espero que este artigo, bem como os artigos do Inoshiro sobre o GnuPG, inspirem você a levar a segurança das comunicações a sério, pois a insegurança da mídia que é a Internet é uma ameaça maior que a maioria das pessoas pensa. Também espero que você ache a minha discussão sobre o OpenSSH útil, à medida que a maioria das pessoas parecem entender o uso básico mas não percebem o quanto um pequeno programa realmente pode fazer. Eu somente arranhei na superfície dos usos do ssh, e, se você está interecado em aprender amis sobre o ssh, eu sugiro que dês uma olhada no livro da O'Reilly, SSH The Secure Shell: The Definitive Guide, de Daniel J. Barrett e Richard Silverman. É um excelente livro, e cobre o programa extensivamente.
1. Algoritmos de criptografia são tipicamente vulneráveis a ataques de força bruta, onde cada chave possível é tentada sucessivamente, até que uma delas descriptografe os dados. O uso de um algoritmo forte e uma chave de tamanho suficiente torna impossível este ataque com o hardware computacional atual, pois o domínio da chave é enorme e o algoritmo de criptografia utiliza extensivos recursos de computação.
2. Existem rumores que esta técnica já foi descoberta por organizações governamentais, mas esta foi a primeira vez que a idéia foi trazida a público.
3. Alguns algoritmos de chave pública, como o RSA, tem a propriedade adicional que os dados criptografados pela chave privada somente podem ser descriptografados com a chave pública correspondente, mas este não é o caso para todos os algoritmos de chave pública.
4. Ou, pelo menos, você sabe que a chave pública que você tem combina com a chave privada dele. O problema da falsificação ("spoofing") de chave pública (no exemplo original, o roteador C pode interceptar a chave pública de A, enviar sua chave pública para B, e interceptar toda a comunicação nos dois caminhos em outra versão do ataque "man-in-the-middle") é um problema, e vários métodos tem sido criados para resolver este problema. Todos eles envolvem um terceiro componente de confiança, ou uma "teia de confiança".
5. Obviamente, uma vez que o tamanho do hash pode ser muito menor que os dados originais, 2 diferentes conjuntos de dados podem resultar no mesmo hash. O objetivo de hashes criptográficos é tornar isto tão difícil de fazer quanto possível.
6. Acesso físico à rede não é realmente necessário, é possível usar equipamentos especiais para monitorar a radiação do seu computador ou cabos de rede e ficar ouvindo suas comunicações. Eu arrisco dizer que esta não é a principal preocupação para a maioria de nós.
7. sshd significa ssh daemon, que é o servidor ssh.
8. SSL significa secure socket layer (camada de soquete seguro), e é uma camada de criptografia de segurança comum para protocolos de rede que não foram projetados originalmente com segurança em mente. Uma implementação livre do SSL está disponível em http://www.openssl.org/, e é usada pelo OpenSSH.
9. Ele funciona criando um display X falso na máquina remota (por padrão ele usa o display :10) e repassa todas as conexões para aquele display através de um tunel criptografado para o teu display local.
10. Seja cuidadoso ao copiá-lo! Este arquivo tende a ter várias linhas, mas PRECISA estar em uma única linha no arquivo authorized_keys, ou o servidor irá recuras a mesma. Se você copiar e colar o mesmo em vez de transferir o arquivo diretamente, você terá de juntar as linhas manualmente[*].
11. Em seu modo normal de operação, o servidor FTP irá criar uma nova conexão de volta ao cliente e usar esta conexão para transferir dados. Por isto é preciso algum truque para conseguir que as duas conexões trafeguem pelo ssh. Não é impossível, mas geralmente dá mais trabalho que vale.
[nota do editor, por DJBongHit] Eu alterei a descrição incorreta do OpenSSH à pedido de Theo De Raadt - é uma implementação livre dos protocolos SSH1 e SSH2 (SECSH).
Discussão completa: http://www.kuro5hin.org/story/2001/10/21/134817/35
Todas as marcas registradas e copyrights nesta página são propriedade de suas respectivas companias. O resto © 2000 - 2001 Kuro5hin.org Inc.
* Nota do Tradutor: sendo um usuário do ssh e costumando utilizar o mesmo juntamente com pares de chaves pública/privada, descobri que a melhor forma de acrescentar uma chave (e, até prova em contrário, a mais simples) é usar um comando como o abaixo:
$ cat identity.pub >> ~/.ssh/authorized_keys
O único cuidado é verificar se o diretório ~/.ssh existe antes de executar o comando.