Tag Archives: sshd

Linux configuration SFTP server

Add user group 

groupadd sftp

Add users and set to SFTP group 

sudo useradd -g sftp -s /sbin/nologin -M sftp

Modify the SFTP user’s password 

sudo passwd sftp

***********

Create the root directory of the SFTP user and set the owner and group, modify the permissions (755) 

cd /home
sudo mkdir sftp

sudo chown root:sftp sftp

sudo chmod 755 sftp

Create admin writable directory
in the directory of SFTP

cd sftp
sudo mkdir report

sudo chown admin:sftp report/

Modify the configuration file 

sudo vim /etc/ssh/sshd_config

Modify the

#Subsystem      sftp    /usr/libexec/openssh/sftp-server
Subsystem       sftp    internal-sftp

Add at the end of the sshd_config file

Match User sftp
        X11Forwarding no
        AllowTcpForwarding no
        ForceCommand internal-sftp
        ChrootDirectory /home/sftp

Restart the SSHD service 

sudo service sshd restart

ftp client:

address : 192.168.1.10

user: sftp

password: xxxxxxx

protocol type : SSH2

port: 22

server folder: /home/sftp

pls use CuteFTP Pro® 8.3.3 or last version.

because CuteFTP Pro® 8.3.2 or earlier has no AES128 and AES256 ciphers.

will raise throw “SFTP21 error = #4” .

SSHD key_read error report solution

The status quo described
In the afternoon, I found that the connection between my Xshell and the server node was inexplicably broken. After checking the system log, I found a large number of following errors:

May 15 17:58:08 yanta sshd[15213]： error：key_read: uudecode AAAAB3NzaC1yc2...........

The solution
After querying the solution on the network, it is found that the IP in error and the string in the corresponding error message can be found in the file /root/.ssh/known_hosts, and it is ok to delete it
. However, after checking the information on the server again, it is found that there is no corresponding one, and the encoded string is completely different.
After looking at /root/.ssh/authorized_keys, I find that one of the keys is consistent with the error message, so I first backup the file:

# cp authorized_keys authorized_keys.bk

After careful examination of the key, it was found that a complete key was originally divided into several parts, leading to the incomplete key when SSH login, so there was no error message after re-copying and pasting the key information on this machine.