aleteo.co

1. Ssh Key Setup
2. Linux Sftp Use Ssh Key

If the private SSH key already exists, this can be done from within FileZilla, without the need to install extra software. Simply go to menu Edit → Settings → Connection → FTP → SFTP. Click button Add key file and add your private key there. It will convert the key for you.

• A better way of carrying out server authentication when using SSH/SFTP is by inspecting the public key fingerprint. A fingerprint in this context is basically a hash function of a public key. Simply put, it's a shorter equivalent of the public key.
• Login SFTP SSH key based authentication To verify that everything went well, ssh again to your SFTP server. This time, you'll be asked to enter the passphrase instead of the password. Navigate to your.ssh directory and view the contents of the authorizedkeys file.

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.

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.

Ssh Key Setup

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.

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/.

In every SSH/SFTP connection there are four keys (or two key-pairs) involved. This article explains a difference between them and what keys an SFTP client user needs to care about.

The SSH employs a public key cryptography. A public-key cryptography, also known as asymmetric cryptography, is a class of cryptographic algorithms which requires two separate keys, one of which is secret (or private) and one of which is public.1 Together they are known as a key-pair. In SSH, the public key cryptography is used in both directions (client to server and server to client), so two key pairs are used. One key pair is known as a host (server) key, the other as a user (client) key.

A user private key is key that is kept secret by the SSH user on his/her client machine. The user must never reveal the private key to anyone, including the server (server administrator), not to compromise his/her identity.

To protect the private key, it should be generated locally on a user’s machine (e.g. using PuTTYgen) and stored encrypted by a passphrase. The passphrase should be long enough (that’s why it’s called passphrase, not password) to withstand a brute-force attack for a reasonably long time, in case an attacker obtains the private key file.

Different file formats are used to store private keys. WinSCP supports PuTTY format, with .ppk extension.

A user public key is a counterpart to user private key. They are generated at the same time. The user public key can be safely revealed to anyone, without compromising user identity.

To allow authorization of the user on a server, the user public key is registered on the server. In the most widespread SSH server implementation, the OpenSSH, file ~/.ssh/authorized_keys is used for that.

Learn more about public key authentication in general and how to setup authentication with public keys.

Advertisement

A host private key is generated when the SSH server is set up. It is safely stored in a location that should be accessible by a server administrator only. The user connecting to the SSH server does not need to care about host private key in general.

A host public key is a counterpart to host private key. They are generated at the same time. The host public key can be safely revealed to anyone, without compromising host identity.

To allow authorizing the host to the user, the user should be provided with host public key in advance, before connecting. The client application typically prompts the user with host public key on the first connection to allow the user to verify/authorize the key. The host public key is then saved and verified automatically on further connections. The client application warns the user, if the host key changes.

Linux Sftp Use Ssh Key

1. The text is partially copied from Wikipedia article on Public-key cryptography. The text is licensed under GNU Free Documentation License.Back