Re: More detailed information about last commands executed than lastcomm

2013-09-16 Thread Johan Mellberg
16 sep 2013 kl. 11:38 skrev Wiesław Kielas wieslaw.kie...@bluemedia.pl:

 Dear misc@,
 
 Is there any way to get information about last commands executed on a
 OpenBSD machine? I'm interested in getting the command name along with
 arguments passed to it.
 
 From what I gathered so far, lastcomm can't show command arguments - is
 there any way/other tool which can do that?

history 

Might do the trick? But maybe you want  a system-wide audit log / recording? 
There are (super-expensive) things like Cyber-Ark that does ssh session 
recording, maybe it could be made to work with local log-in as well. 

 
 -- 
 regards, 
 
 Wiesław Kielas



Re: More detailed information about last commands executed than lastcomm

2013-09-16 Thread Jérémie Courrèges-Anglas
Wiesław Kielas wieslaw.kie...@bluemedia.pl writes:

 Dear misc@,

 Is there any way to get information about last commands executed on a
 OpenBSD machine? I'm interested in getting the command name along with
 arguments passed to it.

 From what I gathered so far, lastcomm can't show command arguments - is
 there any way/other tool which can do that?

Seems like there's nothing in sys/acct.h for storing cli args.

-- 
jca | PGP: 0x06A11494 / 61DB D9A0 00A4 67CF 2A90  8961 6191 8FBF 06A1 1494



Re: More detailed information about last commands executed than lastcomm

2013-09-16 Thread Nick Holland
On 09/16/13 05:37, Wiesław Kielas wrote:
 Dear misc@,
 
 Is there any way to get information about last commands executed on a
 OpenBSD machine? I'm interested in getting the command name along with
 arguments passed to it.
 
From what I gathered so far, lastcomm can't show command arguments - is
 there any way/other tool which can do that?
 

how about man ksh, then search for HISTFILE ?  Is that what you are after?
This is not on by default.  For a very reasons.

Nick.



Re: More detailed information about last commands executed than lastcomm

2013-09-16 Thread Jiri B
On Mon, Sep 16, 2013 at 11:38:18AM +0200, Wies�?aw Kielas wrote:
 Dear misc@,
 
 Is there any way to get information about last commands executed on a
 OpenBSD machine? I'm interested in getting the command name along with
 arguments passed to it.
 
 From what I gathered so far, lastcomm can't show command arguments - is
 there any way/other tool which can do that?

Usual unix process accounting does not take care about commands' args.
Anyway, you probably won't care about what normal users execute, you
probably want that only for admins/root. Then I would propose to build
a server with conserve (console server) which would be used as source
host to ssh/console to destination servers for admins/root. conserve
can save sessions in text form, you could have a filter and send it via
syslog/whatever to central logging server.

j.



Re: More detailed information about last commands executed than lastcomm

2013-09-16 Thread Bret Lambert
On Mon, Sep 16, 2013 at 07:28:21AM -0400, Jiri B wrote:
 On Mon, Sep 16, 2013 at 11:38:18AM +0200, Wies??aw Kielas wrote:
  Dear misc@,
  
  Is there any way to get information about last commands executed on a
  OpenBSD machine? I'm interested in getting the command name along with
  arguments passed to it.
  
  From what I gathered so far, lastcomm can't show command arguments - is
  there any way/other tool which can do that?
 
 Usual unix process accounting does not take care about commands' args.
 Anyway, you probably won't care about what normal users execute, you
 probably want that only for admins/root. Then I would propose to build
 a server with conserve (console server) which would be used as source
 host to ssh/console to destination servers for admins/root. conserve
 can save sessions in text form, you could have a filter and send it via
 syslog/whatever to central logging server.
 
 j.
 

Why make shit more difficult than it need be? From the sudo man page:

sudo also supports logging a command's input and output streams.



Re: More detailed information about last commands executed than lastcomm

2013-09-16 Thread Bret Lambert
On Mon, Sep 16, 2013 at 01:31:58PM +0200, Bret Lambert wrote:
 On Mon, Sep 16, 2013 at 07:28:21AM -0400, Jiri B wrote:
  On Mon, Sep 16, 2013 at 11:38:18AM +0200, Wies??aw Kielas wrote:
   Dear misc@,
   
   Is there any way to get information about last commands executed on a
   OpenBSD machine? I'm interested in getting the command name along with
   arguments passed to it.
   
   From what I gathered so far, lastcomm can't show command arguments - is
   there any way/other tool which can do that?
  
  Usual unix process accounting does not take care about commands' args.
  Anyway, you probably won't care about what normal users execute, you
  probably want that only for admins/root. Then I would propose to build
  a server with conserve (console server) which would be used as source
  host to ssh/console to destination servers for admins/root. conserve
  can save sessions in text form, you could have a filter and send it via
  syslog/whatever to central logging server.
  
  j.
  
 
 Why make shit more difficult than it need be? From the sudo man page:
 
 sudo also supports logging a command's input and output streams.

Er, I meant to copy

 sudo can log both successful and unsuccessful attempts

I blame the lack of something in my something system.



Re: More detailed information about last commands executed than lastcomm

2013-09-16 Thread Jiri B
On Mon, Sep 16, 2013 at 01:33:33PM +0200, Bret Lambert wrote:
 On Mon, Sep 16, 2013 at 01:31:58PM +0200, Bret Lambert wrote:
  On Mon, Sep 16, 2013 at 07:28:21AM -0400, Jiri B wrote:
   Usual unix process accounting does not take care about commands' args.
   Anyway, you probably won't care about what normal users execute, you
   probably want that only for admins/root. Then I would propose to build
   a server with conserve (console server) which would be used as source
   host to ssh/console to destination servers for admins/root. conserve
   can save sessions in text form, you could have a filter and send it via
   syslog/whatever to central logging server.

  Why make shit more difficult than it need be? From the sudo man page:
  
  sudo also supports logging a command's input and output streams.
 
 Er, I meant to copy
 
  sudo can log both successful and unsuccessful attempts
 
 I blame the lack of something in my something system.

Yes it would be better to use sudo but some env are setup to allow direct
login to root :/

j.



Re: More detailed information about last commands executed than lastcomm

2013-09-16 Thread Bret Lambert
On Mon, Sep 16, 2013 at 07:48:14AM -0400, Jiri B wrote:
 On Mon, Sep 16, 2013 at 01:33:33PM +0200, Bret Lambert wrote:
  On Mon, Sep 16, 2013 at 01:31:58PM +0200, Bret Lambert wrote:
   On Mon, Sep 16, 2013 at 07:28:21AM -0400, Jiri B wrote:
Usual unix process accounting does not take care about commands' args.
Anyway, you probably won't care about what normal users execute, you
probably want that only for admins/root. Then I would propose to build
a server with conserve (console server) which would be used as source
host to ssh/console to destination servers for admins/root. conserve
can save sessions in text form, you could have a filter and send it via
syslog/whatever to central logging server.
 
   Why make shit more difficult than it need be? From the sudo man page:
   
   sudo also supports logging a command's input and output streams.
  
  Er, I meant to copy
  
   sudo can log both successful and unsuccessful attempts
  
  I blame the lack of something in my something system.
 
 Yes it would be better to use sudo but some env are setup to allow direct
 login to root :/

And the fact that they can do this via sudo should serve as an impetus
for those admins to stop Doing it Wrong(tm).

I understand that there are exceptions to the best practices dictate
root-level access through sudo, but the original email that started
this thread seems to indicate that there's a need to keep tabs on some
henchmen/underlings/poorly-trained monkies. That screams don't give
them direct root logins, to me.



Re: More detailed information about last commands executed than lastcomm

2013-09-16 Thread Wieslaw Kielas
* Bret Lambert bret.lamb...@gmail.com [16.09.2013. @13:57:46 +0200]:
 On Mon, Sep 16, 2013 at 07:48:14AM -0400, Jiri B wrote:
  On Mon, Sep 16, 2013 at 01:33:33PM +0200, Bret Lambert wrote:
   On Mon, Sep 16, 2013 at 01:31:58PM +0200, Bret Lambert wrote:
On Mon, Sep 16, 2013 at 07:28:21AM -0400, Jiri B wrote:
 Usual unix process accounting does not take care about commands' args.
 Anyway, you probably won't care about what normal users execute, you
 probably want that only for admins/root. Then I would propose to build
 a server with conserve (console server) which would be used as source
 host to ssh/console to destination servers for admins/root. conserve
 can save sessions in text form, you could have a filter and send it 
 via
 syslog/whatever to central logging server.
  
Why make shit more difficult than it need be? From the sudo man page:

sudo also supports logging a command's input and output streams.
   
   Er, I meant to copy
   
sudo can log both successful and unsuccessful attempts
   
   I blame the lack of something in my something system.
  
  Yes it would be better to use sudo but some env are setup to allow direct
  login to root :/
 
 And the fact that they can do this via sudo should serve as an impetus
 for those admins to stop Doing it Wrong(tm).
 
 I understand that there are exceptions to the best practices dictate
 root-level access through sudo, but the original email that started
 this thread seems to indicate that there's a need to keep tabs on some
 henchmen/underlings/poorly-trained monkies. That screams don't give
 them direct root logins, to me.

Yes, I was looking for a way to keep track of commands run by different
users on the machine, and I was aware that various shells have a
HISTFILE. Sorry for not clarifying my intentions in my original post ;-)

I will probably turn sudo command logging and turn off root logins,
since it seems the most straightforward solution.

Thanks for all the replies ;-)

-- 
regards, 

Wiesław Kielas