https://github.com/noteed/sftp-streams

SFTP protocol
https://github.com/noteed/sftp-streams

Last synced: about 2 months ago
JSON representation

SFTP protocol

• Host: GitHub
• URL: https://github.com/noteed/sftp-streams
• Owner: noteed
• License: other
• Created: 2014-07-22T21:45:42.000Z (over 10 years ago)
• Default Branch: master
• Last Pushed: 2015-11-06T14:03:03.000Z (about 9 years ago)
• Last Synced: 2023-04-13T10:31:56.598Z (over 1 year ago)
• Language: Haskell
• Size: 195 KB
• Stars: 7
• Watchers: 3
• Forks: 1
• Open Issues: 0
• Metadata Files:
  • Readme: README.md
  • License: LICENSE

Awesome Lists containing this project

README

        
# sftp-streams

Attempt to implement the SSH File Transfer Protocol.

## Status

There are two small binaries: `sftp-mitm` and `sftp-mem`.

`sftp-mitm` can sit between `sshd` and the SFTP SSH subsystem (e.g. on Ubuntu

this is `/usr/lib/openssh/sftp-server`). It parses the packets exchanged by a

regular client and the real SFTP program on the server, and display them.

`sftp-mem` implements a few commands. Those commands are exercised in

`test-sftp-mem.sh` and can be compared to `test-sftp-mitm.sh`. They can be seen

in [test-batch.txt](test-batch.txt).

`test-sftp-sshs.sh` uses SSHFS to talk to `sftp-mem`.

## Docker image

Paths are hard-coded in the executable. There is a Dockerfile to create an

image that matches the expectations. Before building the image, you need to

provide a public SSH key `insecure_id_rsa.pub` and the `sftp-mitm` binary (put

them in the `images/sftp-mitm` directory). Same for `sftp-mem`.

## Notes

I have started to implement this package by looking at

http://tools.ietf.org/html/draft-ietf-secsh-filexfer-13 (which describes

protocol version 6) then I have switched to

http://tools.ietf.org/html/draft-ietf-secsh-filexfer-02 when I saw that my

client was using protocol version 3.

The version of `sftp` (i.e. the client) I used defaults to protocol version 3.

I have not tried protocol versions 1 and 2 (accessible with the `-1` and `-2`

flags). 

The client can re-use packet IDs very quickly (e.g. after 3 or 4 requests).

`SSH_FXP_READ` packets request 32768 bytes at a time. I think I can use the

`-B` flag to influence that size.

If the server response includes less than the requested size, the client will

issue a second request to try to get the "missing" bytes, but not again 32768

bytes. It does so even if the preceding `SSH_FXP_STAT` request lets it know the

size of the file and thus that the file was complete.

It is necessary to create a directory that you plan to transfer with `put -r`:

    > mkdir some-directory

    > put -r some-directory

otherwise the server fails. I think the reason is that the client first issues

`SSH_FXP_REALPATH` to get the correct path of the directory before transfering

it. That requests fail because the path doesn't exist yet.

Actually, by preceding the `put -r` by `mkdir`, everything (from the user point

of view) works. In reality, the `put -r` also tries to do a `SSH_FXP_MKDIR`

which fails because the directory already exists.

For debugging, I could have used the `-D` flag instead of passing through sshd.

Instead of configuring sshd's subsystem to use the `sftp-mitm` program, the

`-s` option could have been used.