This service allows sftp connections only. Connection to 10.0.0.130 closed. Here are the changes I made to sshdconfig: Subsystem sftp internal-sftp -f AUTH -1 VERBOSE AllowGroups sftpusers sftp sshusers Match Group sftpusers ChrootDirectory%h AllowTCPForwarding yes ForceCommand internal-sftp X11Forwarding no. In this short video I will walk you though the steps of SFTP services installation on Server 2019, Major steps are below 1. Add OpenSSH Server feature2. SFTP (Secure File Transfer Protocol, Secure FTP or SSH FTP) is the extension of SSH protocol, being a standard in the world of UNIX/Linux systems. From the user point of view, it is similar to FTP, but in fact, it is a completely different protocol, having nothing in common with FTP. An SSH server is a software program which uses the secure shell protocol to accept connections from remote computers. SFTP/SCP file transfers and remote terminal connections are popular use cases for an SSH server. Here you can download the latest version of freeSSHd and freeFTPd. Please have in mind that you must have administrator privileges to install both.

As vulnerability was reported from here, new version 1.0.12. of freeFTPd was released to secure the SFTP protocol. I suggest immediate update of your servers.

I have put both freeSSHd and freeFTPd on the same web so it's easier to maintain. Forums are migrated, downloads too, etc..

I have put version 1.2.2 with exploit fixes (and few other small things) online for you to try.
Comments welcome, but please do not expect fast answers.

Changelog:

• 'freeSSHd NULL Pointer Crash' bug fixed
• systray icon is visible only to users with administrator rights
• port forwarding is more stable
• added logging for SFTP transfers
• 'access denied' bug is hopefully part of the past
• and many other little fixes...

Version 1.3.0 will be out soon with more of the requested features, this one was released to address the security issues that emerged recently.

There's a new version of freeSSHd online (1.2.0) and it comes with a cool feature you've all been waiting for: 'graphical' application support. See picture below to better understand what I mean. Here's a list of changes:

• new console handling code - supports 'edit'-like apps, ANSI colors, etc.
• fix in remote port forwarding that closed listening socket after first connection
• automatic update support

There are different ways to lock a user into his home directory. A very special case is to grant sftp-only access, which does not require a full chroot jail to be set up. The sftp subsystem built into openssh allows a simple setup of a user locked into his home directory.

Configure OpenSSH

There are two ways to configure OpenSSH. Individual users can be configured in openssh or (my preferred solution) a group can be created and configured in OpenSSH. This group can then be assigned to the users who should be restricted to sftp only. Edit the /etc/ssh/sshd_config file and include the following section at the end of the file.

The above configuration section (the “Match” block) must be the last configuration item in the config file. Any configuration following a Match block overrides the general settings when the Match conditions are met. In the above example, the two configuration items are only used when the user is part of the “sftponly” user group. The “ChrootDirectory” locks the user into the directory specified as argument. The “%h” represents the user’s home directory, allowing the match pattern to lock each user into his own home directory. The “ForceCommand” ensures that the user cannot trigger any other command, but only enter the “internal-sftp” subsystem.

It is also necessary to configure the sftp subsystem to use “internal-sftp”. Also in the /etc/ssh/sshd_config ensure the following configuration is set. Otherwise the external sftp-server will be used, which can not be found inside the chroot jail of the user.

The configured group needs to exist on the system to assign it to the sftp users. The following command will create this group.

Finally the ssh daemon needs to be restarted to load the new configuration.

Further restricting the account

To ensure the sftp only user is only allowed to use sftp, additional restrictions can be added to the match block.

Some of the most common restrictions are shown in the example above.

AllowTcpForwarding – Deny TCP forwarding which can be used to forward certain ports
PasswordAuthentication – Disable password authentication. The user can only authenticate with any remaining methods, like ssh-keys.
X11Forwarding – Deny X11 forwarding to protect any X11 interaction to the server.

Choose the settings for further restriction of the account based on your needs. In some cases, disabling Password authentication might be required to be disabled.

Preparing the Account

A new sftp only account can now be created and prepared. As described above, the user needs to be assigned to the group used in the Match block.

The “-G” option adds “sftponly” as a supplementary group to the user “user1”. With the “-s” option, the user gets “/sbin/nologin” as shell which denies interactive shell access for the user. This command will automatically (if not instructed otherwise with additional arguments) create a home directory for the user. The permissions of the home directory need to be modified for the chroot jail to work.

The user “root” needs to be set as the owner of the home directory. The group should remain the primary group of the user as the user needs to access the directory. The permission set with the following command should ensure the user “user1” can access the home directory.

Do not set the group’s write permission as it will be checked by ssh during login. The ssh daemon will refuse login attempts with the following error if the write permission is granted.

The permission can either be granted by just adding the read and execute permission to the group as shown in the above command or numerically as “0750” setting implicit permission for user, group and other.

Limitations of this setup

This specific setup has one drawback caused by the fact that the user’s home directory owner is root. The user itself has no write permission to his home directory. So the user can not create new directories or files directly directly in the home directory. Above, the owner of the home directory was set to root to allow the chroot jail to work. That change prevents the user from writing directly into the home directory. Granting the user’s group write permission to the home directory will not be possible.

Sshd Sftp

To allow the user to upload content via sftp, a subdirectory should be created for this purpose. The created directory’s owner will be the user, allowing him to manage files and directories within the subdirectory freely.

The above example creates a directory called “data” in the user’s home directory and changes the owner of it to the user. Now the user can manage data inside this directory. In some web-hosting scenarios the directory is named “public_html”. This allows the user to upload web-content while still being locked into his home directory.

Authorized keys

To be able to configure an authorized key for the user, the “.ssh” directory must be created and changed to the correct owner and permission.

Ssh Sftp

With the .ssh directory prepared and owned by the user, the user can upload his key already by himself as needed. For more details about adding a key, see SSH passwordless login with SSH-key.

Test the configuration

To test the configuration, connect with the sftp command line client as shown below.

Depending on the configuration, you will either see the prompt “sftp>” or, if no ssh-key was yet added, you will be prompted for the password of the user.

Verify that the user is locked inside the home directory by checking the current working directory (command: “pwd”) and the directory content (command: “ls”). The users home directory should be represented by “/” indicating the root directory in which the user is locked in.

Should there be any issues with the connection or the acceptance of the ssh-key, the sftp client allows to pass ssh options using the “-o” option.

The above example will try to connect to the server with the ssh log level set to debug. This will provide more details about problems from the client’s perspective.

On the server the log files will provide information about what went wrong. On RedHat based distributions, the related log is “/var/log/secure”. Even the ssh daemon on the server supports the “LogLevel” setting in the /etc/ssh/sshd_config file.

Read more of my posts on my blog at https://blog.tinned-software.net/.