Mailing List Archive: Bug/RFE - Reacting to system specifying expired password when chrooting

I'm not sure if this would be consider a bug or an RFE, but I definitely
think it needs attention based on the searching I've done.

The scenario I have is this:

User is set up with /sbin/nologin as the shell
User is in a group specifying SFTP-only access, and is chrooted
SSH is configured to use PAM
Upon valid username/password entry, PAM is reporting back password
change is required (debug3: sshpam_password_change_required 1)
Result: User is unable to change password as system reports "passwd not
found"

I've seen multiple pages suggesting how to copy in all the files need to
allow certain commands to be run in a chrooted shell, and one page
mentioning to "mount" the /etc/passwd and /etc/shadow files into the
chrooted directory, but that sort of thing doesn't seem like it would
scale well.

Unfortunately I don't relay know coding well, not at this level, what
I'm thinking is it should be possible to change the order of things such
that, if PAM returns that password change required flag, the login
process could initiate the password change process *before* going into
the chroot environment for the user. Since the system disconnects the
session after the attempt to change the password completes (whether the
change is successful or not), this shouldn't be a security risk.

Here is my /etc/ssh/sshd_config file:
Port 22
Protocol 2
ListenAddress 0.0.0.0
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
SyslogFacility AUTH
Ciphers aes128-ctr,aes192-ctr,aes256-ctr
LoginGraceTime 90
PermitRootLogin yes
StrictModes yes
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile      .ssh/authorized_keys2
IgnoreRhosts yes
RhostsRSAAuthentication no
HostbasedAuthentication no
IgnoreUserKnownHosts no
PermitEmptyPasswords no
PasswordAuthentication yes
ChallengeResponseAuthentication no
UsePAM yes
X11Forwarding no
PrintLastLog yes
KeepAlive yes
UseLogin no
MaxStartups 10
Banner /etc/issue.net
UseDNS no
GSSAPIAuthentication no
GSSAPICleanupCredentials yes
ClientAliveInterval 300
ClientAliveInterval 0
Subsystem       sftp    internal-sftp -l VERBOSE
Match Group sftpusers
        ChrootDirectory %h
        ForceCommand internal-sftp -l VERBOSE
        X11Forwarding no

Thanks in advance for any feedback on this,
Rick
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Rick Greene wrote:
> User is set up with /sbin/nologin as the shell
..
> what I'm thinking is it should be possible to change the order of things
> such that, if PAM returns that password change required flag, the login
> process could initiate the password change process *before* going into
> the chroot environment for the user.

It looks like that would work, since the passwd command to change the
password is executed directly by sshd, without using the user's shell.

You could try the untested patch I've attached if you like.

But there may still be concerns about so much processing going on before
the configured chroot takes effect. I would have to think long about
such a change before I'd enable it on my systems.

//Peter

Mailing List Archive

Mailing List Archive

Attached Files: