Logging of client commands, possible?

[Dan Kaminsky]

> I believe one can obfuscate one's tty session such that you might not
> really figure out what was done merely through a keystroke replay.

Ah, but if the only incoming channel of de-obfuscation code is itself
tapped, it's actually provably impossible to successfully obfuscate the
code.  The best case I can think of involves encrypting to a naturally
cycled file, uploading the encrypted code, decrypting against the file
already there, and letting the file itself expire...and even that has
problems (like it's pretty damn noisy *laughs*).

Believe me, I'm quite evil enough to determine breaks in the system, but
hell, it can't *hurt* to have TTY logs on production machines, especially if
they're sent off-host in realtime.

> > There might be some exceptions, but you just can't deny that it's
certainly
> > imaginable that it's more useful to see a TTY log than the output of
> > "/bin/sh -x" on an arbitrary shell script...that's kinda my feeling
about
> > the interactive logs.  If nothing else, it's a critical adjunct to
obtuse
> > SAR logs.
>
> I think a tty-log plus a history of exec*()s and open()s and creat()s
> and so on would be a rather complete record, yes. But ultimately a
> sufficiently nasty and savvy user can get 'round such logging (though the
> obfuscation necessary might itself raise enough red flags that you could
> catch such a user).

As I've been saying, often the "enemy" is lack of documentation and
accountability, not an active attacker.  Production machines need histories
of who did what when.  exec() is an incomplete and near-useless history --
would you rather have the output of ./configure or all the exec()'s that it
contained?

Different problems, thus my claim of orthogonality to the security -- but
NOT the functionality aspect of SSH.

--Dan