The docs say, "The remote path in the FTP client must be set to the service’s resolution path. If a web service is published without a resolution path, the FTP client should use /ssg/soap as the remote path. For more information, see "About the Resolution Path" in Published Service Properties."
I don't really understand what this means. I understand resolution paths in the context of HTTP, but it's a bit of a mystery in the context of FTP. When does the FTP client have to send the path? When a client app connects to an FTP server, it simply connects to a given host name and port, then sends Username and Password. A path/folder is not specified. There are many commands in FTP that don't require a path be specified, so this is where I'm getting confused.
Say a company has an FTP server and they want the GW to proxy it, but they don't want the GW to perform the FTP authentication. Customers currently login to the FTP server directly with a UserID and Password and do not specify a path. The company's FTP server is configured to drop the user into a specific folder on the server, but to the client it will look like the root folder. The client simply uploads a file and disconnects. No path is ever specified. Is this use-case not supported by the GW's FTP proxy capability? Do you have to specify a path and if so, when do you need to specify it?
Hi I am not sure if this answers the question but I have setup a number ftp based services.
So Usually Yes i generate a policy with a service resolution path. This in most of my use cases are not used for the file transfer command. But to associate with the gateway listen port so it knows what to do when ftp hits that port. When I create my ssh listen port for example 2222 if I want this connection to 2222 to go right to a service in the advanced tab of the listen port, there is a check box to automatically associate this listen port to a service. And then this service and resoloution path can do a route via ssh ftp etc... But mostly the published service is just to assign a policy to the ftp listen port.
So in most cases as far as my use, the published service uri is really just to associate and endpoint with your ftp listen port. Does this help? As far as the gateway authenticating with the remote server you can just pass through the authentication.
Thanks for the reply Charles. I didn't know there was the option to associate the listen port to a service. That makes perfect sense. I associated it with my policy and now I'm able to connect via my FTP client now, and the policy is firing because I see my added audit details in the audit event viewer. But the policy is failing on the error "no user name found for passing through to FTP server". I'm providing a username and password through the FTP client and have the "route via FTP" assertion set to "pass through credentials in request". Any ideas?
I have used the passthrough without issues in the past. My first guess is the client OR just a false positive catch all error from the gateway. I would typically say if you think its the AUTH then for testing try hardcoding it and if it still fails its probably not what you think. And if it works maybe how the client is passing the user/password is causing an issue.
And does your policy include the require ssh credentials assertion?
If its a false positive the ssg_0_0.log (tailing it) may offer more details. Or trying a different client. If you get to deep into the policy it might be wise to open a support case with the policy and use case and what client you are using. And if you are just testing against a ssh server like (localhost the gateway) or what type of sftp server.
Also be weary sftp and ftps are 2 different things which sometimes gets missed.
Thanks again Charles. For right now I'm doing just FTP (not FTPS or SFTP - I'll be trying both of those after I'm able to get a simple pass-through use-case working with plain FTP) so I don't think I need to include anything for ssh credentials. I have no auth assertions of any kind in the policy since I'm just doing a pass-through and the GW isn't authenticating the user. I've tried using the windows command line FTP and also WinSCP and both result in the same error in the audit logs.
I'll reach out to support. Thanks again!