[tinco]

Excellent. I've been thinking about having a SSHD keylogger post to slack (or some other log). It's crazy that sshd doesn't have this functionality built-in. It's so important to know what your admins are executing on your machines. Aside from the fact that they might have been compromised, it's just good to know what sort of general administration is being done.

[jmiserez]

If you don't want to install a "real" solution like Snoopy Logger that works for all users/shells/edge cases, you could always adapt the bash prompt to write the command out. E.g. I personally use something like this in my .bashrc which logs everything per user, but you could easily adapt this to post to Slack instead:

    # Adapted from https://unix.stackexchange.com/questions/207813/how-to-log-every-command-typed-into-bash-and-every-file-operation
    export ETERNAL_AUDIT_LOGFILE=~/.bash_eternal_auditlog
    PROMPT_COMMAND='RET_VAL=$?; history -a; echo "$(who am i | sed -e "s/[[:space:]]\+/ /g") [$$]: $(history 1 | sed "s/^[ ]*[0-9]\+[ ]*//" ) [$RET_VAL]" >> $ETERNAL_AUDIT_LOGFILE'

Output including return code and all parameters:

    ubuntu pts/0 2016-01-22 13:24 (example-loggedinuser-rdns.yourisp.com) [4379]: [2016-01-22 13:25:37] ps aux | grep python [0]

If you assume no malicious users this will work just fine.

[tinco]

I've looked into both Snoopy and a bash script as you said. They both have merits, but I think for it to be really reliable there's no better way than to just log keyboard input. Assuming there are malicious users for me is a big part of the motivation.

[justinhj]

That's some very sensitive information to put in Slack. If Slack has a security breach or if any of your slack accounts are hacked then an outside party could see this channel.

Ever accidentally typed your sudo password at the wrong prompt?

[ultramancool]

People are _way_ too trusting of Slack and similar services.

You could run your own IRC or Mattermost server accessible only in your LAN or over VPN and this would be fairly safe. Heck, even SSL-only with cranked up SSL options would be fairly safe.

Instead, people ship all their data off to a 3rd party company, often letting that 3rd party have control over their servers and such. Their customer data, their payment data, even code exec on all their servers is exposed and out of their control.

It's insanity, I can't believe people have so little regard for security. Especially with a 3rd party company with a less-than-great security record.

[xena]

People will always feel comfortable trading privacy for convenience!

[15155]

And liberty for the feeling of safety.

[ultramancool]

Very unfortunate but I feel it may be true.

[dthakur]

How quickly we forget that Slack was hacked not more than a year ago.

[hoorayimhelping]

How can we forget that? Literally any time Slack is mentioned on HN, people come out of the woodwork to let everyone know they don't use it cause it's hosted by someone else.

[noja]

> It's so important to know what your admins are executing on your machines...

Micromanagement at its finest!

> it's just good to know what sort of general administration is being done.

Your change management process will give you an overview of what your admins are doing.

[tinco]

Eh, the sysadmins would be monitoring eachother. I'm not saying they should have a manager that keeps their commands in check.

And yes a change management process is very nice and all, and I suppose that at Amazon no line is entered into a root sshd shell without each character being vetted thrice, but at your regular shop you can bet that there's loads of admins that type "ps aux" three times before getting it right. Not that that's terrible, but if you want to look at system administration as an engineering problem you have to know what's going on.

[_yy]

Incident response. When one of your admin accounts is compromised, you'd want to know what the attacker executed.

[ultramancool]

Yes you would - but why just SSH? Wouldn't auditd execve syscall logs sent to a logstash server be better? It'd handle compromises other than SSH too.

[_yy]

Yes - though there's more to a SSH session than executing commands (interacting with interactive editors, port forwarding, etc.)

[Diederich]

Could be used for micromanagement. But its required in some environments by some common regulations.

[e28eta]

There's a github talk about using Hubot to do sysadmin. One of the advantages of having everything happening in a public forum is teaching.

[teekert]

I use LogWatch, gives me daily emails with nice summaries of that happened on my Ubuntu Droplet: https://www.digitalocean.com/community/tutorials/how-to-inst...

[pquerna]

(disclaimer, I'm a co-founder of ScaleFT)

If you are interested in a commercial solution in this space, check out ScaleFT. Besides the dynamic SSH certificates, we also track both SSH keys used and access events, which you can then pull via an API across all your machines. We also have a Slack notifier, though It needs a little love & cleanup.

We're currently in what I could best call a beta: https://www.scaleft.com/

[rogeryu]

What about logwatch? That can do the same and a lot more. You can set it to mail you daily, which gives you an overview who logged in and how often. With a weekly mail you don't get these details, but it might be good enough.

[MrSec]

Look into auditd for logging execve() syscall instead. OSSEC can (directly) report or act on any thing reported through logs.

[rmdoss]

And send it to Slack now as well:

https://blog.sucuri.net/2016/01/server-security-integrating-...

[jrcii]

Some shells do have this built in, for example bash's history file, typically set to ~/.bash_history

[jlgaddis]

Which is easily defeated, of course ...

[jrcii]

Some file systems support append-only permissions, although I've never used them. I wonder if that would work with bash's history file?

[detaro]

No, since you can just turn it off or prepend all your commands with a space to hide them.

[jrcii]

You can remove ignorespace from HISTCONTROL for the latter, and for the former, can't you just remove chattr's execute permission for that user?

[jlgaddis]

The user can point $HISTFILE elsewhere (e.g., /dev/null), `unset` it, use another shell, ...

[inanutshellus]

Surprised at how many people didn't read parent's post as satire...

[Estragon]

The author didn't walk it back when challenged.

[SixSigma]

man syslog