SFTP access

[Boštjan Hozjan]

Hi, I have strange thing going on, need some help:)

Inside VM's console I've created 1 group with 3 different users, basically just to use them with SFTP. Then I've created 3 public/private SSH key pairs. I've put 2 of those public keys to VM instance (check attachment).

Strange thing is that whatever public key I enter last in SSH keys settings (check attachment), user that this key belongs to can access SFTP server (using FileZilla with Key File logon type). Other users of whom I've entered public keys before that, can't access SFTP no more.

Example:

1. In VM instance's SSH key settings I enter public key of user with username john

2. User with username john can access SFTP

3. In VM instance's SSH key settings I enter public key of another user with username mike

4. User with username mike can access SFTP, but user with username john can't access SFTP no more.

5. Error that john gets in FileZilla is:

Error: Disconnected: No supported authentication methods available (server sent: publickey)

Error: Could not connect to server

What am I doing wrong?

[Fady (Google Cloud Platform)]

Hello Bostjan, 

Is it possible to send me a private message with a detailed Filezilla session log ? (redact private info) Meanwhile, can you check if all public keys are available at ~/.ssh/ at your instance and match the keys you created? 

[Boštjan Hozjan]

Hi, did it, few hours ago ;) Thanks

[Boštjan Hozjan]

Hi, been unable to resolve situation. Here's another more detailed description with steps to try to reproduce error. Note, when I'm talking about public keys, I'm not talking about server's key but about user's public key.


I've set up Compute engine VM instance in gCloud. I've set up everything, including SFTP similar to as described at https://devtidbits.com/2011/06/29/implement-a-sftp-service-for-ubuntudebian-with-a-chrooted-isolated-file-directory/.

I've created 2 different users with different user IDs that belong to the same group (for the purposes of SFTP usage). Then I've created public/private SSH key pair for every user (as described at https://cloud.google.com/compute/docs/instances/adding-removing-ssh-keys).

Then I've tried two exactly same scenarios with same settings, just on 2 different levels - with setting metadata on project level (https://console.cloud.google.com/compute/metadata/sshKeys?project=PROJECT_ID) and with VM instance's keys on Edit instance page (instance level)(https://console.cloud.google.com/compute/instancesDetail/zones/europe-west1-b/instances/[INSTANCE_NAME]?project=[PROJECT_ID]&graph=GCE_CPU&duration=PT1H). Either of them should work.


With metadata on project level:

1. I added first public key (let's say of User1) to project metadata and tried to connect with FileZilla with User1's username and private key. Everything worked fine.
   
2. I added second public key (let's say of User2) and tried to connect with FileZilla with User2's username and private key. Everything worked fine.
   
3. I tried to connect with FileZilla again with User1's username and private key. Got no connection (Error: Disconnected: No supported authentication methods available (server sent: publickey). Error: Could not connect to server)
   
4. Deleted both public keys in gCloud settings.
   

With VM instance's keys on Edit instance page: - same scenario with no luck

1. I added first public key (let's say of User1) to instance settings and tried to connect with FileZilla with User1's username and private key. Everything worked fine.
   
2. I added second public key (let's say of User2) and tried to connect with FileZilla with User2's username and private key. Everything worked fine.
   
3. I tried to connect with FileZilla again with User1's username and private key. Got no connection (Error: Disconnected: No supported authentication methods available (server sent: publickey). Error: Could not connect to server)
   
4. Deleted both public keys in gCloud settings.
   

I've had FileZilla opened all the time (also tried with restarting FileZilla between steps 2 and 3) but problem still remains. Since every time I could've connected to SFTP with the user that I set up public key last, I don't see that FileZilla itself is the problem.

It's like I can't use more than one user. Really don't know what else can I do ... Any suggestions?

BTW, tried similar scenario by trying to connect to SSH with Putty, but again - every time I was able to connect just with the user that I set up public key in gCloud settings the last.

Also, my colleague tried to do the same - connecting with Putty and FileZilla with username, that wasn't added last - and he also couldn't connect.

Is it possible that there's something wrong with VM instance?

I've read multiple forums but couldn't find a solution. Crying for help here ;)

[Boštjan Hozjan]

Hm, found out what's the issue, but don't know how to fix it: any time I add new SSH public key of a user to VM instance in instance settings (through GUI, not console) the file /.ssh/authorized_keys gets overwritten - instead of just adding new  key, the old one gets deleted and new one added.

Any suggestion how to fix it? Or is this a bug?

[Fady (Google Cloud Platform)]

Following up on our private conversation, and to benefit the community if anyone has a similar question, we have concluded that the behavior mentioned is not an issue with the guest environment itself. To verify, I tested SFTP with multiple simultaneous user authentications and successful file transfers, but I couldn't reproduce the same behavior. However, after investigating your use case, this behavior was rather due to a custom configuration that you implemented in your Linux instance.

You have been following this third party tutorial to implement SFTP, and disable shell access (SSH) to your developers on a Linux server. After checking the tutorial, you had to SSH to your instance and manually create a user group, create users, direct them to root as a home directory rather than the default home directory, modify the SSH daemon file (sshd_config), and change ownership of some files to root. At the same time and despite such modifications, you wanted to manage your SSH keys through the Google Compute Engine metadata.

According to this document, The guest environment does not update the keys for manually created users. Hence, it is not advisable to manually create them and then add the same users with their keys through metadata (or the opposite if possible) as this causes conflicts. The guest environment by default in a normal setup and without any manual modifications automatically creates the users, their home directories, and their corresponding (~/.ssh/authorized_keys) file which contains the public keys. Removing or restricting access to each user’s home directory and it’s content will cause authentication issues.

For this use case, it is advisable, when manually creating users, to manually add the keys to the corresponding directory that the manually configured SSH daemon checks, rather than adding them through metadata. On the other hand, If you would like to use metadata to manage your user keys, then this simple alternative could work without conflicts. If you choose the latter make sure to restore the original settings of the guest environment (only if you changed them, SSH daemon ..), delete the current users, and recreate them with their keys through metadata, and then use the commands in the provided link for each of your users. Please note that since these instructions are from a third party source, we cannot guarantee their accuracy. Google does not take any guarantee of its working behavior and any implications that it may cause.