SFTP with nologin shell ?

Hi There,

I am trying to create a git user to access on its git /home only through sftp.

I didn't found useful info on the handbook therefore I followed this guide:


However I couldn't establish a connection...
  • User is part of a group called "sftp"
  • Public has been updated
  • sshd_config has been updated
  • sshd service restarted multiple time
Precisely:
Code:
 # id git
uid=1003(git) gid=1003(git) groups=1003(git),1004(sftp)

This is the only part that has been changed of my sshd_config:
Code:
# override default of no subsystems
Subsystem       sftp    /usr/libexec/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#       X11Forwarding no
#       AllowTcpForwarding no
#       PermitTTY no
#       ForceCommand cvs server
PermitRootLogin no
PasswordAuthentication no
#AuthenticationMethods publickey
AllowUsers freezr

# Change starts here
# sftp setup
Match Group sftp
ChrootDirectory /usr/home/%u/
ForceCommand internal-sftp

I also tried to modify this line:
Code:
AllowUsers freezr git

And I always got this error:
Code:
sftp git@vultrgit              23:46
Connection to 216.155.135.237 closed by remote host.
Connection closed

In this FreeNAS forum suggested to change nologin shell for scponly shell because:
Shell is set as /usr/local/bin/scponly
Initially I tried setting the shell as /usr/sbin/nologin, but this was just creating errors upon connection.

And it setup sshd_config this way:
Code:
freenas# nano /etc/ssh/sshd_config
[...]
#Subsystem       sftp    /usr/libexec/sftp-server
Subsystem       sftp    internal-sftp

Match Group sftponly
        ChrootDirectory /mnt/vol1/cloud-storage/chroot
        ForceCommand internal-sftp
        AllowTcpForwarding no
        X11Forwarding no

I haven't tested it yet, but I'll give this setup a try...
Meanwhile any help is really appreciated, thanks! ?
 
I used the second method but nothing has changed:

Code:
sftp git@vultrgit
[...]
debug1: Next authentication method: publickey
debug1: Offering public key: /home/freezr/.ssh/[...]explicit agent
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 60
debug1: Server accepts key: /home/freezr/.ssh/[...]explicit agent
debug3: sign_and_send_pubkey: using publickey-hostbound-v00@openssh.com with [...]
debug3: sign_and_send_pubkey: signing using ssh-ed25519 SHA256:[...]
debug3: send packet: type 50
debug3: receive packet: type 52
Authenticated to 111.222.333.444 ([111.222.333.444]:22) using "publickey".
debug2: fd 5 setting O_NONBLOCK
debug1: channel 0: new session [client-session] (inactive timeout: 0)
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug3: send packet: type 90
debug1: Requesting no-more-sessions@openssh.com
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: filesystem
debug3: client_repledge: enter
debug3: send packet: type 1
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
  #0 client-session (t3 [session] nr0 i0/0 o0/0 e[write]/0 fd 5/6/7 sock -1 cc -1 io 0x00/0x00)
Connection to 111.222.333.444 closed by remote host.
Transferred: sent 3380, received 2788 bytes, in 0.0 seconds
Bytes per second: sent 319618.3, received 263637.8
debug1: Exit status -1
Connection closed

It looks like the key is accepted but server is refusing the connection no matter what... ?‍♂️
 
I haven't tested it yet, but I'll give this setup a try...
I use this way many years, and it works for me.

Please check /var/log/auth.log for records like "bad ownership of chroot directory"

As far as I know, any directory of your chroot-path (/mnt/vol1/cloud-storage/chroot) should be owned by root.
 
Hello folks,

I am trying to implement a way to allow some users to upload files on my pet-server through sftp with a nologin however I am doing something wrong therefore the test is able to see and to go anywhere in the chroot environment.

The user is test and it belongs to the group sftp, below my directories:

Code:
ls -la /var/www/
drwxr-xr-x   5 root  wheel  512 Sep 30 01:36 pebcak.club/

and

Code:
ls -la /var/www/pebcak.club/
-rw-r--r--  1 root    wheel   4657 Jul 13 00:16 index.gmi
drwxr-xr-x  4 gabbia  gabbia   512 Aug  3 09:22 ~cage/
drwxr-xr-x  8 burnr   burnr    512 Jul 13 00:27 ~freezr/
drwxr-xr-x  2 test    sftp     512 Sep 30 03:11 ~test/

When I launch the sftp whether it is sftp test@host or sftp test@host:~test, such user can see and go anywhere:

Code:
sftp> ls
index.gmi  ~cage      ~freezr    ~test

While I expect that he can, at least, only its directory and anything else.

Here my sshd_config for that groups of users:

Code:
Match Group sftp
    AllowUsers test
     PasswordAuthentication yes
    ForceCommand internal-sftp
    X11Forwarding no
    AllowTcpForwarding no
    ChrootDirectory /var/www/pebcak.club/

What am I doing wrong?

Thanks?
 
It works for me for any FreeBSD.
I have chrooted users with nologin shell.

Try to setup chroot only for the user 'test'

Code:
Match User test
        ChrootDirectory %h
        AllowUsers test
        ForceCommand    internal-sftp
        X11Forwarding no
        AllowTcpForwarding no

Replace ' ChrootDirectory %h' by required directory, if chroot directory is not equal user's home directory.
Chroot directory should be owned by root, and should not be user-writable.

Check /var/log/auth.log in case of any issues related to ssh, sftp, sftp-chroot
 
I had the suspect that I have to change the permits of al the directories and files to 600...

EDIT:
GMID dev told me that isn't a good idea, this will prevent the server to read the through the directories... ?
 
ChrootDirectory /rootdirhere
ForceCommand internal-sftp -d %u

Should allow finegrained perms for user directories if that's whats required

/rootdirhere/username for example
 
I modified the Subsystem but the test user continues to land on the chroot directory instead of ~test... ?‍♂️

Code:
[...]
Subsystem    sftp    internal-sftp -d ~%u
[...]    
Match Group sftp
    AllowUsers test
     PasswordAuthentication yes
    ForceCommand internal-sftp
    X11Forwarding no
    AllowTcpForwarding no
    ChrootDirectory /var/www/pebcak.club/
 
Ok, I think I mostly solved it, although you can't prevent any users that go inside the server, with the sftp shell, to wandering around the folders, but they can't do anything inside of those.

Code:
[...]
Subsystem    sftp    internal-sftp
[...]
Match Group sftp
    AllowUsers test
     PasswordAuthentication yes
    ForceCommand internal-sftp -d /~%u 
    X11Forwarding no
    AllowTcpForwarding no
    ChrootDirectory /var/www/pebcak.club/
 
Back
Top