Port for FTP and SFTP broadcasts
Answered
The configuration of FTP broadcast is not having the option to set which port will be used.
Here's one scenario, if unsecure FTP port 21 is disabled at FTP host side, to change to SFTP using secure port 22, the previous FTP broadcast will fail, is that right?
How it can be confirmed which port is being used from the application to communicate to the FTP server?
Regards,
Alicia
Hi Alicia,
I'm wondering if this is possible - I would have thought this is configured via the server.xml but I can't see any relevant lines in there for setting the FTP port. It might be within the database. I'll find out and get back to you.
Kind regards,
Chris
Hi Alicia,
I'm wondering if this is possible - I would have thought this is configured via the server.xml but I can't see any relevant lines in there for setting the FTP port. It might be within the database. I'll find out and get back to you.
Kind regards,
Chris
Hi Alicia,
Have you tried setting the port in the configuration for the broadcast under the server hostname line, for example:
Let me know if that works.
Kind regards,
Chris
Hi Alicia,
Have you tried setting the port in the configuration for the broadcast under the server hostname line, for example:
Let me know if that works.
Kind regards,
Chris
Hello Chris,
Configuring the broadcast including the port in the Server Hostname field results in an error.
If only the protocol is included "sftp://" the broadcast works. i.e. sftp://localhost
For this scenario, I'm assuming that the application will communicate through port 22 as is the default secure port for SFTP.
I reviewed the logs but there's nothing indicating the connection string nor the port being used.
It appears to me that if no protocol is used in the Server Hostname file, the application will try to communicate through unsecure FTP port 21, and if SFTP protocol is used, then, the application will use the default secure SFTP port 22, can you confirm if this is the actual behavior?
Regards,
Alicia
Hello Chris,
Configuring the broadcast including the port in the Server Hostname field results in an error.
If only the protocol is included "sftp://" the broadcast works. i.e. sftp://localhost
For this scenario, I'm assuming that the application will communicate through port 22 as is the default secure port for SFTP.
I reviewed the logs but there's nothing indicating the connection string nor the port being used.
It appears to me that if no protocol is used in the Server Hostname file, the application will try to communicate through unsecure FTP port 21, and if SFTP protocol is used, then, the application will use the default secure SFTP port 22, can you confirm if this is the actual behavior?
Regards,
Alicia
Hi Alicia,
Yes apologies, it does appear that trying to customise the port doesn't work. FTP will use 21 and SFTP will use 22, as it's over SSH.
And as you said, SFTP:// must be defined in the hostname field.
We do have an existing open enhancement to create an option to force the use of SFTP instead of FTP, which might be of interest to you.
Kind regards,
Chris
Hi Alicia,
Yes apologies, it does appear that trying to customise the port doesn't work. FTP will use 21 and SFTP will use 22, as it's over SSH.
And as you said, SFTP:// must be defined in the hostname field.
We do have an existing open enhancement to create an option to force the use of SFTP instead of FTP, which might be of interest to you.
Kind regards,
Chris
Hi Alicia,
Hope you're having a good week.
Just wanted to check-in and see how it's all going. Was there anything you were needing from me to help get this resolved?
Regards,
Chris
Hi Alicia,
Hope you're having a good week.
Just wanted to check-in and see how it's all going. Was there anything you were needing from me to help get this resolved?
Regards,
Chris
Hi Chris,
This question has been resolved. Thanks
Hi Chris,
This question has been resolved. Thanks
Hi Alicia,
Thanks for letting me know! Enjoy the rest of your week.
Kind regards,
Chris
Hi Alicia,
Thanks for letting me know! Enjoy the rest of your week.
Kind regards,
Chris
Replies have been locked on this page!