Tiny Core Linux
Tiny Core Base => Raspberry Pi => Topic started by: Cheembus on April 02, 2024, 12:02:59 PM
-
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:
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:
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
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?
-
Can you check if the file are there:
ls -l /usr/local/lib/openssh/sftp-server
Or maybe on another path.
-
Can you check if the file are there:
ls -l /usr/local/lib/openssh/sftp-server
Or maybe on another path.
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.
-
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.
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.
-
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:
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
-
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 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.
-
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.
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.
-
I made a temporary "home" directory for www-data located:
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.
-
Hi Cheembus
Welcome to the forum.
Just a few thoughts.
Run this and make sure the home directory listed exists and is accessible:
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
-
Hi Cheembus
Welcome to the forum.
Just a few thoughts.
Run this and make sure the home directory listed exists and is accessible:
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.
-
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.
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
-
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.
-
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.
-
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.
-
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:
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.
-
Hi Cheembus
It doesn't appear to be flagging /mnt/www or /dump.
It looks like the culprit might be "/" (the root itself".
I found something interesting:
On my TC10 x86 machine, "/" is owned by root:root
On my TC14 x86_64 machine, "/" is owned by tc:staff
I booted up TC13 x86_64, and "/" is owned by root:root
Install coreutils.tcz and use stat to check "/" like this example:
tc@E310:~$ stat /
File: /
Size: 380 Blocks: 0 IO Block: 4096 directory
Device: 2h/2d Inode: 2 Links: 17
Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2024-04-02 17:20:45.649458451 +0000
Modify: 2019-06-09 12:30:02.000000000 +0000
Change: 2024-02-11 22:00:36.450000002 +0000
Birth: -It shows permissions set at 755 and owner set as root:root
If your permissions and/or owners are wrong:
sudo chown root:root /
sudo chmod 755 /Then try connecting again.
-
Hi Cheembus
Turns out you don't need coreutils.tcz.
You can use the ls command:
tc@E310:~$ ls -ld /
drwxr-xr-x 17 root root 380 Jun 9 2019 //
-
oooooooohhhhh myyyyy goodness
tc@box:~$ ls -ld /
drwxrwxr-x 17 root root 380 Jan 1 1970 //
Changing the perms to 755 to / allowed me to connect to /mnt/www like I intended!
Now the next question is, why exactly the root path is 775 instead of 755 unlike the other OS versions, is there a way to permanently set the perms to 755, and if not, is there any harm in setting the perms to 755 in my bootsync.sh?
-
Hi Cheembus
... Now the next question is, why exactly the root path is 775 instead of 755 ...
It was probably 755 in piCore 13.x and inadvertently changed to 775 in 14.x.
... is there a way to permanently set the perms to 755, and if not, is there any harm in setting the perms to 755 in my bootsync.sh?
To permanently change it you would need to unpack/modify/repack the
image file. I recommend adding the change to bootsync.sh.
-
neato.
It looks like we found the cause and solution to my problem.
Thanks for all the help, everyone.
-
Just checked a 13.x system and its 775 too, so likely openssh is just more stringent. The initramfs is created by the rasperrypi firmware, I don't think the initrd file can change that.
-
That problem was deep as it can, to root(/). :)
Thanks for finding that.