RE: Logging enhancement

I think you read way to deep.
I'm not talking about every keystroke.
I'm talking basic syslog connection monitoring here.

There sure doesn't seem to be a problem with sshd logging connection
info!
There sure doesn't seem to be a problem populating client environment
variables with connection info!
SSH_CLIENT='10.10.10.100 2926 22'
SSH_CONNECTION='10.10.10.100 2926 10.20.20.100 22'

I'm just asking why ssh can't do a basic sylog entry on a user like
"su".
Maybe a ssh_config option that provides it for any ssh aware client
(sftp, scp, etc). Keeps it out of O/S specific features like BSM, etc.
And yes, your right, anyone can compile and run anything on any port.
(including the sshd daemon).
I'm just talking about the probable 99% of users that use ssh
out-of-the-box.
The ssh client is always the starting point for most uses I'm aware of.

There are plenty of log analysis packages and correlation tools (sec.pl)
that could take advantage of it. I guess I do not understand the
reluctance, especially considering the nature of the product.

BASIC PREMISE

userA@hostA> ssh userB@hostB

With no ssh client syslog entry
------------------------
sshd server host syslog entry:
Apr 26 09:26:01 hostB sshd[11486]:
Accepted password for userB from 10.10.10.100 port 2926 ssh2

Could be anyone, can't even make a stab in the dark.

With a minimum ssh client syslog entry:
---------------------------------
ssh client host syslog entry:
Apr 26 09:26:01 hostA ssh[11486]:
ssh: user userA connected to host hostB as userB

At least I can probably correlate the event to userA

Sounded like hack your own or go commercial or other options:
http://www.balabit.com/products/scb/

Thanks for the response.

-----Original Message-----
From: Jim Knoble [mailto:jmknoble@pobox.com]
Sent: Wednesday, April 25, 2007 10:01 AM
To: Anderson Russell D (Andy)
Cc: openssh-unix-dev@mindrot.org
Subject: Re: Logging enhancement

Circa 2007-04-24 19:44 dixit Anderson Russell D (Andy):

: I would like to suggest a logging enhancement that would contribute
: greatly to access auditing.
:
: Currently nothing is logged when a user connects to another server as
a
: different user.
:
: The auditing trail is broken for tracing access.
:
: userA> ssh userB@hostB
:
: A simple syslog addition (for example) to ssh.c closes that gap.
: [...]

And what if the user logs into a remote system using an ssh program they
compiled themselves which doesn't have that logging bit in it?

userA@hostA$ /path/to/my/own/ssh userB@hostB

At the very least, you'll need to track every command run by every user,
including its environment (PATH, other environment variables that can
control program behavior, including LD_PRELOAD on appropriate systems).

Furthermore, what if the user sets up a tunneled connection to hostB via
hostA and logs into hostB over that connection?

user5@hostQ$ ssh -f -N -L 23456:hostB:22 userA@hostA
user5@hostQ$ ssh -p 23456 userB@hostB

Now command logging doesn't even help, unless you can log commands run
on hostQ as well.

You're probably better off forcing users to use public key
authentication only, controlling the contents of ~/.ssh/authorized_keys
on the hosts on your network, setting sshd's LogLevel to VERBOSE, and
using the fingerprints logged by sshd to tell who logged into where from
where.

Maybe look into whether using Kerberos and GSSAPI authentication can
help you.

You'll need policies to deal with things like users allowing use of
their accounts or credentials by someone else as well.

--
jim knoble | jmknoble@pobox.com | http://www.pobox.com/~jmknoble/
(GnuPG key ID: 6F39C2CC >>>>>> http://www.pobox.com/~jmknoble/keys/ )
(GnuPG fingerprint: 5024:D578:7CF4:5660:7269::F6F3:B919:9307:6F39:C2CC )
+----------------------------------------------------------------------+
|[L]iberty, as we all know, cannot flourish in a country that is perma-|
| nently on a war footing, or even a near-war footing. --Aldous Huxley|
+----------------------------------------------------------------------+


_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
http://lists.mindrot.org/mailman/lis...enssh-unix-dev