consent to monitoring banner for ssh

[Shawn Wells]

Well, you *could* do the "acceptance by logging in" thing... or you can 
force them to type [yes|no].  Here's how I accomplish that.


#Set the /etc/issue file to the login banner.  This one has no linefeeds,
#so it will wrap accordingly.
cat <<EOF >/etc/issue
YOUR WELCOME BANNER.
EOF

#This part creates the same login banner once your username and password 
has
#been entered.  This has linefeeds in it.
cat <<EOF >/etc/X11/gdm/PreSession/Default
#!/bin/sh
#
# Note that any setup should come before the sessreg command as
# that must be 'exec'ed for the pid to be correct (sessreg uses the parent
# pid)
#
# Note that output goes into the .xsession-errors file for easy debugging
#
PATH="/usr/bin/X11:/usr/X11R6/bin:/opt/X11R6/bin:$PATH:/bin:/usr/bin"

/usr/bin/gdialog --yesno "YOUR WELCOME BANNER"
if ( test 1 -eq \$? ); then
    gdialog --infobox "Logging out in 10 Seconds" 1 20 &
    sleep 10
    exit 1
fi

gdmwhich () {
    COMMAND="$1"
    OUTPUT=
    IFS=:
    for dir in $PATH
    do
        if test -x "$dir/$COMMAND" ; then
            if test "x$OUTPUT" = "x" ; then
                OUTPUT="$dir/$COMMAND"
            fi
        fi
    done
    unset IFS
    echo "$OUTPUT"
}

XSETROOT=\`gdmwhich xsetroot\`
if [ "x$XSETROOT" != "x" ] ; then
    # Try to snarf the BackgroundColor from the config file
    BACKCOLOR=`grep '^BackgroundColor' /etc/X11/gdm/gdm.conf | sed 
's/^.*=\(.*\)$/\1/'`
    if [ "x$BACKCOLOR" = "x" ]; then
        BACKCOLOR="#76848F"
    fi
    "$XSETROOT" -cursor_name left_ptr -solid "$BACKCOLOR"
fi

SESSREG=\`gdmwhich sessreg\`
if [ "x$SESSREG" != "x" ] ; then
    # some output for easy debugging
    echo "$0: Registering your session with wtmp and utmp"
    echo "$0: running: $SESSREG -a -w /var/log/wtmp -u /var/run/utmp -x 
\"$X_SERVERS\" -h \"$REMOTE_HOST\" -l \"$DISPLAY\" \"$USER\""

    exec "$SESSREG" -a -w /var/log/wtmp -u /var/run/utmp -x "$X_SERVERS" 
-h "$REMOTE_HOST" -l "$DISPLAY" "$USER"
    # this is not reached
fi
#Some output for easy debugging.
echo "$0: could not find the sessreg utility, cannot update wtmp and utmp"
exit 0
EOF

#/etc/ssh/sshd_config banner settings.
perl -npe 's/^#Banner \/some\/path/Banner \/etc\/issue/g' -i 
/etc/ssh/sshd_config


-- 
Shawn D. Wells
Solutions Architect, Federal Team
swells at redhat.com
C: 443-534-0130





mups.cp wrote:
> You're right, this give users an out. I forgot the ~/.ssh/rc check.
> Your approach to set the users' shell to a script seem better
>
>
> On Dec 4, 2007 8:17 PM, Carl G. Riches <cgr at u.washington.edu> wrote:
>   
>> 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 at 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 at u.washington.edu
>>>>
>>>>
>>>> --
>>>> redhat-list mailing list
>>>> unsubscribe mailto:redhat-list-request at redhat.com?subject=unsubscribe
>>>> https://www.redhat.com/mailman/listinfo/redhat-list
>>>>
>>>>         
>> --
>>
>> redhat-list mailing list
>> unsubscribe mailto:redhat-list-request at redhat.com?subject=unsubscribe
>> https://www.redhat.com/mailman/listinfo/redhat-list
>>
>>     
>
>