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
|
.\" Personal
.TH FETCHFILE 7
.UC L
.SH NAME
O-SAFT / fetchfile
.SH DESCRIPTION
.SS Introduction
With the server protocol extension O-SAFT (Offer Simple Asynchronous File
Transfer) and the matching client fetchfile there is an easy method of
retrieving files from a SAFT server. This is a direct analogy to the SMTP
and POP or APOP protocol suite in the world of e-mail transfer.
.PP
Overview:
.RS
.sp
\- How does O-SAFT/fetchfile work?
.B
\- What to do on the client side?
.B
\- What to do on the server side?
.B
\- How about security issues?
.B
.sp
.RE
.SS How does O-SAFT/fetchfile work?
O-SAFT is an extension to the existing SAFT protocol and allows
athenticated clients to retrieve files from a (remote) server. The
implemention is the server sendfiled and the client fetchfile.
.PP
O-SAFT uses a dedicated pgp key pair to authenticate the fetchfile session.
The private key will be kept on the client side, the public key must tbe
present at the server side. For security reasons this will NOT be your
regular e-mail pgp key pair, but a separate pair of pgp keys, uniquely
assigned for fetchfile transfers. You will have to create a pair of pgp
keys for this purpose befor using the fetchfile client for the first time
(see below).
.PP
Fetchfile can provide a directory listing of available files from the server,
retrieve files or delete files. After retrieving a file, it will be placed
in the regular spool directory, not in the current directory! You will have
to use the receive command to transfer the files from the spool directory
to your current directory afterwards.
.PP
If there already exists a regular sendfile spool directory /var/spool/sendfile
on the client side it will be used, otherwise a $HOME/.sfspool will be
created. Fetchfile will be running without using root permissions on the
client side.
.SS What to do on the client side?
You must have pgp-2.6.x installed and the binaries must be available through your
$PATH environment variable.
.PP
First, and ONLY ONCE before using fetchfile the very first time, you
have to create a fetchfile pgp key pair (only pgp-2.6.x is supported!):
.PP
.TP 4
.B fetchfile -I
.PP
Please only hit 'ENTER' when being asked for a pass phrase! This will create
a special non-passphrase protected key pair for O-SAFT.
.PP
After this initialization you will have a file
/var/spool/sendfile/$USER/config/public.pgp resp. $HOME/.sfspool/public.pgp
.PP
Please send this file to root@SAFT-server, who has to save this public key
file into the appropiate user configuration directory.
.PP
Example:
.PP
.B sendfile -c 'my O-SAFT puplic key'
.B /var/spool/sendfile/$USER/config/public.pgp root@bofh.belwue.de
.PP
(This prelimary action will enable you to use the SAFT server and will
prevent othes from abusing your name or SAFT-account on the server.)
.PP
After preparing the pgp keys an both sides, you can invoke fetchfile on
a regular basis:
.TP 8
.TP
.B fetchfile -l
list files on the server
.TP
.B fetchfile -a
retrieve all files from server
.TP
.B fetchfile -daf *aol.com
delete all files from the AOL domain
.PP
There is a detailed description of all capabilities in the fetchfile(1)
man page.
For configuring the server SAFT account by the client user there are two
options:
.nf
fetchfile -Cw=config
fetchfile -Cw=restrictions
.fi
.PP
Using this the two local configuration files will be transfered from the
local current directory to the SAFT server. The details of the configuration
can be found in the sendfile(1) man page.
With using
.nf
fetchfile -Cr=config
fetchfile -Cr=restrictions
.fi
.PP
the files will be retrieved back and will be displayed to STDOUT.
.SS What to do on the server side?
pgp-2.6.x must be installed. The system adminsitrator needs to run
.B sfdconf -e config
add set the following option:
.PP
.TP 8
.TP
fetchfile = on
.PP
The system administrator must create a user account (if it does not yet
exist). This account does not need an interactive login shell and does
not need a valid password; the login shell could be /bin/false. The only
purpose is to enable the sendfiled to check out the user and to create
a local spool directory (this method is well known for creating POP mail
accounts).
.PP
The client user will create the initial pgp key pair and the public key
(public.pgp) will be sent to the system administrator of the server.
This key has to be placed into the config directory for the particular user.
Assuming the user name is bozo, the system administrator will have to
type the following (under root permissions):
.PP
.nf
receive -f bozo@* -b bozo public.pgp
su bozo
cd /var/spool/sendfile/bozo/config
receive public.pgp
.fi
.PP
(the first receive resends the file public.pgp from the sender bozo@* to the
local user bozo)
.SS How about security issues?
O-SAFT uses a tcp challenge/response authentication with a pgp signature.
This opens the possibility that the session can be attacked through tcp
hijacking. We are well aware of this, but tcp hijacking is not easy and
only possible if the attacker has direct access to the transport media
(e.g. listening on the same ethernet cable/segment) and has access to a
set of pretty nice cracker tools. With regular operating system supplied
software it is not possible to attack a session.
.SH SEE ALSO
.BR sendfile (1),
.BR fetchfile (1),
.BR sendfiled (8).
.SH AUTHOR
Ulli Horlacher - framstag@rus.uni-stuttgart.de
.PP
translated by andreas@citecs.de
|
