On 2012/12/17 10:42, Jiri B wrote:
> On Mon, Dec 17, 2012 at 02:03:03PM +, Stuart Henderson wrote:
> > Wouldn't it be better to use an ssh forced command, which then looks
> > up the users desired shell (or other command called directly from ssh)
> > and wraps it in a logger?
>
> ForceCommand
On Mon, Dec 17, 2012 at 02:03:03PM +, Stuart Henderson wrote:
> Wouldn't it be better to use an ssh forced command, which then looks
> up the users desired shell (or other command called directly from ssh)
> and wraps it in a logger?
ForceCommand runs under destination user permissions so if y
On 2012-12-16, David Coppa wrote:
>> .profile can be interrupted with ctrl+c.
>
Because it is under controle or the user and he/she can disable
such funcionality.
>
> the safer way imho is patching ksh
Wouldn't it be better to use an ssh forced command, which then looks
up the users des
On Sun, Dec 16, 2012 at 8:07 AM, Alexander Hall wrote:
>
> I still want to know the reason for all this. If it's for security, it sure
> feels ass-backwards and questionable at best.
>
it's useful for honeypot scenarios, with all proposed solutions so far
being influenced by either lazyness or d
Andres Perera wrote:
>On Sun, Dec 16, 2012 at 7:10 AM, Paul de Weerd
>wrote:
>> On Sun, Dec 16, 2012 at 06:38:08AM -0430, Andres Perera wrote:
>> | On Sun, Dec 16, 2012 at 5:47 AM, Paul de Weerd
>wrote:
>> | > On Sun, Dec 16, 2012 at 11:02:31AM +0100, David Coppa wrote:
>> | > | > .profile can
On Sun, Dec 16, 2012 at 7:10 AM, Paul de Weerd wrote:
> On Sun, Dec 16, 2012 at 06:38:08AM -0430, Andres Perera wrote:
> | On Sun, Dec 16, 2012 at 5:47 AM, Paul de Weerd wrote:
> | > On Sun, Dec 16, 2012 at 11:02:31AM +0100, David Coppa wrote:
> | > | > .profile can be interrupted with ctrl+c.
>
On Sun, Dec 16, 2012 at 06:38:08AM -0430, Andres Perera wrote:
| On Sun, Dec 16, 2012 at 5:47 AM, Paul de Weerd wrote:
| > On Sun, Dec 16, 2012 at 11:02:31AM +0100, David Coppa wrote:
| > | > .profile can be interrupted with ctrl+c.
| > |
| > | >>> Because it is under controle or the user and he/s
btw, this program should be the only entry in /etc/shells so only root
is allowed privacy
On Sun, Dec 16, 2012 at 6:38 AM, Andres Perera wrote:
>
> #include
> #include
> #include
> #define sp "/usr/bin/script"
> #define sf "/var/db/ghetto_act/%ju"
>
> main()
> {
> char *so;
> if (asprintf(
On Sun, Dec 16, 2012 at 5:47 AM, Paul de Weerd wrote:
> On Sun, Dec 16, 2012 at 11:02:31AM +0100, David Coppa wrote:
> | > .profile can be interrupted with ctrl+c.
> |
> | >>> Because it is under controle or the user and he/she can disable
> | >>> such funcionality.
> |
> | the safer way imho is p
My guess, compliance to some standard
Den 16 dec 2012 11:17 skrev "Paul de Weerd" :
> On Sun, Dec 16, 2012 at 11:02:31AM +0100, David Coppa wrote:
> | > .profile can be interrupted with ctrl+c.
> |
> | >>> Because it is under controle or the user and he/she can disable
> | >>> such funcionality.
>
On Sun, Dec 16, 2012 at 11:02:31AM +0100, David Coppa wrote:
| > .profile can be interrupted with ctrl+c.
|
| >>> Because it is under controle or the user and he/she can disable
| >>> such funcionality.
|
| the safer way imho is patching ksh
After that, expect all your users to suddenly switch t
> .profile can be interrupted with ctrl+c.
>>> Because it is under controle or the user and he/she can disable
>>> such funcionality.
the safer way imho is patching ksh
Maximo Pech wrote:
>I have found another possible solution, you can use script(1), calling
>it
>from the .profile of the user, with a line like this at the end of such
>file:
>
>exec script
>
>Then you change the permissions of the .profile so that the user cannot
>change it. You could also set t
I have found another possible solution, you can use script(1), calling it
from the .profile of the user, with a line like this at the end of such
file:
exec script
Then you change the permissions of the .profile so that the user cannot
change it. You could also set the output file for script(1) t
And why not tweak it to disable the ability to disable the log
functionality?
2012/12/15 Jiri B
> On Fri, Dec 14, 2012 at 10:11:20PM -0600, Maximo Pech wrote:
> > Why not use something like gnu screen or tmux (if it offers the log
> session
> > funcionality)?
>
> Because it is under controle or
On Fri, Dec 14, 2012 at 01:50:49PM +0100, Dustin Fechner wrote:
> On 12/14/2012 12:20 PM, Lorenzo Crapovich wrote:
> > Hi folks.I'm looking for a clean solution, to log through syslog
> > every single shell command that a user make.
>
> Why not log to /var/account/acct?
> See accton(8) and sa(8).
On 12/14/2012 12:20 PM, Lorenzo Crapovich wrote:
> Hi folks.I'm looking for a clean solution, to log through syslog
> every single shell command that a user make.
Why not log to /var/account/acct?
See accton(8) and sa(8).
On Fri, Dec 14, 2012 at 11:20:09AM +, Lorenzo Crapovich wrote:
> Hi folks.I'm looking for a clean solution, to log through syslog every single
> shell command that a user make.I've found many wrapper scripts, or stuff like
> 'sudosh, snoopy logger', but actually, it sounds pretty dirty imho.
>
Hi folks.I'm looking for a clean solution, to log through syslog every single
shell command that a user make.I've found many wrapper scripts, or stuff like
'sudosh, snoopy logger', but actually, it sounds pretty dirty imho.
What solution guys could you suggest me ?
Greetings.
Lorenzo
19 matches
Mail list logo
