[pastage]

Sending your command history automatically over the network is always an huge security risk. This tool atleast have a security section in the readme, but nothing about operational security and how to guard against hacks of one synced agent.

I will try it because the history tool looks like an interesting take, but the security model is not ok for multi computer use.

[ellieh]

I think my main concern here is the fact that you're putting secrets in your shell history!

[dopidopHN]

Mistake happen.

Yesterday I was tired and working on a friend serveur. The ssh prompt was different and I entered the password from a account while the remote port has hang up on me. So effectively typing “password” straight on my shell.

His password is in my history now. I removed it but that type of thing happen all the time. ( Not that much in a professional settings, password tends to fade away )

[capableweb]

Pro-tip: if you wanna hide stuff from your shell history, enter a space/blank before the actual command.

Not that it probably would have helped in this situation, but maybe useful for others.

Usually if I have to enter secrets in my shell, I do something like this in order to save the useful stuff to history but hiding the secrets:

- ` export PASSWORD=hunter2` (notice the space before "export")

- `service-cli login username $PASSWORD` (no space before, gets saved to shell history)

[Cockbrand]

While ignoring commands preceded by a space character is absolutely one of my very favorite shell features, it usually isn't enabled by default (YMMV).

HISTCONTROL=ignorespace # bash

setopt hist_ignore_space # zsh

These go into ~/.bashrc or ~/.zshrc, respectively. zsh is really smart about this and always enables you to retrieve the immediate previous line with arrow-up, no matter whether it's got preceding whitespace or not.

[ddworken]

+1 to prefixing with a space. hiSHtory supports this out of the box so that anything prefixed with a space isn't recorded (even if your shell doesn't do that by default!). And if you do ever mess up, `hishtory redact` can be used to delete history entries.

[remram]

Other options:

- read -s PASSWORD

- service-cli login username $(cat)

At least you probably don't want to use `export` when setting the variable.

[400thecat]

why use `export` ? That is a terrible idea.

[Cockbrand]

I've certainly entered passwords at the shell prompt by accident. This doesn't happen often, but it sure does.

[ilyt]

Some apps only accept password in commandline.

The better written ones might accept it in env but that will also stay in history.

But if someone have access to your home they can put keylogger in the .profile/.bashrc so it's not really relevant...

[ellieh]

Sure, but something like this also works well:

`the-command --password $(read -s;echo $REPLY)`

[ilyt]

yeah now instead of history you can get the app's password via `ps aux` :D

also you still have the `export REPLY=password` in history.

sure you can source it out of file but, well, that file have same permissions (or looser! if you forgot to change) as your .bash_history file.

`cat password|command` is the safest one (or, well, something 12 factor app clowns hate, a config file)