O authorized_keys é o ficheiro do OpenSSH que lista as chaves públicas autorizadas a iniciar sessão numa conta. Para que o sshd o aceite, o ~/.ssh tem de ter permissões 700 e o authorized_keys 600, sem permissão de escrita para o grupo nem para outros. Cada linha pode incluir opções como from=, command= e no-pty, que limitam de onde uma chave se liga e o que pode executar.
Permissões do authorized_keys: 700 no ~/.ssh e 600 no ficheiro
O sshd ignora o authorized_keys quando o ~/.ssh ou o próprio ficheiro estão mais abertos do que o esperado: 700 para o ~/.ssh e 600 para o authorized_keys e para as chaves privadas. A verificação vem da diretiva StrictModes do sshd_config, ativa por predefinição, que também confirma que o seu diretório pessoal não tem permissão de escrita para o grupo nem para outros.
chmod go-w ~
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R "$(id -un)":"$(id -gn)" ~/.ssh
ls -ld ~ ~/.ssh ~/.ssh/authorized_keysQuando algo está mal, o log do servidor di-lo sem rodeios: procure linhas como Authentication refused: bad ownership or modes. No Debian e no Ubuntu, lê-as com journalctl -u ssh; noutras distribuições, a unidade chama-se sshd. Desativar o StrictModes para sair do impasse é um mau negócio: esconde o problema e permite que outro utilizador com permissão de escrita no seu diretório pessoal introduza a sua própria chave.
Opções do authorized_keys: from=, command= e no-pty com exemplos
Cada linha do authorized_keys segue o formato [options] keytype key comment, com as opções separadas por vírgulas, sem espaços, colocadas antes do tipo de chave. A lista completa encontra-se na secção AUTHORIZED_KEYS da página de manual oficial do sshd.
from="203.0.113.0/24,198.51.100.7",no-pty,no-port-forwarding ssh-ed25519 AAAAC3Nza... admin@phone
command="/usr/local/bin/backup.sh",restrict ssh-ed25519 AAAAC3Nza... backup@nas
restrict,pty ssh-ed25519 AAAAC3Nza... support@laptop- from="patterns": a chave só é aceite quando o cliente se liga a partir desses endereços ou nomes de host. São permitidos curingas, notação CIDR e negação com
!. - command="…": força esse comando independentemente do que o cliente pedir. O comando pedido fica guardado em
SSH_ORIGINAL_COMMANDpara que um script o possa validar. - no-pty: não é atribuído nenhum terminal. Útil para chaves de rsync, de backup ou de deploy.
- no-port-forwarding, no-agent-forwarding, no-X11-forwarding: desativam cada tipo de reencaminhamento individualmente.
- restrict: desativa tudo o que está acima de uma só vez; depois volta a ativar o que precisar, por exemplo com
pty.
Combinar command= com restrict é o padrão habitual para chaves de backup: mesmo que a chave seja divulgada, só consegue executar esse script. O from= acrescenta uma segunda barreira, mas um telemóvel em dados móveis raramente tem um IP de origem fixo. Nesse caso, compensa entrar através de uma rede mesh privada como o Prialo ou o Tailscale e fixar o from= nos endereços dessa rede.
5 erros comuns no authorized_keys e como os detetar
O primeiro passo de diagnóstico é sempre ssh -v user@server: mostra que chaves o cliente oferece e onde o servidor as recusa.
- Permissões ou dono errados. Copiar o ficheiro como root deixa-o com root como dono, e o sshd ignora-o. O bloco de chmod e chown acima resolve o problema.
- Chave partida em várias linhas. Colar a partir de um editor que faz quebra de linha automática estraga a chave. Cada chave tem de ocupar exatamente uma linha.
- Opções com espaços ou aspas por fechar. Um espaço depois de uma vírgula ou uma aspa de fecho em falta invalida a linha inteira, e o sshd descarta-a sem avisar o cliente.
- Chave RSA rejeitada pelo algoritmo. Desde o OpenSSH 8.8, a assinatura
ssh-rsacom SHA-1 está desativada por predefinição, pelo que os clientes mais antigos deixam de conseguir entrar. A solução é passar para Ed25519, suportado desde o OpenSSH 6.5. - command= a estragar o Mosh, o SFTP ou o scp. O Mosh arranca o
mosh-serveratravés de uma ligação SSH inicial e o SFTP pede o seu subsistema; um command= fixo substitui ambos. Desde o OpenSSH 9.0, o scp usa SFTP por predefinição, pelo que também falha. Mantenha chaves separadas para sessões interativas e para automatização.
Gerir o authorized_keys no iOS e no Android versus num computador
A chave privada pode ser gerada no próprio telemóvel e guardada no armazenamento seguro do sistema, pelo que o servidor só precisa que a linha pública seja acrescentada ao authorized_keys.
| Tarefa | iOS/Android com o termi1 | Computador com OpenSSH |
|---|---|---|
| Gerar a chave | No telemóvel; guardada no armazenamento seguro | ssh-keygen -t ed25519 |
| Instalar a chave pública | Colar no authorized_keys ou emparelhar um Mac através do Companion | ssh-copy-id user@server |
| Inspecionar o ficheiro | SFTP integrado sem sair da sessão | Editor local ou cliente sftp |
| Editar com vim ou nano | Teclado personalizado com Esc, Ctrl, Tab e setas | Teclado físico |
| Quebra de rede a meio de uma tarefa | O Mosh e o tmux mantêm a sessão ativa | A sessão SSH morre |
No terminal SSH e Mosh termi1, a chave privada nunca sai do dispositivo nem chega aos servidores da Sinergia, e o termi1 Companion (macOS 14 ou posterior) instala a chave pública num Mac com um código de seis dígitos. Peça à IA para "corrigir as permissões do ssh" e ela escreve chmod 600 ~/.ssh/authorized_keys na linha de comandos sem premir Enter; nas ligações marcadas como produção, o Production Guard retém tudo o que altere o estado. O terminal é gratuito, funciona sem conta e está disponível na App Store e no Google Play.
Perguntas frequentes
Que permissões deve ter o authorized_keys?
O authorized_keys deve ter permissões 600, com leitura e escrita apenas para o dono, e o diretório ~/.ssh deve ter 700. Com o StrictModes ativo, que é a predefinição, o sshd ignora o ficheiro se o grupo ou outros puderem escrever nele, no ~/.ssh ou no diretório pessoal.
O que faz o command= no authorized_keys?
O command= no authorized_keys força um comando específico sempre que alguém se autentica com essa chave, seja qual for o pedido do cliente. O comando pedido fica guardado na variável SSH_ORIGINAL_COMMAND. Usa-se tipicamente em chaves de backup e de deploy, combinado com restrict ou no-pty.
Porque é que o SSH continua a pedir a palavra-passe depois de adicionar a minha chave?
O SSH recorre à palavra-passe quando o sshd não aceita nenhuma chave do authorized_keys. As causas habituais são permissões demasiado abertas, o dono errado, uma chave partida em várias linhas ou uma opção mal escrita. Executar ssh -v no cliente e ler o log do sshd no servidor identifica qual é.
O Mosh funciona com uma chave restrita no authorized_keys?
O Mosh funciona com chaves restritas desde que não tenham command=, porque arranca o mosh-server através de uma ligação SSH inicial. Depois disso, a sessão corre sobre UDP, por predefinição nas portas 60000-61000, que têm de estar abertas na firewall do servidor.