My respects all,
In the same idea, I have developed a patch (I called it "Audit data")
and I wanted to propose to the community to be part of the main branch.
Here is a few lines in my syslog files.
Oct 1 23:01:00 XXXSOMEHOSTNAME1XXX sshd[31568]: LOGIN Audit Data: [
82:12:65:5a:1a:91:58:71:b2:31:06:80:3c:1b:7b:95 # XXXFROM_IPXXX # /dev/pts/3 #
sys_admin ]
Oct 2 13:08:46 XXXSOMEHOSTNAME1XXX sshd[7689]: COMMAND Audit Data: [
82:fa:c2:26:42:12:36:5b:56:25:9b:5c:fc:af:9f:8e # XXXFROM_IPXXX # no pty #
sys_admin # rsync --server -logDtprI --timeout=30 --numeric-ids . / ]
Oct 1 23:42:40 XXXSOMEHOSTNAME1XXX sshd[31567]: LOGOUT Audit Data: [
82:12:65:5a:1a:91:58:71:b2:31:06:80:3c:1b:7b:95 # XXXFROM_IPXXX # /dev/pts/3 #
sys_admin ]
We manage a lot of "identical" hosts and instead of having an username
for each person or implementing an expensive solution for Identity management
(such as Novell Identity Manager or Control SA), we have defined
"generic" users on the remote hosts (sys_admin, net_admin, dba_admin,
... ). SSH Public keys of authorized peoples are deployed via an internal tool
to remote hosts according to their permissions.
An unix administrator --> /home/sys_admin/.ssh/authorized_keys
An Network administrator --> /home/net_admin/.ssh/authorized_keys
And so on ...
By patching the SSHD daemon with the "audit patch" I have created,
SSHD sends to syslog all the details to identify who is connecting on
"sys_admin" for a given time. (of course rsyslog also sends to a
remote rsyslog server)
3 types of logs are sent to rsyslog:
* LOGIN Audit data: [ Fingerprint + Source_IP + PTY allocated + Generic User
used ]
* LOGOUT Audit data: [ Fingerprint + Source_IP + PTY allocated + Generic User
used ]
* COMMAND Audit data (Command executed via "ssh host command" for
instance) : [ fingerprint + Source IP + pty if allocated + Remote user used +
Detail of the remote command launched]
("LogLevel INFO" in the sshd_config file)
Do you find my idea is worth enough to be part of the main branch ?
What is the procedure to "propose" a patch to the community ?
Thank you for your answers in advance !
Best regards,
Theary LOCH.
(System and Security Engineer)
-----Message d'origine-----
De : openssh-unix-dev-bounces+theary.loch=atos.net at mindrot.org
[mailto:openssh-unix-dev-bounces+theary.loch=atos.net at mindrot.org] De la part
de Eldon Koyle
Envoy? : mardi 1 octobre 2013 23:38
? : openssh-unix-dev at mindrot.org
Objet : sshd accepted fingerprint logging
Currently, LogLevel must be set to VERBOSE to see the fingerprint of an accepted
key, and the default LogLevel is INFO. Since this is useful security
information, I would like to propose that the 'Accepted publickey'
message be modified to include the fingerprint of the accepted key. Is this a
reasonable solution?
Here is an example log snippet with LogLevel VERBOSE:
Oct 1 15:23:24 somehost sshd[18603]: Set /proc/self/oom_score_adj to 0 Oct 1
15:23:24 somehost sshd[18603]: Connection from 192.168.1.2 port 49331 Oct 1
15:23:24 somehost sshd[18603]: Found matching RSA key:
7a:70:db:e4:2a:6f:1f:01:8a:fe:15:97:99:fb:e0:2a
Oct 1 15:23:24 somehost sshd[18603]: Postponed publickey for someuser from
192.168.1.2 port 49331 ssh2 [preauth] Oct 1 15:23:24 somehost sshd[18603]:
Found matching RSA key: 7a:70:db:e4:2a:6f:1f:01:8a:fe:15:97:99:fb:e0:2a
Oct 1 15:23:24 somehost sshd[18603]: Accepted publickey for someuser from
192.168.1.2 port 49331 ssh2 Oct 1 15:23:24 somehost sshd[18603]:
pam_unix(sshd:session): session opened for user someuser by (uid=0) Oct 1
15:23:24 somehost sshd[18603]: User child is on pid 18610
--
Eldon Koyle
--
Men often believe -- or pretend -- that the "Law" is something sacred,
or at least a science -- an unfounded assumption very convenient to governments.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev at mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Ce message et les pi?ces jointes sont confidentiels et r?serv?s ? l'usage
exclusif de ses destinataires. Il peut ?galement ?tre prot?g? par le secret
professionnel. Si vous recevez ce message par erreur, merci d'en avertir
imm?diatement l'exp?diteur et de le d?truire. L'int?grit? du message ne
pouvant ?tre assur?e sur Internet, la responsabilit? de Worldline ne pourra ?tre
recherch?e quant au contenu de ce message. Bien que les meilleurs efforts soient
faits pour maintenir cette transmission exempte de tout virus, l'exp?diteur
ne donne aucune garantie ? cet ?gard et sa responsabilit? ne saurait ?tre
recherch?e pour tout dommage r?sultant d'un virus transmis.
This e-mail and the documents attached are confidential and intended solely for
the addressee; it may also be privileged. If you receive this e-mail in error,
please notify the sender immediately and destroy it. As its integrity cannot be
secured on the Internet, the Worldline liability cannot be triggered for the
message content. Although the sender endeavours to maintain a computer
virus-free network, the sender does not warrant that this transmission is
virus-free and will not be liable for any damages resulting from any virus
transmitted.