Hi,
interception of data is technically possible but I doubt you will find
what you are looking for. In ssh there can be many command streams when
you tunnel a connection from one server to another for example.
It would be much more suitable to audit any changes on the server side
within the user environment. Suitably configured login/logout scripts can
capture the command history of your chosen shell environment for example.
Suitably configured restricted shells can offer restricted access to
executables based on role. Or you can use products such as grsecurity (
www.grsecurity.org) which appears to allow audit logging to be configured to
user groups. Often, I use 'screen' myself to record an installation into
a
logfile for further reference. In a much more draconian move you can force
access through a key logging server as the only portal for making changes to
the system.
Do not fall into the temptation of 'fixing' ssh which was designed for
security, networking and connectivity. This are quite opposite principles
from the full audit and micro audit of the business model you are seeking.
In general I consider the overall premise to audit log all changes
unfeasible. What about the changes to the configuration file that were done
6/12/18 months ago and now that the server gets restarted kicking in and
preventing you from starting some service. How will you be able to find the
exact change ? Or when looking at post mortem audit against a system in a
state that not known it becomes very tricky to track back the actual
changes. Consider someone change the /etc/group file using an interactive
command (e.g. vi /etc/group <nl> 10Gcw5 <esc> u :q!) then you have a
very
difficult time to identify what exactly was changed. Consider someone
running a script against your server; how would you know that it is your
approved script and not something they typed in manually.
In my years of system administration the best tool to identify what
happened was to talk to the person logged in at the time. Everything else
must be covered by training, backup, redundancy in systems, more training,
application self logging and access control to permit only the right sort of
people.
Hope this helps.
On Sat, Feb 6, 2010 at 4:42 AM, Lokesh Gupta <lgupta1 at hotmail.com>
wrote:
>
> Hi!!
>
>
>
> We are looking to implement a solution where in the background we want to
> capture all the commands typed by a user.
>
>
>
> One of the ways we are thinking of achieving this is to make some changes
> at an appropriate place in the ssh client's program flow. Given the ssh
> client eventually sends the command typed by the user to the sshd, I am
sure
> somewhere within ssh program there is a place where the "string"
typed by
> the user is present.
>
>
>
> Can someone please tell?
>
>
>
> (i) If there already is a string that carries the command that has been
> typed by the user? If so, do you know where it is? Which file we should be
> looking at in the ssh codebase?
>
>
>
> (ii) Is this feature already implemented by someone? If so, we can perhaps
> just leverage that rather than doing any additional coding for this?
>
>
>
> Business Reasons for why this is required
>
> -----
>
> Typically in a large puclic enterprise, you want to make sure that there is
> controlled access to your production environments. In addition, you also
> want to make sure that you have some sort of audit trail in place when a
> person has logged in to the production environment and know what commands
> s/he has typed - this one one side acts as a deterrent to someone who is
not
> being a good corporate citizen, and at the same time also helps analyze
what
> did we do wrong when say doing a post-mortem of a production issue for
which
> someone had to login to a prod box and do some fixes.
>
>
>
> Any help with this will be greatly appreciated.
>
>
>
> Regards
>
>
>
> Lokesh
>
> _________________________________________________________________
> Hotmail: Powerful Free email with security by Microsoft.
> http://clk.atdmt.com/GBL/go/201469230/direct/01/
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>