OpenSolaris

****************************
Customer would like to file an RFE to change the following behavior
in ssh 
"Wants banner enabled for first time users but does not
want the banner displayed when issuing commands by their trusted users" example ssh <host> ls

Problem detail:

They recently had a security audit and are in the process of moving over from rsh to ssh
as a result of the audit findings.
They have one problem getting in the way.
They do all their admin work via rsh and issue what ever command they're going to use
in the same string as the initial login and would like to do the same with ssh.
rsh allows this without seeing a banner page...ssh displays the banner.

They enabled the banner in  sshd_config with an authentication message
that they want first time users to see.
They have also enabled logging in without a password for their trusted users.
Here's where their issue lies.
They want these trusted users to be able to issue commands without seeing the banner .
for example ssh <host> date .

Consulted with Senior Security engineer " sshd(1m) does not support sending a banner "first time only".
 This isn't actually possible to configure on the server.  The reason being that the banner is sent BEFORE the authentcation. This is the required behaviour of the IETF SSH protocol: see 3.1.5 Banner Message in draft-ietf-secsh-userauth-18.txt
It is an RFE and it won't be changed in Solaris 9."
Customer has chosen to file an rfe this seems to have a lot of impact to 
his daily administrators.
His best description of what he's looking for  is to mimic the behavior of rsh

The banner is displayed by the ssh(1) client on stderr not stdout.  So you could redirect the clients stderr to /dev/null.  However by default the local and remote stderr would be lost.  This can be worked around a little like this:

$ ssh braveheart "/home/darrenm/src/hello-stderr 2>&1" 2> /dev/null
Hello, World!

Where hellos-stderr is the normal hello world program but instead of writting to stdout it writes to stderr.

Note that this will still cause you to loose all stderr output from the ssh(1) client which might be a bad idea. 

N/A