Hoje terminei uma parte importante da organização das minhas senhas: exportei uma cópia do meu cofre do KeePassXC e coloquei os dados no pass, o gerenciador de senhas simples do mundo Unix.
\nO motivo principal não foi abandonar o KeePassXC imediatamente. Foi experimentar uma integração melhor com o terminal. Como eu já passo bastante tempo no shell, queria conseguir consultar senhas, copiar credenciais e gerar códigos OTP sem sair desse ambiente.
\nPor enquanto vou manter os dois fluxos: o KeePassXC continua sendo a referência principal e o pass fica como uma segunda cópia em estudo. Ainda estou avaliando a melhor forma de sincronizar os dois cofres sem criar conflitos ou perder alterações.
A ideia do pass é direta: cada entrada vira um arquivo de texto criptografado com GPG. O nome da entrada organiza o cofre e a senha fica na primeira linha.
O ponto de partida foi o meu cofre do KeePassXC. O KeePassXC permite exportar as entradas para CSV, então fiz essa exportação antes de começar a migração.
\nO CSV é útil para transportar os dados, mas não é um formato adequado para deixar espalhado por aí: ele contém as senhas em texto puro. Por isso tratei o arquivo como uma etapa temporária e restrita, sem colocá-lo no Git, no servidor remoto ou na nuvem.
\nDepois da exportação, criei uma versão sanitizada do arquivo. Nessa etapa eu:
\nO arquivo intermediário foi:
\n~/caminho/para/senhas.sanitized.csv\nSó depois dessa normalização o conteúdo foi importado para o pass. Ao final, o CSV continuou protegido com permissões restritas e não foi adicionado ao repositório de configurações.
Eu tinha um arquivo com minhas senhas em CSV. Ele tinha usuários, senhas, URLs, anotações e alguns tokens de autenticação em dois fatores.
\nAntes de importar, organizei os nomes dos grupos. Em vez de caminhos longos como meu cofre/família/pessoa, passei a usar nomes mais curtos:
familia.pessoa\nfamilia.outro\nempresa.exemplo\nempresa.outro\nTambém substituí espaços nos nomes dos itens por pontos. Assim, uma entrada ficou parecida com:
\nempresa.exemplo/ambiente.de.stage\nfamilia.pessoa/banco.inter\nO processo ficou assim:
\n\nForam importadas 223 entradas. Depois conferi se todas podiam ser descriptografadas e se as senhas estavam na primeira linha, que é o formato esperado pelo pass.
Também instalei a extensão pass-otp. Ela usa as URIs padrão otpauth:// para gerar códigos de autenticação de dois fatores.
Na primeira importação, eu tinha colocado a URI assim:
\nTOTP: otpauth://totp/...\nParecia organizado, mas a extensão não encontrava o token. O formato correto é deixar a URI em uma linha própria:
\notpauth://totp/...\nDepois de ajustar o CSV, zerei o cofre e importei tudo novamente. O resultado foi melhor: as entradas com OTP passaram a funcionar com o comando:
\npass otp "empresa.exemplo/servico.otp" Ou copiando o código diretamente para a área de transferência:
\npass otp -c "empresa.exemplo/servico.otp" Para criar uma nova entrada, uso pass insert:
pass insert empresa.exemplo/nova-senhaO pass pede a senha no terminal e salva o resultado criptografado. Para guardar também usuário, URL e outras informações, uso o modo multiline:
pass insert --multiline empresa.exemplo/nova-senhaO formato fica assim:
\nminha-senha\nUsername: meu.usuario\nURL: https://servico.example\nNotes: alguma observação\nA senha fica na primeira linha. Isso permite usar pass -c para copiar somente a senha:
pass -c empresa.exemplo/nova-senhaPara adicionar um token de autenticação, uso a extensão pass-otp:
pass otp insert empresa.exemplo/nova-senhaO comando pede uma URI no formato otpauth://. Normalmente ela vem do QR Code exibido pelo serviço ao ativar o segundo fator.
Se eu já tenho uma entrada de senha e quero adicionar o OTP nela, uso append:
pass otp append empresa.exemplo/nova-senhaDepois posso gerar o código com:
\npass otp empresa.exemplo/nova-senhaOu copiá-lo para a área de transferência:
\npass otp -c empresa.exemplo/nova-senhaA URI do OTP é armazenada como uma linha própria dentro da entrada, começando diretamente com otpauth://.
Meu ~/.password-store já era um repositório Git com um servidor remoto configurado. Isso significa que o pass consegue criar commits quando uma entrada é adicionada ou atualizada.
Depois da reorganização, os nomes antigos foram removidos e as entradas novas ficaram nos grupos empresa.* e familia.*. Fiz a consolidação em um commit e enviei para o servidor remoto.
O fluxo ficou assim:
\n\nO servidor remoto recebe somente os arquivos criptografados. Mesmo assim, o repositório não substitui o backup da chave GPG. Sem a chave privada, os arquivos .gpg continuam inacessíveis.
Foi aí que veio a próxima pergunta: e se esta máquina quebrar?
\nA chave GPG não deve ficar somente em um computador. Também não é uma boa ideia colocar uma cópia sem proteção em um serviço de nuvem.
\nEm vez de copiar todo o ~/.gnupg, preparei um script genérico no meu repositório de configurações pessoais:
scripts/backup-gnupg.sh\nO script exporta somente o que importa para recuperar a identidade:
\nownertrust;Ele não copia sockets, cache, locks nem arquivos temporários do agente GPG.
\nO resultado é um arquivo 7-Zip criptografado com uma senha própria:
\n\nA senha do arquivo 7-Zip é diferente da senha da chave GPG. Isso é importante: são duas camadas diferentes de proteção.
\nO repositório dotfiles é o lugar das minhas configurações pessoais e dos pequenos scripts que ajudam a recuperar o ambiente.
Para este setup, versionei o script genérico de backup seletivo do GPG e sua documentação. O backup criado não foi colocado no repositório. O Git guarda o script que sabe criar o backup, não o arquivo com as minhas chaves privadas.
\nO mais importante de hoje não foi somente trocar um gerenciador de senhas. Foi experimentar um fluxo mais próximo do terminal sem abandonar o KeePassXC antes de entender bem a sincronização.
\nPor enquanto, os dois cofres convivem. Foi uma migração controlada, não uma troca definitiva.
\nTambém consegui separar melhor as coisas:
\npass guarda uma cópia criptografada e acessível pelo terminal;dotfiles documenta como refazer o setup.Ainda quero testar a restauração completa em uma máquina virtual. Backup bom não é o que existe. É o que foi restaurado com sucesso pelo menos uma vez.
\n", "summary": "", "date_published": "2026-09-08T00:00:00-00:00", "image": "", "authors": [], "tags": [ "tech", "vida", "open-source" ], "language": "pt-br" } ] }