Existe uma maneira de transmitir dados confidenciais no bash usando um prompt, para qualquer comando?

Suponha que eu estivesse usando sha1passpara gerar um hash de alguma senha confidencial na linha de comando. Eu posso usar sha1pass mysecretpara gerar um hash, mysecretmas isso tem a desvantagem que mysecretestá agora no histórico do bash. Existe uma maneira de atingir o objetivo final deste comando, evitando revelar mysecretem texto simples, talvez usando um passwdprompt de estilo?

Também estou interessado em uma maneira generalizada de fazer isso para passar dados confidenciais para qualquer comando. O método mudaria quando os dados confidenciais fossem passados ​​como um argumento (como em sha1pass) ou no STDIN para algum comando.

Existe uma maneira de conseguir isso?

Edit : Esta questão atraiu muita atenção e houve várias boas respostas oferecidas abaixo. Um resumo é:

• De acordo com a resposta de @ Kusalananda , o ideal seria nunca dar uma senha ou segredo como argumento da linha de comando a um utilitário. Isso é vulnerável de várias maneiras, conforme descrito por ele, e deve-se usar um utilitário melhor projetado, capaz de receber informações secretas sobre o STDIN
• A resposta de @ vfbsilva descreve como impedir que coisas sejam armazenadas no histórico do bash
• A resposta de @ Jonathan descreve um método perfeitamente bom para fazer isso, desde que o programa possa levar seus dados secretos para o STDIN. Como tal, decidi aceitar esta resposta. sha1passno meu PO era apenas um exemplo, mas a discussão estabeleceu que existem melhores ferramentas que utilizam dados no STDIN.
• como @R .. observa em sua resposta , o uso da expansão de comando em uma variável não é seguro.

Então, em resumo, aceitei a resposta do @ Jonathan, já que é a melhor solução, pois você tem um programa bem projetado e comportado para trabalhar. Embora passar uma senha ou segredo como argumento da linha de comando seja fundamentalmente inseguro, as outras respostas fornecem maneiras de atenuar os simples problemas de segurança.

Se estiver usando o zshou bashshell, use a opção -s no readshell interno para ler uma linha do dispositivo terminal sem que ele ecoe.

IFS= read -rs VARIABLE < /dev/tty

Então você pode usar algum redirecionamento sofisticado para usar a variável como stdin.

sha1pass <<<"$VARIABLE"

Se alguém executar ps, tudo o que verá é "sha1pass".

Isso pressupõe que sha1passlê a senha de stdin (em uma linha, ignorando o delimitador de linha) quando não recebe nenhum argumento.

Idealmente, você nunca digita uma senha de texto não criptografado na linha de comando como argumento para um comando. Isso faz da senha um argumento para o comando, e os argumentos da linha de comando podem ser vistos na tabela de processos, usando ferramentas simples como psou registradas em alguns logs de auditoria.

Dito isto, certamente existem maneiras de ocultar a senha real do histórico de comandos do shell.

sha1pass "$( head -n 1 )"

Em seguida, digite a senha e pressione Enter. O headcomando usado aqui aceita exatamente uma linha de entrada e a última nova linha que você digita não fará parte dos dados transmitidos sha1pass.

Para impedir que os caracteres ecoem:

sha1pass "$( stty -echo; head -n 1; stty echo )"

O stty -echocomando desativa o eco dos caracteres digitados no terminal. O eco é então restaurado com stty echo.

Para passar a entrada padrão, esse último comando pode ser alterado (você o faria se os sha1passdados aceitos na entrada padrão, mas parece que esse utilitário em particular está ignorando sua entrada padrão):

{ stty -echo; head -n 1; stty echo; } | somecommand

Se você precisar de entrada com várias linhas (o que foi dito acima pressupõe que uma única linha deva ser transmitida, sem nenhum caractere de nova linha no final), substitua o headcomando inteiro por cate encerre a entrada (supondo que somecommandele leia até o final do arquivo) com Ctrl+D( a seguir, Returnse você deseja incluir um caractere de nova linha na entrada ou duas vezes, se não).

Isso funcionaria independentemente de qual shell você estivesse usando (desde que fosse um shell tipo Bourne ou rc).

Alguns shells podem ser feitos para não salvar os comandos digitados nos arquivos de histórico se o comando for precedido por um espaço. Isso geralmente envolve ter que definir HISTCONTROLo valor ignorespace. Isso é suportado pelo menos bashe kshno OpenBSD, mas não por exemplo ksh93ou dash. zshos usuários podem usar a histignorespaceopção ou sua HISTORY_IGNOREvariável para definir um padrão a ser ignorado.

Nas conchas que suportam a leitura readsem ecoar caracteres no terminal, você também pode usar

IFS= read -rs password     # -s turns off echoing in bash or zsh
                           # -r for reading backslashes as-is,
                           # IFS= to preserve leading and trailing blanks
sha1pass "$password"

mas isso obviamente ainda tem o mesmo problema em potencialmente revelar a senha na tabela de processos.

Se o utilitário ler da entrada padrão e se o shell suportar "here-strings", o acima poderá ser alterado para

IFS= read -rs password
somecommand <<<"$password"

Resumo dos comentários abaixo:

• A execução de um comando com uma senha fornecida na linha de comando, como todos os comandos acima, exceto o que canaliza os dados para o comando, potencialmente tornará a senha visível para qualquer pessoa que esteja executando psao mesmo tempo. No entanto, nenhum dos comandos acima salvará a senha digitada no arquivo de histórico do shell se executada a partir de um shell interativo.

• Programas bem comportados que leem senhas em texto não criptografado fazem isso lendo suas entradas padrão, um arquivo ou diretamente do terminal.

• sha1pass requer a senha na linha de comando, digitada diretamente ou usando alguma forma de substituição de comando.

• Se possível, use outra ferramenta.

Se você definir HISTCONTROLassim:

HISTCONTROL=ignorespace

e inicie o comando com um espaço:

~$  mycommand

não será armazenado no histórico.

Passe dados confidenciais por um canal ou aqui-doc:

command_with_secret_output | command_with_secret_input

ou:

command_with_secret_input <<EOF
$secret
EOF

É bom que os segredos estejam em variáveis ​​de shell (não exportadas), mas você nunca pode usá-las em linhas de comando, apenas em documentos aqui e em shell internals.

Como observado por Kusalananda em um comentário, se você estiver digitando comandos em um shell interativo, as linhas que você digitar para um documento aqui serão armazenadas no histórico do shell, portanto, não é seguro digitar uma senha lá, mas ainda deve ser seguro usar variáveis ​​de shell contendo segredos; a história conterá o texto $secrete não o que for $secretexpandido.

O uso de expansões de comando não é seguro :

command_with_secret_input "$(command_with_secret_output)"

porque a saída será incluída na linha de comando e visível na pssaída (ou leitura manual de / proc), exceto em sistemas com / proc reforçado.

A atribuição a uma variável também é aceitável:

secret=$(command_with_secret_output)

Basta escrever o valor em um arquivo e passar o arquivo:

$ cat > mysecret
Big seecreeeet!
$ cat mysecret | sha1pass 

Não sei ao certo como sha1passfunciona; se ele pode receber um arquivo como entrada, você pode usá-lo sha1pass < mysecret. Caso contrário, o uso catpode ser um problema, pois inclui a nova linha final. Se for esse o caso, use (se o seu headsuporte -c):

head -c-1 mysecret | sha1pass 

Se o que o terdon fez é possível, essa é a melhor solução, passando pela entrada padrão. O único problema que resta é que ele escreveu a senha no disco. Em vez disso, podemos fazer isso:

stty -echo
echo -n "password: "
head -1 | sha1pass
stty echo

Como Kusalananda disse, stty -echogarante que o que você digita não é visto até que você faça stty echonovamente. head -1obterá uma linha da entrada padrão e a passará para sha1pass.

eu usaria

sha1pass "$(cat)"

cat leria de stdin até EOF , o que pode ser causado pressionando Ctrl + D. Em seguida, o resultado seria passado como argumento parasha1pass