PuTTY solicita um arquivo de chave privada no formato PPK, enquanto um servidor Linux OpenSSH permite uma chave pública na conta visada. Esses dois arquivos não vão para o mesmo lugar: o PPK permanece na sua estação Windows, a chave pública é adicionada ao authorized_keys no servidor.
Você pode criar um novo par com PuTTYgen ou importar uma chave privada OpenSSH já existente. Em ambos os casos, mantenha uma sessão funcional ou um console de backup durante o deployment. Uma chave recém-criada não dá acesso ao servidor até que sua parte pública tenha sido autorizada.
Para os parâmetros do host, da porta, da conta e a verificação inicial de sua impressão digital, siga o guia configurar a conexão PuTTY ao seu servidor Linux. Aqui, o assunto é a preparação da chave e a prova de que PuTTY realmente a utiliza.
Identifique as duas chaves e a conta Linux alvo
Um par SSH contém uma chave privada e uma chave pública. A privada serve para provar sua identidade: nunca a transmita e não a coloque no servidor. PuTTYgen a registra no formato .ppk. Proteja este arquivo no Windows com uma frase de segurança e mantenha, se necessário, um backup criptografado em um local seguro.
A chave pública pode ser comunicada ao servidor. Para OpenSSH, ela normalmente aparece em uma única linha no arquivo ~/.ssh/authorized_keys da conta Linux em questão. A conta, seu diretório pessoal e o caminho autorizado devem ser confirmados antes de qualquer modificação. Um servidor administrado pode definir outro local com AuthorizedKeysFile.
A frase de segurança protege a chave privada local; ela não é a senha da conta Linux. Uma autenticação por chave também pode permanecer sujeita a um segundo fator. Por fim, a chave do host verifica a identidade do servidor: ela é diferente da sua chave de usuário e deve sempre ser controlada.
Crie um par com PuTTYgen e salve o PPK
No seu computador Windows, abra o PuTTYgen. Escolha EdDSA com Ed25519 se o servidor e sua política aceitarem. Dependendo da versão, a rotulagem do tipo pode variar. RSA ainda é uma opção de compatibilidade se o ambiente exigir; não reative uma antiga assinatura SHA-1 ou SSH-1 para contornar um problema de cliente. Se preferir criar o par a partir de um computador Ubuntu, siga este guia para gerar uma chave SSH a partir do Ubuntu; PuTTYgen permanece o percurso descrito aqui para Windows.
Clique em Generate e siga o pedido de movimento do mouse da ferramenta. Adicione um comentário reconhecível que não revele informações sensíveis. Preencha Key passphrase e Confirm passphrase, e então clique em Save private key. Escolha um diretório privado acessível apenas aos usuários autorizados do seu computador e anote a localização do arquivo .ppk. A geração por si só não salva o arquivo.
Copie o valor exibido em Public key for pasting into OpenSSH authorized_keys file. É esta linha que deverá ser adicionada à conta Linux. O botão Save public key pode produzir um formato diferente, incluindo o RFC 4716. Não cole um bloco BEGIN SSH2 PUBLIC KEY no arquivo OpenSSH. Mantenha as configurações de formato PPK propostas pelo PuTTYgen; se um cliente não souber ler o formato, atualize-o ao invés de enfraquecer a proteção da chave.
Importar uma chave OpenSSH existente em PPK
Se você já possui a chave privada OpenSSH, importe-a no seu computador Windows com o PuTTYgen: escolha Conversions > Import key, selecione o arquivo privado e, em seguida, digite sua frase de segurança se o PuTTYgen pedir. Depois, salve uma cópia no formato PPK com Save private key.
Esta operação converte o contêiner para PuTTY; ela não cria uma nova identidade. A chave pública e sua impressão digital devem permanecer as mesmas do par original. Verifique a impressão digital no PuTTYgen antes e depois da importação e, em seguida, verifique se a pública correspondente está autorizada na conta Linux. Uma chave pública sozinha, muitas vezes nomeada com a extensão .pub, não permite reconstruir a privada. Renomear um arquivo .pem para .ppk também não o converte: os formatos variam, é necessário importá-lo e verificar se o PuTTYgen o reconhece.
Não transmita sua chave privada para um conversor Web e não a recupere de uma conta root no servidor. Se ela for perdida ou se sua frase de segurança for esquecida, crie um novo par, faça a autorização da chave pública com um acesso de backup, teste-a e depois retire a autorização antiga se ela não for mais necessária.
Adicionar a chave pública à conta correta sem sobrescrever as outras
Os seguintes comandos são executados em um shell Linux já aberto na conta alvo, não no PowerShell e não automaticamente como root. Eles servem primeiro para confirmar a identidade da conta e os caminhos envolvidos:
whoami
printf '%sn' "$HOME"
ls -ld "$HOME" "$HOME/.ssh"
ls -l "$HOME/.ssh/authorized_keys"Verifique se whoami exibe a conta prevista e que $HOME é seu diretório pessoal. Os comandos ls permitem controlar a existência, o proprietário e as permissões da pasta e do arquivo. Uma mensagem indicando que um caminho não existe pode ser normal para uma instalação nova. Não crie inadvertidamente arquivos no diretório root.
No caso padrão em que você está bem conectado a essa conta, esses comandos preparam o diretório e abrem o arquivo com o Nano:
umask 077
mkdir -p "$HOME/.ssh"
chmod 700 "$HOME/.ssh"
nano "$HOME/.ssh/authorized_keys"
chmod 600 "$HOME/.ssh/authorized_keys"umask 077 limita os direitos por padrão nesse shell. mkdir -p cria a pasta se ela estiver ausente sem apagar seu conteúdo. O modo 700 reserva a pasta .ssh para a conta; o modo 600 reserva o arquivo para o proprietário. No Nano, adicione a linha pública copiada do PuTTYgen ao final do arquivo, sem remover as linhas existentes. Salve e saia do editor. Se o arquivo já existir, faça um backup antes de modificá-lo. Não use uma redireção > que o sobrescreveria.
Após a edição, ainda no shell da conta alvo, este comando lê as impressões das chaves públicas presentes em authorized_keys:
ssh-keygen -lf "$HOME/.ssh/authorized_keys" -E sha256Compare a impressão digital esperada com a mostrada pelo PuTTYgen e identifique a entrada correta se o arquivo contiver várias chaves. Este controle se refere às chaves de usuário autorizadas, não à impressão digital da máquina remota. Não remova as outras chaves para simplificar a comparação.
Se o diretório pessoal, os proprietários, as ACL ou o caminho das chaves forem personalizados, peça ao administrador para confirmar a configuração. Evite chmod -R e um chown aplicado cegamente: eles podem modificar arquivos não relacionados com SSH. A partir de um computador Linux, um outro método consiste em instalar uma chave pública com ssh-copy-id. Este comando diz respeito a um cliente Linux, não ao PuTTY no Windows.
Selecionar o PPK no PuTTY e verificar a autenticação
No PuTTY, carregue a sessão em questão. Abra Connection > SSH > Auth > Credentials, e então escolha o arquivo em Private key file for authentication. Volte para Session e salve a configuração. Mantenha a conta remota já prevista para esta sessão.
Mantenha sua sessão de backup e abra uma nova janela do PuTTY para o teste. Se o PuTTY reportar uma impressão de host desconhecida ou modificada, compare-a a um valor obtido através de um canal confiável antes de continuar. A frase de segurança da chave privada pode ser solicitada: isso não significa que o PuTTY esteja pedindo a senha Linux.
Para confirmar o método utilizado, abra o Event Log do PuTTY e verifique se a chave esperada é proposta e aceita para a autenticação por chave pública. Um shell obtido não é suficiente por si só: o Pageant pode ter fornecido outra chave e o PuTTY também pode dispor de outro modo de autenticação. Para isolar o teste, saia temporariamente do Pageant ou remova suas chaves, e então selecione explicitamente o PPK na sessão. Se o PuTTY solicitar a senha Linux, interrompa este teste: uma conexão de fallback não prova que a chave funcionou. Respeite os fatores adicionais impostos pelo servidor.
No shell da segunda conexão, estes comandos confirmam a conta e a máquina acessadas, mas não o método de autenticação:
whoami
hostnameCompare a conta exibida com aquela visada e verifique o nome do host esperado. O Event Log do PuTTY e, se necessário, os logs do lado do servidor estabelecem o método utilizado. Não feche a sessão de backup até ter confirmado o resultado.
Utilizar Pageant sem confiar-lhe mais do que o necessário
Pageant é opcional. Comece acertando um teste direto com o PPK. Para evitar ter que inserir a frase de segurança durante as conexões seguintes, inicie o Pageant, abra sua janela, escolha Add Key, e então selecione o arquivo PPK. Desbloqueie-o localmente e verifique o comentário ou a impressão digital exibida. O PuTTY pode então solicitar ao agente que assine as trocas.
A frase de segurança protege o arquivo no disco; o Pageant facilita seu uso enquanto a chave desbloqueada permanecer disponível na memória. O agente não instala a chave pública no servidor e não substitui a verificação da impressão digital do host. Remove Key retira a chave do agente, não do authorized_keys. Para revogar o acesso deste computador, remova separadamente a linha pública correta no servidor a partir de uma sessão ainda autorizada.
Não carregue apenas as chaves úteis e mantenha a transferência do agente desativada, exceto em necessidades específicas para máquinas de confiança. Um processo malicioso no computador pode tentar abusar das assinaturas do agente. Remova as chaves do Pageant ou feche-o quando não forem mais necessárias. Nunca coloque uma frase de segurança em um atalho ou em um script.
Diagnosticar uma recusa sem enfraquecer o servidor
- Couldn’t load private key ou Unable to use key file : verifique o caminho do arquivo, seu formato e a versão do cliente. Importe a chave corretamente com o PuTTYgen; mudar sua extensão não é suficiente.
- Server refused our key : confirme a conta remota, a correspondência entre a privada e a pública, a linha OpenSSH completa, o caminho autorizado e as permissões/proprietários. Se você administra o servidor, consulte os logs no momento exato da tentativa.
- Too many authentication failures : o agente pode estar oferecendo chaves demais. Para um teste, selecione a chave correta e remova as outras do Pageant. Não aumente arbitrariamente
MaxAuthTries. - PuTTY pede uma senha : distinga a frase de segurança da chave, a senha Linux e um possível fator adicional. Pare o teste se a senha da conta for solicitada; isso não é uma prova de autenticação por chave.
A partir de um console independente ou de uma sessão de administração existente, o administrador pode consultar a unidade de log presente na distribuição. Esses comandos leem as 50 últimas entradas da unidade indicada; use a que existir, muitas vezes ssh no Debian ou Ubuntu, ou sshd em outras distribuições:
sudo journalctl -u ssh -n 50 --no-pager
sudo journalctl -u sshd -n 50 --no-pagerUm log vazio não prova que nenhuma tentativa ocorreu: a distribuição pode usar outra unidade ou outro destino de logs. Compartilhe apenas as linhas úteis, após ter ocultado os detalhes da infraestrutura. Se a configuração usar regras Match ou um caminho personalizado, peça ao administrador para verificar a configuração efetiva da conta em questão. Este artigo não pede para alterar a configuração SSH nem para desativar um controle de segurança.
Não desative StrictModes, o MFA ou a verificação do host para realizar o teste. Não permita root como atalho e não reative SSH-1 ou assinaturas fracas. Se a chave privada ou sua frase de segurança for perdida, faça um novo par via acesso de backup e verifique-o antes de retirar a autorização antiga. O controle final se refere a quatro elementos: o arquivo privado correto no Windows, a chave pública correta na conta visada, as permissões esperadas e a aceitação dessa chave no Event Log do PuTTY.