Live data from Hacker News

Bashhub – Bash History in the Cloud

bashhub.com

41–49 of 49 posts

Re: Bashhub – Bash History in the Cloud

#41
post #36
post #20

Earlier quoted context omitted.

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

> 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.

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.

Re: Bashhub – Bash History in the Cloud

#42
post #36
post #20

Earlier quoted context omitted.

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

> 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.

Syncthing

Re: Bashhub – Bash History in the Cloud

#43

Earlier quoted context omitted.

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.

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

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?

Re: Bashhub – Bash History in the Cloud

#44

Earlier quoted context omitted.

I can't see your comment about splitting history - this sounds like something I'd use, though.

https://news.ycombinator.com/item?id=10695029 is the comment, but it didn't contain much detail. Splitting history is done fundamentally by setting HISTFILE - nothing too surprising about that. But for my particular setup, I more broadly divide my shell use by context. I have a script called "session". `session $somename` looks for a screen (feel free to prefer tmux) session named $somename. If one exists, it attache…

This is offtopic, but do you have issues maintaining the right path to the SSH agent socket when switching between screen sessions? (tmux has the same issue)

Re: Bashhub – Bash History in the Cloud

#45

Earlier quoted context omitted.

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

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 y…

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.

Re: Bashhub – Bash History in the Cloud

#46

Earlier quoted context omitted.

https://news.ycombinator.com/item?id=10695029 is the comment, but it didn't contain much detail. Splitting history is done fundamentally by setting HISTFILE - nothing too surprising about that. But for my particular setup, I more broadly divide my shell use by context. I have a script called "session". `session $somename` looks for a screen (feel free to prefer tmux) session named $somename. If one exists, it attache…

This is offtopic, but do you have issues maintaining the right path to the SSH agent socket when switching between screen sessions? (tmux has the same issue)

Not really, but I know what you're experiencing.

The ssh agent forwarding info is stored in environment variables, which are then inherited by any other process spawned from your initial connection, so everything that cares knows the agent pid and where to find the agent socket.

The problem is that, with screen and tmux, the content of those environment variables outlasts their accuracy.

The solution needs to take the form of updating those environment variables. It looks like there's a .ssh_agent file that can be sourced to update it, though I'm not finding - at a skim of the docs - what creates that and when. It does only seem to contain info for a single socket, so assuming it's populated on login there's still a possibility of that data being stale:

    connection 1 login
    connection 1 writes info to file
    connection 2 login
    connection 2 writes info to file
    connection 2 logout
leaves the info wrong if you try to use it from connection 1.

Better would be to store all active agent sessions. We can implement that as follows:

in .bash_profile:

    if [ "$SSH_AUTH_SOCK" -a "$SSH_AGENT_PID" ]; then
        exec {SSH_AGENT_INFOS_FD}>>~/.ssh_agent_infos
        if flock $SSH_AGENT_INFOS_FD; then
            sed -i "1i$SSH_AGENT_PID $SSH_AUTH_SOCK" ~/.ssh_agent_infos
        fi
        exec {SSH_AGENT_INFOS_FD}>&-
    fi
This creates the file if it doesn't exist, locks it, and prepends the current session's info. It goes in .bash_profile, not .bashrc, so that it is only executed for login shells.

in .bash_logout:

    if [ "$SSH_AUTH_SOCK" -a "$SSH_AGENT_PID" ]; then
        flock .ssh_agent_infos sed -i "/^$SSH_AGENT_PID /d" .ssh_agent_infos
    fi
This locks the file and strips out lines with a matching PID. .bash_logout is sourced on exit from a login shell.

in .bashrc, set BASH_PROMPT so that it includes the following (personally, my BASH_PROMPT is set to source ~/.bash_prompt):

    exec {SSH_AGENT_INFOS_FD}>>~/.ssh_agent_infos
    if flock -w 1 -s $SSH_AGENT_INFOS_FD; then
        read -u $SSH_AGENT_INFOS_FD SSH_AGENT_PID SSH_AUTH_SOCK
    fi
    exec {SSH_AGENT_INFOS_FD}>&-
This will run every time a new prompt is generated (so, right after running the previous command, if any). It locks the file, and then reads the first line out of it to populate SSH_AGENT_ID and SSH_AUTH_SOCK. So if a shell has old values in those variables, you should just need to hit enter to repopulate them.

Note that the above assumes that, if you're logging in from multiple devices, your agents are interchangeable. If you need to keep them separate, then adjust the above to either tag the lines in .ssh_agent_infos or use multiple files.

Re: Bashhub – Bash History in the Cloud

#48

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

"I don't even store my shell history on private computers." Any particular reason for that? It seems devastating to usability, for unclear benefit...

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.

Post reply on HN