#Scp server ps3 remote not working windows

None of our other shell choices in Bitvise respect the virtual filesystem root. It is also expecting to have access to (presumably) GNU compatible binaries. So now we know not only does this 'SCP' transfer method require a shell to execute commands. So it's trying to create the 'myfolder' which I had already pre-created using 'mkdir -p' and apparently the mkdir command in BvShell doesn't support the '-p' option. ERROR: Failed to create dir /myfolder/ at 10.10.10.10 sshCmd:, rc:2, stdOut:, stdErr:mkdir: Unexpected command parameter: -p. There's now a /var/log/vmware/applmgmt/backup.log though which has more details. But it eventually errors out with the message,Д«ackupManager encountered an exception. I run through the wizard again and make it through to where it seems to be starting the backup job. Sounds great! The backup user should still be tied to the virtual root folder and limited to commands that are associated with file transfers. file copy) that their SFTP or SCP client might not provide. It is intended to be enabled for clients limited to file transfer access that may wish to use commands (e.g. BvShell does not permit execution of arbitrary programs. This is the only shell type which respects the virtual filesystem layout configured for the client in SSH Server settings. From their help docs:Д«vShell is a bash-like shell provided by the SSH Server. But the only one that respects the virtual filesystem root folder is their BvShell option. So I modify the settings for the backup user to allow a shell. In any case, now I'm curious what it will take to get it to work.

But why? Just to validate credentials in the wizard? Why not just SCP a zero byte file or something? Again, I've already verified that plain old scp works just fine with the current configuration and the GUI and Docs all refer to this option specifically as 'SCP' and not 'SSH'. That definitely verifies that it was trying to open a shell. ERROR: Failed to validate SSH login at 10.10.10.10:22/myfolder sshCmd:, rc: 255, stdOut:, stdErr: I see this in /var/log/vmware/applmgmt/backupRestoreAPI.log: So let's dig into the log on the VCSA side. But why is VCSA trying to open a shell when it's supposed to be using SCP? When I check the logs on the SSH server, I see that the session was denied because it was attempting to execute a command, 'Command execute request rejected.' This is exactly what I wanted it to do when I set the 'No shell access' option. I also pre-created an empty 'myfolder' in the virtual root. Check your credentials and permissions.ДЇor reference, here are the values I used in the wizard. However, when I attempt to configure the backup job from the VCSA web UI, I get the following error.ДЄccess to the remote server is denied. ' and everything transfers successfully. That is, I can SSH to vCenter, drop to the shell, and 'scp filename or 'scp. I have verified that SCP file transfers to and from my VCSA to this SSH server using the account I configured work just fine.

The user config looks like this if anyone wants to try and reproduce locally.

#Scp server ps3 remote not working windows

My backup target is currently a Windows box running Bitvise SSH Server using a dedicated local account that is limited to file transfers only (no shell) and a virtual root directory. I've been attempting to test out the SCP option in the new File-based VCSA backup feature in 6.5 (specifically, I'm testing against 6.5.0e which is the latest as of today).