Eu tenho um conjunto de chaves SSH para acessar contas e servidores. No entanto, desde que eu mudei o meu perfil de trabalho principal para uma unidade USB (para sincronização e facilidade de uso, entre outras razões) eu fui incapaz de diretamente usar as chaves SSH no perfil para autenticação, tendo que crie cópias locais em vez disso.
O fluxo de trabalho normal do SSH costuma ser
ssh-add $HOME/.ssh/id_server_key
ssh username@domain
Que funciona sem problemas. No entanto, para impedir que cada máquina tenha uma cópia das minhas chaves, eu as movi para uma unidade xexternal, formatada como vfat . Então o fluxo de trabalho deve ser assim:
ssh-add /run/media/myself/USB/.ssh/id_server_key
ssh username@domain
... O que não funciona. SSH reclama sobre fazer algo para me proteger:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: UNPROTECTED PRIVATE KEY FILE! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for 'id_server_key' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
bad permissions: ignore key: id_server_key
Permission denied (publickey).
Que, embora eu possa entender, não é realmente que me protege neste caso.
O drive USB monta automaticamente na minha distro, com um fmask de (eu acho) 022 . Eu poderia desmontar e remontar a unidade USB com um fmask de 077 , mas isso exigiria (1) privilégios de superusuário a cada vez e (2) afetaria cada arquivo no dispositivo, não apenas as chaves SSH.
Eu tentei criar um link simbólico para a chave, mesmo com o uso anterior de umask , como já vi em algumas dicas e truques:
cd .ssh
umask 077
ln -s /run/media/myself/USB/.ssh/id_server_key
Mas as permissões não podem ser usadas dessa forma para um link simbólico, então eu não recebo nada.
Então, quais opções tenho aqui disponíveis se o objetivo for não ter uma cópia física da chave na máquina? Uma das máquinas é um laptop familiar que vai para vários lugares, por isso tenho interesse em evitar que algumas das chaves sejam descobertas.
Até agora eu considerei o seguinte:
- Existe, por exemplo, uma opção para forçar o SSH (
ssh-add principalmente) a aceitar as chaves do dispositivo externo? (Presumo que deva existir - a maioria dos programas segue um sinalizador "sei-o-que-estou-fazendo", mas até agora não consigo encontrá-lo na página do manual.
- Definindo um
bindfs sobre o diretório .ssh/ , mas o problema é que o diretório não está vazio (pois contém known_hosts e outros dados).
-
fuse-zip -executar as chaves em /dev/shm também parece ser um caminho possível.
EDITAR : Conforme o comentário de @Gilles, sim, bindfs resolve o problema. Após uma verificação da página de manual, o teste inicial foi bem-sucedido usando a seguinte chamada:
bindfs -n -r -p 0700 -o nonempty /run/media/myself/USB/.ssh/ ~/.ssh
Que liga a não permissão de acesso de outros usuários (aparentemente mesmo de root !), somente leitura, com permissões 0700 refletidas. Essa reflexão foi a parte que me faltou quando trabalhei com bindfs originalmente. O sinalizador nonempty foi necessário devido a arquivos preexistentes, como known_hosts . Isso preserva o fluxo de trabalho original exatamente, exceto por um messae de aviso extra sobre não ser possível adicionar informações a known_hosts (que no final eu não me importaria).
Claro, eu estou ligando para outro diretório agora (em / dev / shm) como originalmente sugerido para tornar as coisas um pouco mais fáceis.
Eu não sou tão conspiranóide quanto ao encfs do meu pendrive (ainda), então, com relação à privacidade, isso é bom o suficiente para mim.