Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
Instead of just one line, this gets printed when loggin in: "Last login: Tue Oct 28 19:38:19 WET 2008 from flamingo-b01.housing.ua.pt on pts/0 Last login: Tue Oct 28 19:45:53 2008 from flamingo-b01.housing.ua.pt" This seems to be because of the /etc/pam.d/sshd file, when using the one from the 4.7 version, everything is fine. Reproducible: Always Steps to Reproduce: 1.upgrade to version 5.1_p1-r1 2.update the configuration files 3. Actual Results: "Last login: Tue Oct 28 19:38:19 WET 2008 from flamingo-b01.housing.ua.pt on pts/0 Last login: Tue Oct 28 19:45:53 2008 from flamingo-b01.housing.ua.pt" Expected Results: Last login: Tue Oct 28 19:38:19 WET 2008 from flamingo-b01.housing.ua.pt on pts/0 or Last login: Tue Oct 28 19:45:53 2008 from flamingo-b01.housing.ua.pt"
*** Bug 244849 has been marked as a duplicate of this bug. ***
Note: This problem doesn't just cause the login to be shown twice (because of defaulting to "PrintLastLog yes" in combination with pam_lastlog.so), but causes wtmp to be updated twice, which is more serious. Even if setting "PrintLastLog no", you now get two wtmp entries.
More output in the hope that it'll be useful. -- login as: root Using keyboard-interactive authentication. Password: Last login: Sat Nov 1 15:24:17 EAT 2008 from 192.168.0.77 on pts/0 Last login: Sat Nov 1 15:44:43 2008 from 192.168.0.14 Loki ~ # last -10 root pts/0 192.168.0.14 Sat Nov 1 15:44 still logged in root ssh 192.168.0.14 Sat Nov 1 15:44 still logged in root pts/0 192.168.0.77 Sat Nov 1 15:24 - 15:24 (00:00) root ssh 192.168.0.77 Sat Nov 1 15:24 - 15:24 (00:00) reboot system boot 2.6.25-gentoo-r8 Sat Nov 1 15:23 (00:24)
(In reply to comment #2) > Note: This problem doesn't just cause the login to be shown twice (because of > defaulting to "PrintLastLog yes" in combination with pam_lastlog.so), but > causes wtmp to be updated twice, which is more serious. > > Even if setting "PrintLastLog no", you now get two wtmp entries. > I had the same issue here and disabled the lastlog in sshd_config to let only PAM display the last login. Now while reading this bug I see that this is not a clean solution as it still leaves two entries in wtmp. last -10 billie pts/0 gentoo.linux.net Mon Nov 10 18:45 still logged in billie ssh gentoo.linux.net Mon Nov 10 18:45 still logged in billie pts/0 gentoo.linux.net Mon Nov 10 18:45 - 18:45 (00:00) billie ssh gentoo.linux.net Mon Nov 10 18:45 - 18:45 (00:00) billie pts/0 gentoo.linux.net Mon Nov 10 18:43 - 18:45 (00:01) billie ssh gentoo.linux.net Mon Nov 10 18:43 - 18:45 (00:01) billie pts/0 gentoo.linux.net Mon Nov 10 18:21 - 18:39 (00:18) billie ssh gentoo.linux.net Mon Nov 10 18:21 - 18:39 (00:18) billie pts/0 gentoo.linux.net Mon Nov 10 18:20 - 18:21 (00:00) billie ssh gentoo.linux.net Mon Nov 10 18:20 - 18:21 (00:00) wtmp begins Sat Nov 1 22:17:04 2008
(In reply to comment #4) > (In reply to comment #2) > > Note: This problem doesn't just cause the login to be shown twice (because of > > defaulting to "PrintLastLog yes" in combination with pam_lastlog.so), but > > causes wtmp to be updated twice, which is more serious. > > > > Even if setting "PrintLastLog no", you now get two wtmp entries. > > > > I had the same issue here and disabled the lastlog in sshd_config to let only > PAM display the last login. Now while reading this bug I see that this is not a > clean solution as it still leaves two entries in wtmp. Modify your /etc/pam.d/sshd like this and leave sshd_config asis: # cat /etc/pam.d/sshd auth include system-remote-login account include system-remote-login password include system-remote-login #session include system-remote-login session required pam_env.so session include system-auth
That's not a solution and certainly not a supported one since you're going to skip over the important session chain! I hope to get a fix for this asap, I just am focusing on something else right at this moment.
(In reply to comment #5) > Modify your /etc/pam.d/sshd like this and leave sshd_config asis: > # cat /etc/pam.d/sshd > auth include system-remote-login > account include system-remote-login > password include system-remote-login > #session include system-remote-login > session required pam_env.so > session include system-auth You can't be serious recommending this as an option. Why using pam at all when one disables it's features if an issue occurs. Removing lastlog in sshd_config is only a cosmetic workaround that disables the display of the last login. This however looks like a dirty hack to me as it is not only removing the display of the last login, it removes an entire feature from the pam configuration which probably will affect other remote connections besides ssh.
(In reply to comment #7) > (In reply to comment #5) > > Modify your /etc/pam.d/sshd like this and leave sshd_config asis: > > # cat /etc/pam.d/sshd > > auth include system-remote-login > > account include system-remote-login > > password include system-remote-login > > #session include system-remote-login > > session required pam_env.so > > session include system-auth > > You can't be serious recommending this as an option. Why using pam at all when > one disables it's features if an issue occurs. What is being disabled (I'm not a PAM expert)? > This however looks like a dirty hack to me as it is > not only removing the display of the last login, it removes an entire feature > from the pam configuration which probably will affect other remote connections > besides ssh. Yes it looks like pam_mail.so is missing. Our servers have a large motd and lastlog auditing is broken so this problem needed to be addressed asap. This "dirty hack" seems to be working perfectly so if there is a problem I'd like to know about it so I can revert openssh instead.
(In reply to comment #8) > What is being disabled (I'm not a PAM expert)? Well, me not either. But from looking at this it removes the whole pam session management for ssh logins. This may indeed solve the symptoms as the module causing the problem is not used anymore, but it is not a solution to the problem. > Our servers have a large motd and lastlog auditing is broken so this problem > needed to be addressed asap. This "dirty hack" seems to be working perfectly > so if there is a problem I'd like to know about it so I can revert openssh > instead. Okay "dirty hack" was a bit exagerated here. If your auditing works with it I think you are fine. It is just you are not using pam for logging but let ssh itself do the job. The problem here seems to be that pam and ssh are trying to do the same thing, so a fix is probably to decide who should do it.
Shouldn't the ebuild be masked until this is sorted out? That would seem the right thing to do, if there really are any security implications with this version.
(In reply to comment #9) > (In reply to comment #8) > > What is being disabled (I'm not a PAM expert)? > > Well, me not either. But from looking at this it removes the whole pam session > management for ssh logins. This may indeed solve the symptoms as the module > causing the problem is not used anymore, but it is not a solution to the > problem. If you look at system-remote-login (in /etc/pam.d) all it does is call system-login (also in /etc/pam.d). So system-remote-login is useless and all the logic is in system-login. system-login contains this for the session section: session required pam_env.so session optional pam_lastlog.so session include system-auth session optional pam_motd.so motd=/etc/motd session optional pam_mail.so If you remove lastlog and motd (and mail) you get what I suggested. I lean to fixing this in pam rather than openssh because the pam fix is config files while fixing it in openssh requires code patches.
There is also a difference in behavior in the way "logins" are added to wtmp via pam. sshd does not add an entry to wtmp if ssh doesn't start a login session, ie this does not go to wtmp: ssh root@someserver ls (that runs ls on someserver and pipes it to stdout on the host running ssh) however pam_lastlog.so adds an entry to wtmp for non-login sessions (the tty is "ssh"). This means adding entries via pam is a change in behavior.
*** Bug 250287 has been marked as a duplicate of this bug. ***
I'm sincerely tempted to just disable the lastlogin update from sshd itself and just leave the one from PAM, if not for anything for the reason it does write down the ssh connections without actual login shells (which to me is a desirable option). Does anybody have an argument for not doing so?
(In reply to comment #14) > Does anybody have an argument for not doing so? Please take the other way round, disable pam_lastlog for sshd. Reasons for this include: a) Being compatible with what we've been doing for past five years b) Being compatible with what all other distributions [1] are doing Please don't make Gentoo be different by default, especially when there's no compelling reason to do so. [1] Verified on Debian, RHEL and OpenSUSE.
(In reply to comment #2) > Even if setting "PrintLastLog no", you now get two wtmp entries. That's untrue. PrintMotd no PrintLastLog no in the /etc/ssh/sshd_config fixes the problem of the two messages for me.
(In reply to comment #16) > (In reply to comment #2) > > Even if setting "PrintLastLog no", you now get two wtmp entries. > > That's untrue. > PrintMotd no > PrintLastLog no > in the /etc/ssh/sshd_config > fixes the problem of the two messages for me. Yes, it's true. wtmp != the messages you eyeball when you log in, it's the logging information that you DON'T see unless you specifically ask for it. And if you have the pam use flag, both pam and sshd appears to update wtmp, which is wrong: kether ~ # grep PrintLastLog /etc/ssh/sshd_config PrintLastLog no kether ~ # last -2 art pts/1 kestrel.lightnin Wed Dec 10 21:47 still logged in art ssh kestrel.lightnin Wed Dec 10 21:47 still logged in One entry is made by pam.d (pts/1) and one by sshd (ssh). Since pam is defined as a USE flag, the natural assumption would be that pam should do the update instead of sshd. Especially since it logs the tty used, which is VERY useful when doing a ps and finding a job on servers where users log in multiple times -- you can check how long ago that person logged on in that window, and take actions accordingly. With the "ssh" entry, you lose that ability. man wtmp for more information on wtmp.
> kether ~ # grep PrintLastLog /etc/ssh/sshd_config > PrintLastLog no > kether ~ # last -2 > art pts/1 kestrel.lightnin Wed Dec 10 21:47 still logged in > art ssh kestrel.lightnin Wed Dec 10 21:47 still logged in > > One entry is made by pam.d (pts/1) and one by sshd (ssh). I think that is backwards. The pam entry prints "ssh" and sshd prints the tty "pts/1". > Especially since it logs the tty used, which is VERY useful > when doing a ps and finding a job on servers where users log in multiple times > -- you can check how long ago that person logged on in that window, and take > actions accordingly. I agree.
I didn't want to meddle with the "PAM-wide" system-login, so I just copied the lines pertaining to the session configuration into the sshd configuration and commented out the lines responsible for the double motd, lastlog and wtmp entries. My /etc/pam.d/sshd now reads: """ # cat /etc/pam.d/sshd auth include system-remote-login account include system-remote-login password include system-remote-login #session include system-remote-login session required pam_env.so #session optional pam_lastlog.so session include system-auth #session optional pam_motd.so motd=/etc/motd session optional pam_mail.so """ The only caveat would be that this breaks the inclusion of the "system-wide" PAM settings into the PAM sshd settings, but I'd say its a lesser "risk" than commenting this stuff out in the system-login PAM file, it doesn't change the sshd_config and you have only one line in wtmp with the correct tty.
(In reply to comment #19) [ commenting out pam system-login ] > > The only caveat would be that this breaks the inclusion of the "system-wide" > PAM settings into the PAM sshd settings, but I'd say its a lesser "risk" than > commenting this stuff out in the system-login PAM file, it doesn't change the > sshd_config and you have only one line in wtmp with the correct tty. I'd say that could be a pretty big caveat. How would, for example, selinux be able to set the context if pam_selinux.so is never called? Or anything else that goes in system-login or system-remote-login?
(In reply to comment #20) > (In reply to comment #19) > [ commenting out pam system-login ] > > > > The only caveat would be that this breaks the inclusion of the "system-wide" > > PAM settings into the PAM sshd settings, but I'd say its a lesser "risk" than > > commenting this stuff out in the system-login PAM file, it doesn't change the > > sshd_config and you have only one line in wtmp with the correct tty. > > I'd say that could be a pretty big caveat. How would, for example, selinux be > able to set the context if pam_selinux.so is never called? Or anything else > that goes in system-login or system-remote-login? Well, that's my (hopefully temporary) fix for it, I didn't say it would solve every problem :-) Anyway, I like to believe that people who meddle with their PAM settings or with SELinux know what they are doing and would be able remember to change /etc/pam.d/sshd if they notice that a package just changed their /etc/pam.d/system{,-remote}-login. Unfortunately, I'm not aware of a way to disable optional PAM statements from an included file, which would make this fix less of a problem. Ultimately, this is in my eyes an upstream problem, which should disregard optional pam_motd.so and pam_lastlog.so if they already have their own blurb and config for it, in the end, that's why they are optional :-) Anyway, I'm not even proposing to put this in the ebuild, because it's not a fix, but the less painful workaround. Anyone knows if it's already been reported upstream?
Okay, let's cure one step at a time, the actual double display is fixed by openssh-5.1_p1-r3. I'll be taking care of the double entry in lastlog, with a new pambase release.
*** Bug 262371 has been marked as a duplicate of this bug. ***
