21–30 of 33 posts
Earlier quoted context omitted.
Unfortunately SFTP isn't a good replacement when speed is a concern, anything running over OpenSSH will have its bandwidth limited by the fixed window size. I long for the day when HPN-SSH replaces OpenSSH everywhere.
I just found out this is a thing. Thank you for this.
These systems are there for the same reason COBOL and RPG are alive and well.
Earlier quoted context omitted.
For me, I SFTP from 5 locations around the globe daily. I could build a complex system to manage the transfers.. but why, when it just works for our use case.
SFTP is basically just SSH, the only thing it shares in common with FTP is the name.
Earlier quoted context omitted.
SFTP is basically just SSH, the only thing it shares in common with FTP is the name.
SSH is just the transport, you use a different protocol inside it. But yeah, it's not FTP
The original RFC for SFTP was written to actually be a simpler version of FTP. While v3 seems to be the standard and the final RFC was never ratified, SFTP is still FTP.
Earlier quoted context omitted.
For me, I SFTP from 5 locations around the globe daily. I could build a complex system to manage the transfers.. but why, when it just works for our use case.
Unfortunately SFTP isn't a good replacement when speed is a concern, anything running over OpenSSH will have its bandwidth limited by the fixed window size. I long for the day when HPN-SSH replaces OpenSSH everywhere.
Earlier quoted context omitted.
Unfortunately SFTP isn't a good replacement when speed is a concern, anything running over OpenSSH will have its bandwidth limited by the fixed window size. I long for the day when HPN-SSH replaces OpenSSH everywhere.
Most of our transfers are limited by our backbone, but because we chunk files we're able to do multiple concurrent transfers and max out traffic as best we can. We mostly have 10g links, but anything over that tends to get into serious diminishing returns in value/performance.
Earlier quoted context omitted.
SSH is just the transport, you use a different protocol inside it. But yeah, it's not FTP
The only difference is the security transport / authentication, otherwise if functions the exact same way. The original RFC for SFTP was written to actually be a simpler version of FTP. While v3 seems to be the standard and the final RFC was never ratified, SFTP is still FTP.
They are very different. SFTP isn't even textual, nor does it have separate control and data channels of FTP.
Are these exactly the same?:
https://www.ietf.org/rfc/rfc959.txt
https://datatracker.ietf.org/doc/html/draft-moonesamy-secsh-...
Earlier quoted context omitted.
SSH is just the transport, you use a different protocol inside it. But yeah, it's not FTP
The only difference is the security transport / authentication, otherwise if functions the exact same way. The original RFC for SFTP was written to actually be a simpler version of FTP. While v3 seems to be the standard and the final RFC was never ratified, SFTP is still FTP.
Note that SFTP is not a protocol for security transport / authentication. It doesn't do that. It assumes that you've already secured/authorized the channel with SSH. See section 1 of the RFC.
https://datatracker.ietf.org/doc/html/draft-ietf-secsh-filex...
FTP did have some odd features that were useful at times. The SITE EXEC command allowed programs to be run remotely, with their output filtered back to the client. The proxy command allowed functionality similar to modern jump host ssh. Of course, anonymous ftp has no equivalent in ssh/sftp.
Being able to send files between two ftp servers without having to download then upload is a pretty interesting feature that arises from the two connection model of data transfer. Of course, that model also makes ftp hard to secure and hard to NAT.