I recently logged in via sftp to change some files I get “permission denied” so I log into my vps to see why and all my files are now root:root ??? What happened, why would it change?
Using winscp and debian10
How did you login? What exactly did you changed? There is no reason to set root:root as permission, if you dont have logged yourself in with root. This is a sftp feature, which hasnt a direct relation to hestia - we just provide the configured parts.
I only longed in via user, not admin or root. But even if I did login with root and change certain files it would only change those files, not everything.
How can I change this back?
Please provide step by step informations and what you’re doing. It sounds not like a hestia issue
I can only upload one image. How to do I put my user back in place of all these files?? It will take to long to go 1 by 1.
$: /home/dssn
drwxr-xr-x+ 11 root root 4096 Aug 4 21:54 .
drwxr-xr-x 5 root root 4096 Aug 5 05:54 …
-rw-r–r-- 1 root root 23 Aug 4 21:54 .bash_aliases
-rw-r–r-- 1 dssn dssn 220 Apr 18 2019 .bash_logout
-rw-r–r-- 1 dssn dssn 3526 Apr 18 2019 .bashrc
drwxr-xr-x 2 dssn dssn 4096 Aug 4 21:41 .cache
drwxr-xr-x 2 dssn dssn 4096 Aug 4 21:41 .composer
drwxr-xr-x 5 root root 4096 Aug 4 21:41 conf
drwxr-xr-x 2 dssn dssn 4096 Aug 4 21:41 .config
drwxr-xr-x 2 dssn dssn 4096 Aug 4 21:41 .local
drwxr-x–x 3 root root 4096 Aug 4 21:55 mail
-rw-r–r-- 1 dssn dssn 807 Apr 18 2019 .profile
drwxr-xr-x 2 dssn dssn 4096 Aug 13 06:16 .ssh
drwxrwx–x 2 dssn dssn 4096 Aug 14 19:54 tmp
drwxr-x–x 6 dssn dssn 4096 Aug 12 02:49 web
when I go to /home/dssn/web
drwxr-xr-x+ 11 root root 4096 Aug 4 21:54 …
dr-xr-x–x 9 dssn dssn 4096 Aug 12 05:54 domain.tld
Next in /home/dssn/web/domain
drwxr-x–x 9 dssn www-data 4096 Aug 6 08:20 public_html
/home/dssn/web/domain/public_html
Everything is owned by root, it has to be hestia because I do not use root I do everything from the control panel, ports/firewall, only upload and download I use sftp.
how did you uploaded the files? how to use a easy chown user:user * -R inside the public_html directory to fix your issue?
1 Like
Can you post /etc/ssh/sshd_config? in case you are using sftp and not ftp
What shell is enabled for dssn user?
grep dssn /etc/passwd
chown user:user * -R inside the public_html directory to fix your issue?
Thank you!
dssn = hestiacp user name
ds = regular user on debian
ds@cp:~$ grep dssn /etc/passwd
root:x:0:0:root:/root:/bin/bash
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
systemd-timesync:x:101:102:systemd Time Synchronization,,,:/run/systemd:/usr/sbin/nologin
dssn:x:1001:1001:email_gmail.com:/home/dssn:/sbin/nologin
#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
# Ciphers and keying
#RekeyLimit default none
# Logging
#SyslogFacility AUTH
#LogLevel INFO
# Authentication:
#LoginGraceTime 1m
PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10
#PubkeyAuthentication yes
# Expect .ssh/authorized_keys2 to be disregarded by default in future.
#AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2
#AuthorizedPrincipalsFile none
#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody
# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes
# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication yes
#PermitEmptyPasswords no
# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no
# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no
# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no
# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication. Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes
#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
PrintMotd no
#PrintLastLog yes
#TCPKeepAlive yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none
# no default banner path
#Banner none
# Allow client to pass locale environment variables
AcceptEnv LANG LC_*
# override default of no subsystems
Subsystem sftp internal-sftp
# Example of overriding settings on a per-user basis
#Match User anoncvs
# X11Forwarding no
# AllowTcpForwarding no
# PermitTTY no
# ForceCommand cvs server
DebianBanner no
# Hestia SFTP Chroot
Match User sftp_dummy99,admin,dssn
ChrootDirectory %h
X11Forwarding no
AllowTCPForwarding no
Are the accounts chrooted?
Edit*
conf folder is still root, it won’t let me change it to dssn.
/home/dssn
drwxr-xr-x 5 root root 4096 Aug 4 21:41 conf
chown: changing ownership of ‘conf’: Operation not permitted
hestia users, yes. manualy created system users, no.
this is correct, a user should not change anything inside of conf, the permission belongs to root. Only touch the confs when you’re 100% sure about what you’re doing!