2

Imagine we have a shared ssh key/(username & password) between two users, We call them Bob and Alice.

Bob has connected to the server and has executed some chain of commands that led to the deletion of some critical data on that host.

Alice also connected to the same host, using the same shared credential just to run some updates.

Although we have the sshd auth logs (/var/log/auth.log) and know that both users were connected during the incident, is there a way to distinguish which user (connection, as they contain the user's IP) was responsible for the chain of actions?

Improve this question
3
  • 3
    One would usually have per-person ssh keys (and disable password logins). They may all be allowed to log into the same account. Then you can track by sshd logs. You can also easily manage access (e.g. disable the key of an employee who leaves the company without affecting others).
    – Ned64
    Sep 15, 2021 at 22:12
  • @Ned64 Although that is commonsense to that, I'm more looking into the possibility if someone failed to stick to the best practices. I'm more thinking in the forensics side of things. something has happened and that's all we have to work with.
    – A.R.H
    Sep 15, 2021 at 22:18
  • 3
    If people share keys then you can perhaps trace by their IP address, login time (last, wtmp) and "personal style", e.g. which commands they used (everyone has their own style), check the shell history (if not cleared or manipulated by a malicious actor) and file change times. If available you can check their host machines' (bash/shell) history with command times, file access of ssh key files etc.
    – Ned64
    Sep 15, 2021 at 22:20

1 Answer 1

Reset to default
2

This is why many companies have policies prohibiting human accounts from using ssh keys... they tend to share them and/or don't put passwords on them so that the keys themselves basically become passwords-in-a-file.

Smarter companies will use a security product to control which users are allowed to use ssh keys, where those keys can be used, and where the connections are allowed to begin and end.

You are permitting known insecure, unauditable behavior and trying to catch it after-the-fact. The best answer would be to stop the behavior outright.

The same security product that would help you control your ssh key use can also be used to do keystroke logging on the ssh session. That way, you could still capture unique log events, showing the source and destination of the connection and see every ugly keystroke the user typed... with the resulting output. This is a commercial solution, of course, but would definitely get you what you're looking for.

One hack-of-an-option would be to use unique shell history files on each login to the account. Basically you'd define HISTFILE to be something like this in the users .bashrc (or equivalent):

TIMEST=`date +%Y.%m.%d-%H%M%S`
SOURCETERM=` who am i | awk '{print $5}'`
HISTFILE=.sh_history-$TIMEST"_"$SOURCETERM

This results in a unique shell history file for each session, named something like:

$HOME/.sh_history-2021.09.16-022345_(1.2.3.4)

This might get you what you want, but if the users are wise, they could easily change or delete the file, or assign themselves a different history file.

You're trying to work around an almost impossible problem. From the systems' perspective, the same user is simply logged in twice. Commands, processes, memory, etc. are all owned by one UID and can be manipulated by anyone else with the same effective UID.

Again, the proper solution is to prevent the insecure behavior to start with.

Improve this answer
2
  • I really appreciate the answer, however, I'm not looking for a solution to the root of the problem, but the problem itself. Imagine an incident response team have a situation on hand like this and have to deal with it. The question is what artifacts each session creates that are traceable, maybe the PID of the said shells, etc.
    – A.R.H
    Sep 16, 2021 at 7:42
  • 1
    In your question, the premise is that two users are logged in under the same account. How could you tell which one was the culprit that deleted the critical data. If that is what you are looking for, the HISTFILE hack above would show you each command the user executed... provided they weren't wise enough to delete the file. The fact that each session has a unique file, would maintain an endless history of past activity that you could backup each night to research later if needed. Sorry if it's not helpful, but you're probably going need a commercial product to do what you want.
    – mikem
    Sep 16, 2021 at 7:46

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .