problem: whenever you startup a ssh session with a graphical ssh client, fork a sftp session, and exit the ssh session the wtmp log indicates the user has logged out even though they still have an open sftp session. reproducibility: always workaround: startup a sftp session first, then fork a ssh session. I believe this bug is related to "session_destroy_all(NULL);" in "server_loop2(Authctxt *authctxt)" from "serverloop.c". it appears that the sftp session is being closed in the wtmp log whenever the parent ssh process exits.
sftp sessions are never creates a 'wtmp'. So I don't see this as really a bug.
so if the user is actively using an sftp session they aren't logged on? all of the major ftp servers seem to disagree with your stance as they DO log to the wtmp log whenever a user begins and ends an ftp session. therefore, the sftp server needs to log user logons/logoffs to the wtmp log. if yo u don't, the wtmp log will not be accurate and some insitutions, such as universities, need accurate logs of who is using the system at all times.
> [..] major ftp servers seem to disagree [..] Who said sshd was a ftp server? Ignoring the fact this 'feature' was added about four/five years ago. Against a lot of people's believes that it was an abuse of the wtmp file. Besides, there is no clear way of saying "this is an sftp" session. Tagging all subsystems as a 'must have wtmp' is wrong since subsystems is a generic concept. And you can always do 'sftp -1 localhost' under OpenSSH which skips the subsystem since SSH v1 protocol does not support it. try: ssh localhost /bin/ksh or scp file localhost:/tmp or ssh localhost 'cat /my/file' > file none of them create wtmp entry. Try the rsh versions and you'll see they the same behavior. - Ben
> Besides, there is no clear way of saying "this is an sftp" session. couldn't ssh just write to the wtmp log whenever sftp-server starts and exits respectively? > Tagging all subsystems as a 'must have wtmp' is wrong since subsystems is a generic concept. the generic nature of subsystems like shells, etc is irrelevant, IMHO. sshd forks for every user session and doesn't exist until the command, shell, etc has exited. so here is a typical senario: 1.) sshd recieves a connection and authenicates the user 2.) sshd forks to handle the user's session 3.) the child(sshd) writes to the wtmp log that the user has logged on 4.) the child(sshd) executes a command or subsystem(if any) and waits on the child 5.) the command or subsystem process exits 6.) the child(sshd) recieves the exit status and writes to the wtmp log that user has logged off 6.) the child(sshd) exits apparantly, you believe that logging user sessions to the wtmp log is abuse? I consider it nothing less than mandatory. consider this situation: a university student executes "ssh user@host /bin/ksh" and does something malign to the system intentionally or unintentially. it would help tremedously if the wtmp log reflected who actually logged on during that period. basically, openssh provides several loopholes around proper user session logging through subsystems and I find this to be a huge security risk. I've spoken with a couple of sysadmins at neighboring universities and they have the same problem/concerns. I'm just the first one to speak up about it. don't get me wrong, I love what you guys are doing with openssh but this is a serious issue.
wtmp is not for logins, it's for ttys. using it for sftp is an abuse and causes portability nightmares. we could abuse wtmp, but not now. apart from that only rlogin causes wtmp entries, rsh does not. sshd tried to emulate this from the beginning. now every ssh host ls would create a wtmp entry, same about cvs over ssh.
> wtmp is not for logins, it's for ttys. from UTMP(5) man page: "The file <utmp.h> declares the structures used to record information about current users in the file utmp, logins and logouts in the file wtmp, and last logins in the file lastlog." furthermore: "Next, the login program opens the file wtmp, and appends the user's utmp record. The same utmp record, with an updated time stamp is later ap- pended to the wtmp file when the user logs out (see init(8))." an empty tty can be included in the log for that user. > using it for sftp is an abuse and causes portability nightmares. correct me if I'm wrong, but you already have "ssh_login.c", etc so the portable wtmp logging code has been there for a while. it's simply a matter of incorporating the existing functionality in the write place i.e. whenever a subsystem is called. as it stands, ssh provides an insecure login method where a user can go undetected by exploiting the subsystem and thus rendering commands such as 'who' and 'last' useless...
correct me if i'm wrong, but wtmp is about 'lines' i.e. ttys and not arbitrary remote command execution. traditionally, in rlogind/rshd/sshd, _login_ refers to login sessions involving terminals. and as i said, no it's not a bug, its intentional in sshd for about 8 years, but, as i said before we might consider changing this. but having all remote command executions in wtmp is a huge change that should not be made without considering all kinds of side effects.
tility functions SYNOPSIS #include <utmp.h> #include <util.h> void login(struct utmp *ut); int logout(const char *line); void logwtmp(const char *line, const char *name, const char *host); DESCRIPTION The login(), logout(), and logwtmp() functions operate on the database of current users in /var/run/utmp and on the logfile /var/log/wtmp of logins and logouts. The login() function updates the /var/run/utmp and /var/log/wtmp files with user information contained in ut. The logout() function removes the entry from /var/run/utmp corresponding to the device line. The logwtmp() function adds an entry to /var/log/wtmp. Since login() will add the appropriate entry for /var/log/wtmp during a login, logwtmp() is usually used for logouts. RETURN VALUES logout() returns non-zero if it was able to find and delete an entry for line, and zero if there is no entry for line in /var/run/utmp. XXX, need unique ttyline
XXX adding wtmp logging to subsystems only will lead to a false sense of so called security since sftp will not be logged for sftp -s /usr/libexec/sftp-server server
I looked at creating a patch for the current version, but I ran into problems with "privilege separation" i.e. setuid(). I noticed that you fork several times to handle a user logons, especially using privilege separation, which makes it bit more confusing. the change is located in "session.c" where you have two functions to handle the user: void do_exec_pty(Session *s, const char *command) void do_exec_no_pty(Session *s, const char *command) and the only difference is "do_exec_pty" calls "do_login" which calls "record_login" in "sshlogin.c" because "do_exec_pty" handles shell invocations. the logon(writing to the wtmp file) only occurs if privilege separation is not used so it's a bit confusing. so the obvious fix to the nieve developer, me, is to add "do_login" to the "do_exec_no_pty" function to handle all subsystem invocations but this doesn't work if privilege separation is used because the executing process is running as the user who was authenticated and not root. any ideas? FYI, executing "sftp -s /usr/libexec/sftp-server <host>" goes through "do_exec_no_pty" just like all subsystem commands so it would be logged too...
the unprivileged process, needs to tell the monitor that it executes a command. this requires a new privsep message. but as is said before: having all remote command executions in wtmp is a huge change that should not be made without considering all kinds of side effects.
I don't see this changing - [uw]tmp have been for interactive, tty-ful logins since their inception.
Change all RESOLVED bug to CLOSED with the exception of the ones fixed post-4.4.