mirror of
https://github.com/s3fs-fuse/s3fs-fuse.git
synced 2026-04-24 21:06:02 +03:00
[GH-ISSUE #2775] Public Key Authentication ssh-rsa in .ssh/authorized_keys #1295
Labels
No labels
bug
bug
dataloss
duplicate
enhancement
feature request
help wanted
invalid
need info
performance
pull-request
question
question
testing
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/s3fs-fuse#1295
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @OrionMicrofocus on GitHub (Dec 17, 2025).
Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/2775
Additional Information
Version of s3fs being used (
s3fs --version)[ec2-user@ip-x-x-x-x ~]$ s3fs --version
Amazon Simple Storage Service File System V1.91 (commit:16bc449) with OpenSSL
Copyright (C) 2010 Randy Rizun rrizun@gmail.com
License GPL2: GNU GPL version 2 https://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
[ec2-user@ip-x-x-x-x ~]$
Version of fuse being used (
pkg-config --modversion fuse,rpm -qi fuseordpkg -s fuse)[ec2-user@ip-x-x-x-x ~]$ pkg-config --modversion fuse
2.9.4
[ec2-user@ip-x-x-x-x ~]$
Provider (
AWS,OVH,Hetzner,iDrive E2, ...)AWS
Kernel information (
uname -r)[ec2-user@ip-x-x-x-x ~]$ uname -r
4.14.355-196.643.amzn1.x86_64
[ec2-user@ip-x-x-x-x ~]$
GNU/Linux Distribution, if applicable (
cat /etc/os-release)[ec2-user@ip-x-x-x-x ~]$ cat /etc/os-release
NAME="Amazon Linux AMI"
VERSION="2018.03"
ID="amzn"
ID_LIKE="rhel fedora"
VERSION_ID="2018.03"
PRETTY_NAME="Amazon Linux AMI 2018.03"
ANSI_COLOR="0;33"
CPE_NAME="cpe:/o:amazon:linux:2018.03:ga"
HOME_URL="http://aws.amazon.com/amazon-linux-ami/"
SUPPORT_END="2023-12-31"
[ec2-user@ip-x-x-x-x ~]$
How to run s3fs, if applicable
I inherited the system and I haven't figured out yet how s3fs-fuze starts. I have not found it in crontab, systemd, or systemv. Still a bit of a mystery so checking ps is the best I've got.
[ec2-user@ip-x-x-x-x ~]$ ps aux | grep -i s3fs
root 2465 3.6 9.4 1265980 743576 ? Ssl Dec09 425:37 /usr/bin/s3fs my-bucket-name /sftp -o allow_other -o mp_umask=0022 -o iam_role=my-virginia-SftpStack-62MREDACTEDR1L-SftpAccessRole-X2UREDACTED4W7 -o stat_cache_expire=86400 -o list_object_max_keys=5000 -o use_cache=/s3fs-temp
ec2-user 20436 0.0 0.0 110624 2172 pts/0 S+ 15:34 0:00 grep --color=auto -i s3fs
[ec2-user@ip-x-x-x-x ~]$
s3fs syslog messages (
grep s3fs /var/log/syslog,journalctl | grep s3fs, ors3fs outputs)[root@ip-x-x-x-x ~]# grep s3fs /var/log/syslog
grep: /var/log/syslog: No such file or directory
[root@ip-x-x-x-x ~]# journalctl | grep s3fs
-bash: journalctl: command not found
[root@ip-x-x-x-x ~]# s3fs outputs
s3fs: could not determine how to establish security credentials.
[root@ip-x-x-x-x ~]#
Details about issue
I've got an installation of s3fs-fuze that is configured so the user directories are under the /sftp/ directory.
I have a user configured that is able to connect with username & password. The username and user directory are different.
This user would like to use public key authentication instead, so they provided me with the ssh-rsa which I put in their /sftp/User_Directory/.ssh/authorized_keys file.
I set the permissions as follows.
[root@ip-x-x-x-x ~]# mkdir /sftp/User_Directory/.ssh
[root@ip-x-x-x-x ~]# chown username:sftpusers /sftp/User_Directory/.ssh
[root@ip-x-x-x-x ~]# chmod 700 /sftp/User_Directory/.ssh
[root@ip-x-x-x-x ~]# ls -la /sftp/User_Directory/
total 2
drwxr-xr-x 1 root root 0 Dec 15 14:01 .
drwxr-xr-x 1 root root 0 Jul 9 13:46 ..
drwxr-xr-x 1 username sftpusers 0 Apr 27 2015 data
drwx------ 1 username sftpusers 0 Dec 15 14:26 .ssh
[root@ip-x-x-x-x ~]# touch /sftp/User_Directory/.ssh/authorized_keys
[root@ip-x-x-x-x ~]# chown username:sftpusers /sftp/User_Directory/.ssh/authorized_keys
[root@ip-x-x-x-x ~]# chmod 600 /sftp/User_Directory/.ssh/authorized_keys
[root@ip-x-x-x-x ~]# ls -la /sftp/User_Directory/.ssh/
total 2
drwx------ 1 username sftpusers 0 Dec 15 14:26 .
drwxr-xr-x 1 root root 0 Dec 15 14:01 ..
-rw------- 1 username sftpusers 0 Dec 15 14:29 authorized_keys
[root@ip-x-x-x-x ~]# vi /sftp/User_Directory/.ssh/authorized_keys
[root@ip-x-x-x-x ~]# cat /sftp/User_Directory/.ssh/authorized_keys
ssh-rsa AAAAB3NzaC1y...REDACTE...3UWljfOHus8cU= emailname@someplace.wherever.com
[root@ip-x-x-x-x ~]#
We tested this and it did not work. Logs from the client side:
user@server .ssh]$ sftp -vvv username@ip.add.res.s
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /client/pub/key/.ssh/mft_rsa/id_rsa RSA SHA256:3N3...REDACTED...TaQ explicit
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
user@server's password:
I checked the /var/log/secure on the s3fs-fuze server and I found these, but the timestamps are about 20 minutes after the test was performed.
Dec 16 14:12:53 ip-x-x-x-x sshd[641]: Authentication refused: bad ownership or modes for file /sftp/User_Directory/.ssh/authorized_keys
Dec 16 14:13:09 ip-x-x-x-x sshd[733]: Authentication refused: bad ownership or modes for file /sftp/User_Directory/.ssh/authorized_keys
Dec 16 14:17:10 ip-x-x-x-x sshd[3028]: Authentication refused: bad ownership or modes for file /sftp/User_Directory/.ssh/authorized_keys
Dec 16 14:24:30 ip-x-x-x-x sshd[6327]: Authentication refused: bad ownership or modes for file /sftp/User_Directory/.ssh/authorized_keys
I rechecked and found that the permissions had changed.
[root@ip-x-x-x-x ~]# ls -la /sftp/User_Directory/.ssh/authorized_keys
-rw-rw-rw- 1 username sftpusers 1189 Dec 15 15:56 /sftp/User_Directory/.ssh/authorized_keys
[root@ip-x-x-x-x ~]#
We retested again and the connection still did not work. The user is still able to connect with username & password.
Is publickey authentication possible using s3fs-fuze? What are we doing wrong?
@OrionMicrofocus commented on GitHub (Dec 17, 2025):
Update: I got on a live call with this user and if I perform the chmod 600 and then they immediately try connecting it works.
[root@ip-x-x-x-x ~]# chmod 600 /sftp/User_Directory/.ssh/authorized_keys
[root@ip-x-x-x-x ~]# ls -la /sftp/User_Directory/.ssh/authorized_keys
-rw------- 1 username sftpusers 595 Dec 17 19:33 /sftp/User_Directory/.ssh/authorized_keys
[root@ip-x-x-x-x ~]
Dec 17 19:36:34 ip-x-x-x-x sshd[28580]: Accepted publickey for username from z.z.z.z port 41680 ssh2: RSA SHA256:3N3n035...REDACTED...eYYTaQ
Dec 17 19:36:34 ip-x-x-x-x sshd[28580]: pam_unix(sshd:session): session opened for user username by (uid=0)
Unfortunately 15 minutes later some automated process sets the permissions back and it stops working again.
Dec 17 19:50:17 ip-x-x-x-x sshd[4288]: Authentication refused: bad ownership or modes for file /sftp/User_Directory/.ssh/authorized_keys
[root@ip-x-x-x-x ~]# ls -la /sftp/User_Directory/.ssh/authorized_keys
-rw-rw-rw- 1 username sftpusers 595 Dec 17 19:33 /sftp/User_Directory/.ssh/authorized_keys
[root@ip-x-x-x-x ~]#
I assume the s3fs-fuze utility is the process that is changing this permission but I'm not sure if there's some way to prove that.