Logging of client commands, possible?

[Dan Kaminsky]

> Yes, you are right.
>
> And because SSH does not care about what's going on inside it does
> not snoop ttys.  On Unix, tools should do _one_ thing and do it well, not
> 1000 things is a very mediocre way.

Markus,

    If I wanted one tool to do one thing, I'd use Telnet over SSL. :-)
OpenSSH is *all* about the integration of generic encapsulators into a
common tool.  In this case, we'd be integrating a cross platform method to
encapsulate TTY logging methods, as an alternative to painful, non-portable
solutions.

    OpenSSH is already providing TTY services; logging functionality is all
over the place in TTY tools(script, most GUI telnet clients, etc.)  This
ain't a big jump; in fact I'd be surprised if it's more than a few dozen
lines of code to diff in.

    A *really* nice aspect of friendly TTY logs(we'll leave attacker-logs to
the SAR reports, though I doubt there's any disagreement that TTY logs would
supplement SAR's by helping filter out innocent traffic) is that they'd
automatically drop whatever didn't show up on the TTY, i.e. typed passwords.
That would make captured logs an order of magnitude less security
sensitive -- big win.

    I *very* much see the wisdom in your nervousness.  Spyware is certainly
not something SSH should be.  But spyware sends your data to someone else --
security monitoring retains your own data for your own future analysis.

    This isn't a small distinction.  Every DRM system in existance is based
on the concept that your computer should do something for someone else
instead of you.  Every firewall in existance is based on the concept that
your network should behave how you wish it to, no matter what anyone else
wants.  The latter is compatible with base concepts of property(that which
is mine ought not betray me); the former violates those concepts with
abandon.

    I posit that the administrator of an SSH daemon is presumed to have the
right to view all data that passes over it.  They're administering the
cryptographic keys, it's their property(or they've been granted legitimate
access to control it), and possibly their job if somebody breaks something.
Obfuscating access to that data because we think other people might not want
their limited contribution to be abused in some arbitrary way -- sound
familiar?  That's just another DRM applying security through obscurity, and
I think we can both agree that StO ain't the philosophy of OpenSSH.

    A compelling argument against integrating this form of logging is that
it's more likely to be hacked onto a server than it is legitimately
deployed.  My response would be that hackers have more interesting tools to
play with, and the fact that I've had to point administrators at hacker
tools is a bit embarassing.  It'd be like if VNC didn't exist and entire
networks were managed with BackOrifice :-)

    A more compelling argument is that administrators don't necessarily have
the right to monitor their own servers.  Certainly, it'd be unethical to
monitor the desktop of an employee -- as a couple federal judges have
started to note.  But production machines are usually systems with very
stringent rules about who should be changing what and what kind of backoff
plans need to be in place first; certainly there's a legitimate place for
this kind of monitoring and I'm not sure it's fair to make the policy
statement that the illegitimate abuses override all possible legitimate
uses.

    Thoughts?  I definitely see your perspectives on this...perhaps we can
limit abuses by making this a compile time option?  Mind you, I *hate*
compile time options, but we could at least throw up a banner referencing
ECPA1986 if it was enabled.

--Dan