[munkfish]

I'm wanting to log all logins to my sshd by some means and am unsure how to achieve this. I've read through the man pages for sshd, login, utmp, wtmp etc etc and can't seem to find the relevant info.

I've added this to syslog.conf:

# sshd:
!sshd
*.*						/var/log/sshd/sshd.log

but of course this only logs messages created by the sshd system (ie when the daemon starts, creates new keys etc), when I really want to log the times users login, where they login from, how long they were logged in for and when they logged out. Is this possible?

Further is it worth keeping a log of all user's login sessions to check for abuse/misuse and if so, how would this be achieved. I have compiled support for the snoop tty device and was thoroughly impressed by the 'watch' utility which allows a superuser to watch another user's teletype session (and even interact with it, very cool for helping people in trouble). Would it be feasible to log user's login sessions using watch (or otherwise), and if so how would I initiate the watch command line to pipe a login session to a log file (ie how can I execute commands once a user has logged in such that the user has no control over the execution of the commands)?

Many thanks in advance,
Jez

[mezz]

You should check in your /etc/ssh/sshd_config.. My looks like this follows:

#--------------------------------------------------------------
# Logging
#--------------------------------------------------------------
SyslogFacility SSHDLOG
LogLevel DEBUG

My sshd is logging to the SSHDLOG facility, so I add the following lines to my /etc/syslog.conf file..

# Log SSH daemon messages to own file
!sshd
sshdlog.* /var/log/sshd.log

You can change from SSHDLOG to whatever what you wish it to be..

[munkfish]

Cool, thanks mezz - I did add a line 'auth.* /var/log/auth/auth.log' to my syslog.conf file, but it wasn't as verbose as I wanted... I think I'll try increasing the verbosity of it in the 'LogLevel' param in sshd_config, see how that works out.

I like the ability to change the name of the syslogd facility name used by sshd, nice one that (seems by default it's just 'auth').

Do you have any idea about the logging of user's login sessions to file at all?

I can log a user's tty session manually using 'watch <flags> <tty> > output_file.txt', but this is very cumbersome - I'd settle for being able to grep through my user's .history files... trouble is I'm not sure how easy it is for user's to execute commands in a way that bypasses logging to their .history files.

[mezz]

I recently tried on FreeBSD and it doesn't works.. It used to work long time ago when I had Linux...

Oh well, I am using auth so it's fine with me.. I don't know what else to help, so sorry.. Maybe, you can search in the google to see if you can find the luck there..

[freebsd]

syslogd probably can't do what you want. I run sshd from tcpserver and here is the run script:

/var/djb/ssh/run

#!/bin/sh
PATH=/usr/local/bin:/usr/bin:/bin
export PATH
exec tcpserver -vRp -l www.mydomain.com -x root/ssh.cdb \
-c5 -u0 -g0 0 22 /usr/local/sbin/sshd -eiD4 2>&1

My sshd version is: OpenSSH_3.0.2p1
From man 8 sshd -> sshd [-deiqtD46]
I am not sure if default sshd with 4.5-STABLE supports those options since I have been using latest sshd from the ports tree. As for 4.4-STABLE, the default version doesn't support every option as deiqtD46. So check your sshd and make sure.
Here is the list of those options that I used for sshd:

-e      When this option is specified, sshd will send the output to the
             standard error instead of the system log.
-i      Specifies that sshd is being run from inetd.  sshd is normally
             not run from inetd because it needs to generate the server key
             before it can respond to the client, and this may take tens of
             seconds.  Clients would have to wait too long if the key was
             regenerated every time.  However, with small key sizes (e.g.,
             512) using sshd from inetd may be feasible.
-D      When this option is specified sshd will not detach and does not
             become a daemon.  This allows easy monitoring of sshd.

BTW I installed openssh-portable-3.0.2p1 instead of openssh-3.0.2.
It's possible to use recordio in front of sshd in the run script to get more verbose logs. Normally qmail people would use recordio for troubleshooting because it captures everything including the entire email message and the SMTP session.

[mezz]

>> My sshd version is: OpenSSH_3.0.2p1

Well, does it means you have to install OpenSSH 3.0.2p1 at every time when you do the CVSUP/buildworld or you just don't bother to do the CVSUP/buildworld for long time? I am asking, because when I tried to upgrade OpenSSH to 3.xxx, but after CVSUP and buildworld then it brings the default version (downgrade to 2.9) back...

[freebsd]

No, you just need to echo "NO_OPENSSH=true" >> /etc/make.conf so buildworld doesn't build it any longer.

[mezz]

w0w, I didn't know about it.. Thanks freebsd!!

[freebsd]

Not only that, you can add a lot more. Check /usr/ports/Mk/*, /usr/share/mk/* and /etc/defaults/make.conf. Like Sendmail, I don't run it so just NO_SENDMAIL=true to /etc/make.conf. Though cvsup will fetch the latest src but buildworld just won't build it.

[mezz]

Thanks for more tips..

Ummm, when I tried to upgrade openssh 2.9 to 3.0.2p1 then I typed "sshd -V" but it says 2.9 ever thought I already installed from ports.

At first, I killed sshd by follows killall -HUP sshd then upgrade it from ports. Do I have to remove freebsd's default ssh first by manual before I use ports to install newest version?

[freebsd]

>> Do I have to remove freebsd's default ssh first

No but afterward because once it's installed it doesn't launch automatically. Here is what you need to do afterward:
1) chmod 0 and mv it with a .bak extension or whatever to the following files:

/usr/bin:
            ssh-add
            ssh-agent
            ssh-keygen
            ssh
/usr/libexec:
            sftp-server
/usr/sbin:
            sshd

2) rm -f the old manpage and catpage of above binaries
/usr/share/man/man1,8/*
/usr/share/man/cat1,8/*
3) Remove sshd_enable="YES" from /etc/rc.conf (if supervise). If running it standlone, you can use the script in /usr/local/etc/rc.d/ or append sshd_program="/usr/local/sbin/sshd" to /etc/rc.conf.

[mezz]

Thanks freebsd.. Here what I put in shell script follows:

remove whole man of ssh

#!/bin/sh

log=/var/tmp/_$$rmmanssh.log
/bin/rm -rf /var/tmp/_*rmmanssh.log

for i in                                        \
        /usr/share/man/cat1/ssh-keygen.1.gz     \
        /usr/share/man/cat1/ssh.1.gz            \
        /usr/share/man/cat8/sshd.8.gz           \
        /usr/share/man/man1/ssh.1.gz            \
        /usr/share/man/man1/ssh-add.1.gz        \
        /usr/share/man/man1/ssh-agent.1.gz      \
        /usr/share/man/man1/ssh-keygen.1.gz     \
        /usr/share/man/man8/sshd.8.gz           \

do
        if [ -e $i ]; then
                echo "/bin/rm -f $i" >> $log
                /bin/rm -f $i
        else
                echo "$i does not exist." >> $log
        fi
done

Another script for killall, chmod 0 and mv to .bak follows:

#!/bin/sh

log=/var/tmp/_$$mvssh.log
/bin/rm -rf /var/tmp/_*mvssh.log

for i in                                \
        /usr/bin/ssh                    \
        /usr/bin/ssh-add                \
        /usr/bin/ssh-agent              \
        /usr/bin/ssh-keygen             \
        /usr/sbin/sshd                  \
        /usr/libexec/sftp-server        \

do
        if [ -e $i ]; then
                echo "/bin/mv $i $i.bak" >> $log
                /usr/bin/killall -HUP sshd
                /bin/chmod 0 $i
                /bin/mv $i $i.bak
        else
                echo "$i does not exist." >> $log
        fi
done

Both shell scripts seem work perfectly, so I am going to install openssh again then modify to get startup works..

Thanks again,
Mezz

[munkfish]

mezz:
I recently tried on FreeBSD and it doesn't works.. It used to work long time ago when I had Linux...

If you're referring to the watch utility, you need to compile in support for the snoop device into the kernel - this is very very simple to do and afaik doesn't add any massive overhead to things, plus it's quite useful if you have mates who aren't sure what they're doing in UNIX because it even lets you interact on the command-line with an already established login on a given tty (so you can 'help' users out as they work!). Good fun, bit of a toy, although as I say it's also nice in that it allows you to log a tty session to a file.

Anyway, there's a simple howto for building in support for snoop device at this place: http://freebsdhowtos.com/86.html

freebsd:
djb tools again! I've been back to the site many times now, although I still haven't downloaded anything as yet - the tool kit sounds very useful and I'll have to grab it and read through the docs. I must admit I hadn't thought of running sshd via a wrapper (in fact I've not even touched on the use of wrappers at all as yet), so I'll have a go at running sshd as you mention via djb's tcp-server util (ditto with the other service I currently run via inetd, so long inetd!).

Further the recordio tool at djb that you mention sounds very interesting, another avenue I'll look at. Am I being too paranoid in worrying what users are/will be doing on my server? What is the best strategy to deploy in watching for 'bad/abusive behaviour' from users?

Thanks in advance,
Jez

[mezz]

Thanks munkfish for the link..

BTW: freebsd, I had to put sshd_enable="YES" in /etc/rc.conf to make it works. Without it then it will not startup as well. I found one link in freebsd.org, but it's non-english so it works very well with sshd_enable="YES".. http://www.freebsd.org.pl/?q=sshd

Anyway, thanks for help..

[freebsd]

>> ditto with the other service I currently run via inetd

inetd, being the top three most vulernable software (among the others: BIND and Sendmail), should be disabled and look for replacement.
tcpserver, on the other hand, will never suffer DoS attack because you can control the limit and how many simultaneous connection and many others.
Just remember one thing: djb is the best UNIX software developer in the world.

>> the recordio tool at djb that you mention sounds very interesting

I'm still unsure whether recordio can really capture everything. Here is a smtp run script:

#!/bin/sh
PATH=/var/qmail/bin:/usr/local/bin:/usr/bin:/bin 
export PATH
exec 2>&1
exec envdir ./env sh -c '
 exec softlimit -m32768000 \
tcpserver -vR -l mail.mydomain.com -x root/smtp.cdb -c30 -u82 -g81 0 25 \
rblsmtpd -r inputs.orbz.org -r outputs.orbz.org \
-r "rbl.mydomain.com:Sorry. Spamming is not allowed! - %IP%" qmail-smtpd
'

If you need to insert recordio, it will then be:

#!/bin/sh
PATH=/var/qmail/bin:/usr/local/bin:/usr/bin:/bin 
export PATH
exec 2>&1
exec envdir ./env sh -c '
 exec softlimit -m32768000 \
tcpserver -vR -l mail.mydomain.com -x root/smtp.cdb -c30 -u82 -g81 0 25 \
rblsmtpd -r inputs.orbz.org -r outputs.orbz.org \
-r "rbl.mydomain.com:Sorry. Spamming is not allowed! - %IP%" recordio qmail-smtpd
'

When your qmail-smtpd is TLS-aware, you can't use recordio and smtpd will choke. Though you can still try it with sshd+supervise+tcpserver.

>> Am I being too paranoid

Yes and you are invading the privacy of your users.