Re: Switching audit files under Solaris 8 via cron

From: Warren Belfer (
Date: 05/01/02

Date: Wed, 1 May 2002 09:35:20 -0700 (PDT)
From: Warren Belfer <>

For some reason, I did not see the beginning of this thread, but
based on what I see here:

I believe that you make this work by changing the sshd_config line from

UseLogin No
UseLogin Yes

and restart the ssh deamon(s). [it will kill all current ssh
sessions, even if you only HUP it, and I have found that you need
to actually restart it anyhow.]

I am assuming that you are using something that allows this
change. If not, you are really in trouble, because BSM won't
track users actions unless /bin/login has been used to log them

This configuration should work fine. I have lots of systems
where this is all working. BSM works, you can run crontab over
ssh and life is grand - but you must use (an sshd that allows you
to use) /bin/login

The problem is that if you use the login capabilities built into
the ssh daemon, it does not understand auditing and therefore
does not set up the audit credentials properly (or at all). This
messes up the file in /var/spool/cron/crontabs. Then
when cron tries to run, it doesn't get the correct audit info and
quits. BY setting UseLogin to "Yes", you use the login facility
of /bin/login which does set up the auditing credentials
correctly. [This is also the reason BSM won't give you
meaningful results unless you use /bin/login]

Hope this Helps,


>On Tue, Nov 13, 2001 at 02:50:26PM -0800, Darren Moffat wrote:
>["cron audit problem" errors]
>> >The solutions: edit crontab files via console only, and/or switch to
>> >OpenSSH using either PAM or /bin/login. Both of the latter will produce
>> >a properly validated session, allowing crontab editing.
>> You only get the audit system setup properly when using /bin/login PAM
>> plays no part in BSM setup.
>Having run into similar problems myself, I'm trying to find a solution that
>does allow me to edit crontab files over ssh links.
>As I understand it from the various discussions of the problem produced
>upon a google search, getting rid of the auditing should cure it. I've
>disabled BSM (bsmunconv), ensured that the audit init script is not being
>run at bootup, and rebooted. Yet I'm still getting the same errors after
>editing root's crontab file over ssh links. For various reasons switching
>from SSH to openssh isn't really an option, and any unencrypted
>remote access methods are definitely out :-)
>No doubt I've missed something trivial, but any advice would be much
>--------------- Robin Stevens <> -----------------
>Oxford University Computing Services ----------- Web:
>------- (+44)(0)1865: 273212 (work) 273275 (fax) Mobile: 07776 235326 -------