piCore 14.x sftp not working after update from 13.x?

[Cheembus]

Hello all,

I recently updated my 13.x piCore on my raspi 3 model B to version 14, and updated all the required extensions. Previously when it was version 13 I had an SFTP server running on it that I used semi-frequently. As of updating to version 14, I can't seem to log in to the piCore through sftp and access the server. Every time I try to log in, it asks for my user password, and when I enter it in correctly I immediately get booted out with the error message:

Code: [Select]

sftp www-data@raspivpn
www-data@raspivpn's password:
Connection to raspivpn closed by remote host.
Connection closed. 
Connection closed

All my other ssh capabilities are functioning correctly, I can ssh into my tc user, do scp, rsync, etc.
I know that this type of error is usually caused by directory permissions problems, but to my knowledge I have all the directories with the correct permissions.

The following is an excerpt from my sshd_config, and the permissions of my directories:

Code: [Select]


Subsystem       sftp    /usr/local/lib/openssh/sftp-server

# sftp stuff
Match User www-data
        ChrootDirectory /mnt/www
        ForceCommand internal-sftp
        PasswordAuthentication yes
        AllowTcpForwarding no
        X11Forwarding no
        ClientAliveInterval 60



Code: [Select]

drwxr-xr-x  10 root root   200 Apr  2 15:34 mnt/
drwxr-xr-x 7 root root  140 Apr  2 15:34 www/


I've been scratching my head over this for the last 2 days. What am I doing wrong here?

[patrikg]

Can you check if the file are there:

Code: [Select]

ls -l /usr/local/lib/openssh/sftp-server

Or maybe on another path.

[Cheembus]

Can you check if the file are there:

Code: [Select]

ls -l /usr/local/lib/openssh/sftp-server

Or maybe on another path.

Code: [Select]

lrwxrwxrwx 1 root root 53 Jan  1  1970 /usr/local/lib/openssh/sftp-server -> /tmp/tcloop/openssh/usr/local/lib/openssh/sftp-server

Yes, I can confirm it is there.

[patrikg]

When debugging ssh the option -v is your friend.
So you can try to add that to your scp command like this, to get more info what the ssh doing.

Code: [Select]

scp -v tc@localhost:/home/tc/myfile myfile
And you could try to use the tc user.
And do you have www-data as user ?
And what I am seeing is the owner of the directory is root.

So you have lots of user errors.

[Cheembus]

And do you have www-data as user ?

ssh to the user tc gives no problems, its the user www-data that is causing problems. www-data does in fact exist as a user, I can see it in my passwd and shadow files. I can also attempt to login as www-data via the tty terminal (it kicks me out immediately because I have the shell set to /bin/false on purpose). For the record, if I intentionally type in the wrong password when trying to sftp or ssh as the user www-data, it tells me explicitly that the password is incorrect, so it is able to verify the login, it just unexpectedly drops.

Doing either -vvv on ssh or sftp for www-data@raspi results in a vague error:

Code: [Select]

Authenticated to raspivpn ([X.X.X.X]:22) using "password".
debug1: channel 0: new [client-session]
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: 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 nr0 i0/0 o0/0 e[write]/0 fd 4/5/6 sock -1 cc -1 io 0x00/0x00)

Connection to raspivpn closed by remote host.
Transferred: sent 2980, received 2516 bytes, in 0.0 seconds
Bytes per second: sent 159785.5, received 134906.1
debug1: Exit status -1
Connection closed. 
Connection closed



[Cheembus]

As for user permissions (ownership of root:root), to my best of knowledge the chroot directory is supposed to be root-owned, and any folder or file inside can be user-owned.

I'd rather not use user tc as sftp user, as it's a sudoer and I prefer low-permission users to be used for external connections, for security reasons.


Edit: I can confirm doing

Code: [Select]

sftp tc@raspivpn actually drops me into my /home/tc/ home directory.

now, as to why www-data can't do the same, is whats confusing me.

[patrikg]

Great, now success of knowing little more about what the problem maybe is.
You could also try to get the sshd running config. So you can see that it's corresponding to what you think of. Is it the same as you running before the picore update.

Code: [Select]

sudo sshd -T
And you should try to get rid of some lines of it, first so you could connect and get it working.
Don't take to many steps at time.
After it's working then you can hardening your system, with all things you think of, like not using passwords for authentication and so on.

[Cheembus]

I made a temporary "home" directory for www-data located:

Code: [Select]

drwxr-s---  2 www-data staff 4.0K Apr  2 18:33 /home/www-data/

and when I remove the line "ChrootDirectory /mnt/www" from the sshd_config, I then get dropped into this home directory (/etc/passwd has /home/www-data as the home directory for the user www-data)

weirdly enough, if I set the /mnt/www directory to have the exact same ownership and permissions, I still get kicked immediately. What exactly do I have wrong with the ChrootDirectory settings? do I need to specify something else in my sshd config? Maybe I actually have to specify this as my new home directory in the passwd file, for this new version of sftp?

Is it the same as you running before the picore update.

It's about 99% the same, the only major difference I see is the "Subsystem  sftp" section was changed to /usr/local/lib/openssh/sftp-server. I believe it was "internal-sftp" originally.

[Rich]

Hi Cheembus
Welcome to the forum.

Just a few thoughts.

Run this and make sure the home directory listed exists and is accessible:

Code: [Select]

cat /etc/passwd | grep www-data
Add the  syslog  boot code to your Pi and reboot it. Check
/var/log/messages  after a failed login to see if it provides
any more clues.

Check these links for a couple of other ideas:
https://serverfault.com/a/890751
https://serverfault.com/a/1001818

[Cheembus]

Hi Cheembus
Welcome to the forum.

Just a few thoughts.

Run this and make sure the home directory listed exists and is accessible:

Code: [Select]

cat /etc/passwd | grep www-data

www-data:x:1003:1003:Linux User,,,:/home/www-data:/bin/false is the output of that command.

I'll try the syslog in a bit and report back in a few minutes.

[Cheembus]

www-data:x:1003:1003:Linux User,,,:/home/www-data:/bin/false is the output of that command.

I'll try the syslog in a bit and report back in a few minutes.

Code: [Select]

Apr  2 20:20:32 box auth.info sshd[3779]: Accepted password for www-data from X.X.X.X port 55238 ssh2
Apr  2 20:20:32 box auth.crit sshd[3781]: fatal: bad ownership or modes for chroot directory component "/"

hmmmmm....


right now, /mnt/www is owned by www-data:www-data and perms are drwxr-xr-x

[patrikg]

ChrootDirectory settings? do I need to specify something else in my sshd config? Maybe I actually have to specify this as my new home directory in the passwd file, for this new version of sftp?

Can you see with sudo sshd -T that your settings take effect.

[Cheembus]

chrootdirectory none is the only reference to the chrootdirectory, only I would assume this is for global users, and I wouldn't think it would show up for Matching Users.

[Rich]

Hi Cheembus
Read this:
https://takahisa.info/2010/03/18/sftp-chroot-with-openssh-error-fatal-bad-ownership-or-modes-for-chroot-directory/

My guess is  /mnt  has extra write permissions.

[Cheembus]

I decided to simplify my configuration and just created a temporary /dump directory located at / with ownership root:root and 700 permissions.
I set my sshd config to contain as such:

Code: [Select]

Match User www-data
        ChrootDirectory /dump
        ForceCommand internal-sftp
        PasswordAuthentication yes
        AllowTcpForwarding no
        X11Forwarding no
        ClientAliveInterval 60



It follows the requirements of the link you posted, but still refuses to connect, for the same "fatal: bad ownership or modes for chroot directory component "/" " error.

Seems no matter what I do, it will always refuse any non-home directory as chroot.