0

I use the following configuration and it worked successfully for restricting the ssh user to a particular folder but when I change the permission of the group to read+write, the user can't login to the server

In /etc/passwd I changed

/bin/bash of user to /bin/false

In /etc/ssh/sshd_config I added

Subsystem sftp internal-sftp
    Match Group dnduser
    ChrootDirectory /home/dnduser
    ForceCommand internal-sftp
    AllowAgentForwarding no
    AllowTcpForwarding no
    X11Forwarding no

Working /home/dnduser directory permissions without write permission

#chmod 755 /home/dnduser -R

#chown root:dnduser /home/dnduser -R

When I change the permission to

#chmod 775 /home/dnduser -R

the user can't login

Anthon
  • 79,293
Vinayak
  • 121
  • Have you looked at the permissions in ~/.ssh on the remote machine? ssh enforces some basic things like "private keys must not be readable to anybody but the user", I wouldn't be surprised by "authorized_keys must not be writeable by anybody but the user". – Ulrich Schwarz Sep 08 '16 at 05:03
  • Im not using any keys. its password based and only allows sftp connections – Vinayak Sep 08 '16 at 05:06

2 Answers2

1

Recursive chmod'ing is dangerous and should be avoided as you are changing the mode on directories and files to be the same; files generally do not need the execute bit, and as Ulrich pointed out that some files in $HOME must not be group or other readable/writeable.

To repair the damage:

find /home/dnduser -type f -exec chmod 640 {} \;
find /home/dnduser -type d -exec chmod 750 {} \;

From man sshd_config the second sentence is of most relevance:

 ChrootDirectory
         Specifies the pathname of a directory to chroot(2) to after authentication.  At session startup sshd(8) checks that all components of the
         pathname are root-owned directories which are not writable by any other user or group.  After the chroot, sshd(8) changes the working direc‐
         tory to the user's home directory.  Arguments to ChrootDirectory accept the tokens described in the TOKENS section.

To aid with debugging, you can run ssh in super verbose mode with "ssh -vvv" and on the server side, for RH based systems, view the log output of /var/log/secure and /var/log/messages. You should get pointers of where to investigate next from the server log output, but I feel that the man page points to the... root.. of your problem.

Phil
  • 11
0

From manual page to sshd_config:

At session startup sshd(8) checks that all components of the pathname are root-owned directories which are not writable by any other user or group.

If you want to chroot the user to specific directory, then he can write only to the subdirectories. Period.

Jakuje
  • 21,357