[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: consent to monitoring banner for ssh



On Tue, 4 Dec 2007, mups.cp wrote:

Carl,

You don't need set the everyone's login shell, you could use
/etc/ssh/sshrc and put your code or your a call to it in it.

Is /etc/ssh/sshrc run in the case where a user has a private ~/.ssh/rc file? The information here:

  http://www.oreilly.com/catalog/sshtdg/chapter/ch08.html

states that it is not.  Also, the sshd(8) man page says:

  If ~/.ssh/rc exists, runs it; else if /etc/ssh/sshrc exists,
  runs it; otherwise runs xauth.  The "rc" files are given the
  X11 authentication protocol and cookie in standard input.

This gives the user an out.

Carl



On Dec 4, 2007 7:41 PM, Carl G. Riches <cgr u washington edu> wrote:
On Tue, 4 Dec 2007, Bill Tangren wrote:

A new policy has been implemented here at work. The old policy stated
that, when someone logs in to a system via ssh, I had to display a consent
to monitor banner, which is easy to implement.

The new policy, however, requires that the user has to somehow signify
that they have read and will abide by the policy. In essence, I have to
get a yes or no input from the user, possibly just after they log on, and
if they say no, log them off. If they say yes, they get to proceed.

My question: what is the best way to implement this? I have to make sure
the user cannot remove this functionality for future logins, so I can't
put it in any of their login scripts. This is easy to implement for GUI
logins, but I don't know the best way to proceed for ssh. Any ideas?


We did a somewhat-similar task at a place where I used to work.  We set
everyone's login shell to a locally-written perl script.  That perl script
did things such as ensure that the user had permission to log in to the
system, check the user's quota, print out a blurb, then exec( )'d tcsh.
It needed some interupt handling, though, to fit what you want to do.  I
don't have the code anymore, but this might give you an idea of what
direction to go.  (Would you need to record user's answers to your
question in a database for future reference?  This might give you that
ability.)

HTH,
Carl

--
Carl G. Riches
Software Engineer
Department of Biostatistics
Box 357232                      voice:     206-616-2725
University of Washington        fax:       206-543-3286
Seattle, WA  98195-7232         internet:  cgr u washington edu


--
redhat-list mailing list
unsubscribe mailto:redhat-list-request redhat com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]