1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
|
FTP to SFTP (#1):
https://www.bitvise.com/ftp-bridge
https://enterprisedt.com/products/completeftp/doc/guide/html/gateway.html
mindterm source (Java, FTPOverSFTP bridge code for mapping)
For each FTP command, decompose it into SFTP request equivalents; note which
FTP commands have no SFTP request equivalents.
USER
PASS
USERAUTH
ACCT
n/a
CWD
XCWD
CDUP
XCUP
n/a; will mod_proxy have to maintain some state about the FTP session
for such directory traversal commands? Yuck. Maybe use with REALPATH?
SMNT
not implemented
REIN
not implemented
QUIT
CHANNEL_CLOSE
PORT
EPRT
PASV
EPSV
this will be the most interesting; translating SFTP data transfers into
frontend FTP transfers.
TYPE
n/a (binary only?)
STRU
n/a; always F
MODE
n/a; always S
RANG
REST
RETR
OPEN + READ + CLOSE
RANG
REST
APPE
STOR
OPEN + WRITE + CLOSE
STOU
OPEN + WRITE + CLOSE; have mod_proxy generate the unique name for the
backend SFTP file? Use O_CREAT|O_EXCL to force uniqueness, I guess...
ALLO
n/a
RNFR
RNTO
RENAME
ABOR
n/a; maybe just stop the current data transfer, send CLOSE?
DELE
REMOVE
MDTM
STAT
MKD
XMKD
MKDIR
RMD
XRMD
RMDIR
LIST
MLSD
MLST
NLST
OPENDIR + READDIR + CLOSE
MFF
FSETSTAT
MFMT
FSETSTAT
PWD
XPWD
SITE
n/a; support for specific SITE commands *may* be added later, e.g.
SITE CHMOD = SETSTAT
SITE CHGRP = SETSTAT
SITE SYMLINK = SYMLINK (from mod_site_misc)
SITE UTIME = SETSTAT (from mod_site_misc)
SIZE
STAT
SYST
n/a; always "215 UNIX Type: L8"
STAT
STAT
HELP
n/a?
NOOP
no backend equivalent; handle in proxy
FEAT
n/a (SFTP extensions?)
OPTS
LANG
n/a
HOST
n/a
CLNT
n/a (would be part of SSH connect, but is too late in FTP protocol)
AUTH
PBSZ
PROT
n/a (provided by SSH by default!)
For authentication, it will always be password authentication to the backend
SSH server. (Or should this overridable, e.g. password authentication to
the proxy, but hostbased authentication from the proxy to the backend server?)
What does this look like, for an FTP forward proxy configuration to an SFTP
backend? How would mod_proxy know that the destination server is an SFTP
server? I suppose it could do a probe: make the initial TCP connection,
see whether it gets the "220 Server Ready" FTP response, or the "ssh-..."
SSH banner...
Note: This would require that mod_proxy be built _without_ mod_sftp being
present! This means that the logic regarding mod_sftp HOOKs would need
to be revisited.
Implementation:
Implement a "protocol", which handles all of the above FTP commands.
The default Protocol object will do what mod_proxy currently does for
all of the commands; this will thus be a transparent change. These
Protocol objects would then have to maintain/accumulate their own state,
so as to implement/translate RNFR + RNTO = RENAME, *and* be responsible
for translating the responses. Thus these would indeed be more than
just codecs (or, for some value of "codec", very complicated codecs).
Once that's done, we need to determine how to lookup a new Protocol object,
and when do it, and when to register it. For cases where mod_proxy
knows the backend URL at connect time, this is easier. What about for
the auth-time (PerUser, PerGroup) URLs?
FTP Implementation API:
Suitable for plugging into mod_proxy's CMD C_ANY handler, *and*
its POST_CMD C_PROT handler. Thus the API for the given impl
input should be something like:
MODRET (handle_cmd)(pool *p, cmd_rec *cmd, int cmd_phase);
Consider, for example, a logging-only Implementation object, to
demonstrate the concept?
Note that this Impl API works for FTP, but NOT for SSH; SSH packets
are not handled by the C_ANY handler.
SFTP to FTP (#2):
No forward proxying supported here, since SFTP doesn't have that notion;
mod_proxy will know (via the ProxyReversServers URL schemes) which protocol
to use for the backend server.
SCP (#3?):
subset of SFTP to FTP, with no directory listing support.
|
