On Tue, Jul 17, 2018 at 6:22 PM, Damien Miller <djm at mindrot.org> wrote:> > > On Tue, 17 Jul 2018, Rob Marshall wrote: > >> Hi, >> >> I built OpenSSH 7.7p1-1 to try to include some security fixes for an old OS >> version (SLES 10). We use a special PAM module for root to allow us to >> provide auto-expiring passwords. There is, however, one root password that >> should always work. root can login just fine on the console, which I assume >> means that the PAM module is working correctly because I can use both the >> always should work password and an auto-expiring password. And if I provide >> a valid key in authorized_keys I can login via ssh without a password >> without any problems. >> >> I can also login as root just fine via ssh prior to installing the RPM I >> built for OpenSSH 7.7p1-1. However, once I install it, I can no longer ssh >> as root. I saved the file: /etc/pam.d/sshd from prior to the install and >> restore it after the RPM is installed since it overwrites it. I have a >> /etc/pam.d/common-auth that has: >> test10:/etc/pam.d # cat sshd > >> #%PAM-1.0 >> auth include common-auth >> auth required pam_nologin.so > > I think pam_nologin.so should be in the "account" rather than "auth" stack. > > I.e. > > account required pam_nologin.so > > -dDefinitely check /etc/ssh/sshd_login, or wherever your particular version of SSH expects its sshd_config, for the value of "PermitRootLogin". If you're a weasel, and want to test SSHD configs. And.... This is why PAM is often a solution in search of a problem to cause. It provides enormous flexibility, but has no effective line-by-line management or review tool to double check the frequently confusing results of manual editing. And there are a *lot* of Google-discoverable manual tune-ups that break things you don't expect at times you can't afford. The few PAM management tools (such as authconfig) do not keep PAM consistent with previous manual edits. The results can be seriously destructive. If you'd like to review what it was before any manual auditing or before "authconfig" was run to tune your local environment, I urge you to do "rpm -q -f /etc/pam.d/sshd", get the original RPM that provided the original file, and take it apart with "rpm2cpio.sh filename | cpio -id" to see what the original file looked like, then compare it side-by-side for the results of editing.
Hi, I added some debugging to my PAM module and it looks like rather than returning the password the pam_prompt() is getting: " INCORRE" returned in the password field. Any idea how that could happen? Thanks, Rob On Wed, Jul 18, 2018 at 6:23 AM Nico Kadel-Garcia <nkadel at gmail.com> wrote:> On Tue, Jul 17, 2018 at 6:22 PM, Damien Miller <djm at mindrot.org> wrote: > > > > > > On Tue, 17 Jul 2018, Rob Marshall wrote: > > > >> Hi, > >> > >> I built OpenSSH 7.7p1-1 to try to include some security fixes for an > old OS > >> version (SLES 10). We use a special PAM module for root to allow us to > >> provide auto-expiring passwords. There is, however, one root password > that > >> should always work. root can login just fine on the console, which I > assume > >> means that the PAM module is working correctly because I can use both > the > >> always should work password and an auto-expiring password. And if I > provide > >> a valid key in authorized_keys I can login via ssh without a password > >> without any problems. > >> > >> I can also login as root just fine via ssh prior to installing the RPM I > >> built for OpenSSH 7.7p1-1. However, once I install it, I can no longer > ssh > >> as root. I saved the file: /etc/pam.d/sshd from prior to the install and > >> restore it after the RPM is installed since it overwrites it. I have a > >> /etc/pam.d/common-auth that has: > >> test10:/etc/pam.d # cat sshd > > > >> #%PAM-1.0 > >> auth include common-auth > >> auth required pam_nologin.so > > > > I think pam_nologin.so should be in the "account" rather than "auth" > stack. > > > > I.e. > > > > account required pam_nologin.so > > > > -d > > Definitely check /etc/ssh/sshd_login, or wherever your particular > version of SSH expects its sshd_config, for the value of > "PermitRootLogin". If you're a weasel, and want to test SSHD configs. > > And.... This is why PAM is often a solution in search of a problem to > cause. It provides enormous flexibility, but has no effective > line-by-line management or review tool to double check the frequently > confusing results of manual editing. And there are a *lot* of > Google-discoverable manual tune-ups that break things you don't expect > at times you can't afford. The few PAM management tools (such as > authconfig) do not keep PAM consistent with previous manual edits. The > results can be seriously destructive. > > If you'd like to review what it was before any manual auditing or > before "authconfig" was run to tune your local environment, I urge > you to do "rpm -q -f /etc/pam.d/sshd", get the original RPM that > provided the original file, and take it apart with "rpm2cpio.sh > filename | cpio -id" to see what the original file looked like, then > compare it side-by-side for the results of editing. >
Hi, Sorry, figured it out. Looking through the OpenSSH code I saw that fake_password() (which returns a bogus password with the word: INCORRECT) gets returned if root logins are not permitted. I checked sshd_config and, sure enough, PermitRootLogin was commented out and I assume the default is: no. I uncommented it and set it to "yes" and now it's working. Rob On Thu, Jul 19, 2018 at 11:38 AM Rob Marshall <rob.marshall17 at gmail.com> wrote:> Hi, > > I added some debugging to my PAM module and it looks like rather than > returning the password the pam_prompt() is getting: " INCORRE" returned in > the password field. Any idea how that could happen? > > Thanks, > > Rob > > On Wed, Jul 18, 2018 at 6:23 AM Nico Kadel-Garcia <nkadel at gmail.com> > wrote: > >> On Tue, Jul 17, 2018 at 6:22 PM, Damien Miller <djm at mindrot.org> wrote: >> > >> > >> > On Tue, 17 Jul 2018, Rob Marshall wrote: >> > >> >> Hi, >> >> >> >> I built OpenSSH 7.7p1-1 to try to include some security fixes for an >> old OS >> >> version (SLES 10). We use a special PAM module for root to allow us to >> >> provide auto-expiring passwords. There is, however, one root password >> that >> >> should always work. root can login just fine on the console, which I >> assume >> >> means that the PAM module is working correctly because I can use both >> the >> >> always should work password and an auto-expiring password. And if I >> provide >> >> a valid key in authorized_keys I can login via ssh without a password >> >> without any problems. >> >> >> >> I can also login as root just fine via ssh prior to installing the RPM >> I >> >> built for OpenSSH 7.7p1-1. However, once I install it, I can no longer >> ssh >> >> as root. I saved the file: /etc/pam.d/sshd from prior to the install >> and >> >> restore it after the RPM is installed since it overwrites it. I have a >> >> /etc/pam.d/common-auth that has: >> >> test10:/etc/pam.d # cat sshd >> > >> >> #%PAM-1.0 >> >> auth include common-auth >> >> auth required pam_nologin.so >> > >> > I think pam_nologin.so should be in the "account" rather than "auth" >> stack. >> > >> > I.e. >> > >> > account required pam_nologin.so >> > >> > -d >> >> Definitely check /etc/ssh/sshd_login, or wherever your particular >> version of SSH expects its sshd_config, for the value of >> "PermitRootLogin". If you're a weasel, and want to test SSHD configs. >> >> And.... This is why PAM is often a solution in search of a problem to >> cause. It provides enormous flexibility, but has no effective >> line-by-line management or review tool to double check the frequently >> confusing results of manual editing. And there are a *lot* of >> Google-discoverable manual tune-ups that break things you don't expect >> at times you can't afford. The few PAM management tools (such as >> authconfig) do not keep PAM consistent with previous manual edits. The >> results can be seriously destructive. >> >> If you'd like to review what it was before any manual auditing or >> before "authconfig" was run to tune your local environment, I urge >> you to do "rpm -q -f /etc/pam.d/sshd", get the original RPM that >> provided the original file, and take it apart with "rpm2cpio.sh >> filename | cpio -id" to see what the original file looked like, then >> compare it side-by-side for the results of editing. >> >