
Bashhub  – Bash History in the Cloud - nikolay
https://bashhub.com/
======
0fx
There are people who use bash enough--and in such a way--that they'd benefit
from this kind of .bash_history backup and analysis.

There are people who would not be wary of sending this kind of information
remotely to be stored by someone else.

But I think the intersection of these types would be small.

~~~
shaan7
Well, the people in the first category will usually be smart enough to setup a
sync without using an external "cloud service".

~~~
porker
> Well, the people in the first category will usually be smart enough to setup
> a sync without using an external "cloud service".

Apart from some, like myself.

How would you go about it, given the need for 2-way sync? I've ruled out
rsync, could see Git working but not particularly performant to run every 20
seconds to keep the history in sync between machines.

~~~
deadbunny
I use git to sync my dotfiles (pulled in by SaltStack because I'm crazy enough
to put my workstations under config management) I just have a script that does
a git commit -am "automated push on $(date)" that triggers when I lock my
screen. It's not perfect but it works well enough for my needs, though I don't
sync my bash history.

------
bahador
I like the idea a lot, but the security implications of this are scary. May as
well just do a cloud based key stroke recorder.

~~~
rcaloras
In defense, you're not recording keystrokes. Simply taking bash history which
is already recorded locally and moving it to the cloud.

~~~
nullrouted
You are giving all your bash history to a third party, that is incredibly
scary and if you can't see the security implications then you need to rethink
your product.

~~~
rcaloras
Agree privacy is a concern. You can configure what you do and don't send as
well.

~~~
nullrouted
Seriously I don't think you really understand the implications here or you
aren't taking them seriously, if you did you sure wouldn't be talking about
this so nonchalantly. You should seriously shut this down before you get some
young programmers/admins fired or worse.

Also from your FAQ what the hell is "strong level encryption", can you not
name it? Can you go into the extreme technical details of what encryption you
are using, how data is protected in memory and at rest?

~~~
Terretta
The FAQ says 'storage level encryption' which presumably means volume
encryption, but in any case is unlikely to protect against anyone gaining
access to the box, only against someone making off with the physical storage.

------
voltagex_
>#ignore added to any command will omit it from being saved. Simply add it to
the end of any command and it won't be recorded in Bashhub.

A space at the start of the command will do the same in Bash itself - with
this work for bashhub?

~~~
rcaloras
Yes, if you configure your history to ignore space. It won't be put in
Bashhub.

Actually just added a filter command as well. You can export BH_FILTER="some-
regex" and it'll ignore all those commands. Just released in 0.0.14!

~~~
rcaloras
[https://github.com/rcaloras/bashhub-client#filtering-
command...](https://github.com/rcaloras/bashhub-client#filtering-commands)

------
gruez
I might be okay with this if the data was encrypted client side prior to
upload.

------
bariumbitmap
How does it compare to shellsink?

[https://github.com/joshuacronemeyer/shellsink](https://github.com/joshuacronemeyer/shellsink)

(Besides being actively developed.)

------
rcaloras
Creator here! Wow, didn't think this would get posted on HN all of a sudden.
Would love to hear your feedback or ideas, I'm very actively developing the
project. ryan@bashhub.com

~~~
voltagex_
The security implications are terrifying.

~~~
dllthomas
I'd hope not. What winds up in _your_ bash history?

[In case it wasn't clear, above was mildly tongue-in-cheek; secrets should
_not_ be in your bash history, but of course things approaching (and
including) PII may well be]

~~~
nodesocket
Not saying I make of habit of this, but sometimes you have to pass sensitive
things as arguments (passwords, api tokens, customer data, etc), it happens.

I think client side encryption by Bashhub would alleviate this security
concern.

~~~
voltagex_
One of the AWS config utilities comes to mind - you have to paste in your AWS
key if running interactively.

~~~
nodesocket
Actually `aws configure` is interactive when it asks for input. Those values
won't be stored in `history`.

------
TurboHaskal
Weird that one would agree to that. I don't even store my shell history on
private computers.

~~~
dllthomas
_" I don't even store my shell history on private computers."_

Any particular reason for that? It seems devastating to usability, for unclear
benefit...

~~~
TurboHaskal
It was the default behavior on OpenBSD's pdksh and my paranoid self grew to
like it.

I view abusing your shell history as a symptom of lack of automation and
functions/aliases.

Results May Vary, but in a way it made me more organized.

------
dllthomas
This is very interesting. Somewhat related, by _far_ my biggest history-
related usability/efficiency win has been to separate out different history
files for different contexts.

------
_alex_
If you rely on your shell history to the level that you need synchronization
via a cloud-based service, it should be a signal that your automation needs
work.

------
heyrhett
chattr +a ~/.bash_history

~~~
voltagex_
What does this do?

~~~
fabulist
After some experimentation, it makes a file impossible to delete.

Very clever, +1.

~~~
voltagex_
I wonder if this solves the issue of multiple bash instances clobbering
history.

~~~
dllthomas
From the bash manpage:

    
    
        If the histappend shell option  is  enabled (see  the description of shopt
        under SHELL BUILTIN COMMANDS below), the lines are appended to the history
        file, otherwise the history  file  is overwritten.
    
    
        histappend
            If  set,  the history list is appended to the file named
            by the value of the HISTFILE  variable  when  the  shell
            exits, rather than overwriting the file.

~~~
voltagex_
[http://askubuntu.com/a/80380/288724](http://askubuntu.com/a/80380/288724)
looks like it might be my issue, specifically

> The bash session that is saved is the one for the terminal that is closed
> the latest.

------
saurik
I have routinely kept my history "best effort" for many many years now by
exporting HISTSIZE=10000 and HISTFILESIZE=1000000, and then occasionally doing
a cp -a ~/.bash_history{,-$(date +%s)}. I actually use this history archive,
and wish it was higher fidelity. (In practice, I am thinking I should just run
all my sessions through script... ;P.)

[http://man7.org/linux/man-
pages/man1/script.1.html](http://man7.org/linux/man-pages/man1/script.1.html)

I have thereby had it on my todo list for a month or so, ever since I learned
of the bash DEBUG trap, to instead store my history into an sqlite3 database
and have it separated by host. Seeing this reminded me "oh yeah, I really
should do that" (as no: there's no way in hell I'm going to just send all of
the commands I type to some random guy with a website ;P).

This is "the simplest thing that could possibly work" and might very well
break if you set some crazy history configuration variables I don't use. Note
that it works for pipes specifically and only because it can overwrite the
same entry to the database multiple times using "insert or replace"
(prevention of which is what normally makes these scripts so complex).

    
    
        histsql=~/.bash_sqlite3
    
        sqlite3 "${histsql}" '
            create table if not exists "session" (
                "id" integer not null primary key autoincrement,
                "address" text not null,
                "process" integer not null,
                "tty" text not null,
                "user" text not null,
                "start" timestamp not null default current_timestamp,
                "end" timestamp null
            );
    
            create table if not exists "command" (
                "session" integer not null,
                "line" integer not null,
                "time" timestamp not null default current_timestamp,
                "pwd" text not null,
                "text" text not null,
                primary key ("session", "line")
            );
        '
    
        histmac=$(ifconfig | sed -e 's/  *$//; /\(ether\|HWaddr\) / { s/.* //; q; }; d;')
        histtty=$(tty)
    
        histssn=$(sqlite3 "${histsql}" "
            insert into \"session\" (
                \"address\", \"process\", \"tty\", \"user\"
            ) values (
                '${histmac//\'/''}', '${$//\'/''}',
                '${histtty//\'/''}', '${USER//\'/''}'
            );
    
            select last_insert_rowid();
        ")
    
        function histend {
            sqlite3 "${histsql}" "
                update \"session\" set
                    \"end\" = current_timestamp
                where
                    \"id\" = '${histssn//\'/''}';
            "
        }
    
        trap histend EXIT
    
        function histadd {
            local data="$(HISTTIMEFORMAT= history 1)"
            if [[ -z $data ]]; then return; fi
    
            data="${data#"${data%%[![:space:]]*}"}"
            local line="${data%%' '*}"
    
            data="${data#*' '}"
            data="${data#"${data%%[![:space:]]*}"}"
    
            sqlite3 "${histsql}" "
                insert or replace into \"command\" (
                    \"session\", \"line\",
                    \"pwd\", \"text\"
                ) values (
                    '${histssn//\'/''}', '${line//\'/''}',
                    '${PWD//\'/''}', '${data//\'/''}'
                );
            "
        }
    
        trap histadd DEBUG

~~~
dllthomas
_" (In practice, I am thinking I should just run all my sessions through
script... ;P.)"_

I've been doing this for on-call work, actually. It really helps to be able to
review what was seen, what was done, how long things took, &c.

For me, the purpose of a typescript is almost entirely unrelated to the
purpose of a history, though - history is things I reach for, more than things
I review.

