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
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
|
Subject: Use of mgetty with pppd (FAQ addition, not yet inside official FAQ)
$Id: ppp,v 1.2 1999/10/30 15:46:45 schaefer Exp $
[ This is very Linux specific. However, the basics should work
with usual pppd configurations on other UNIX systems too
]
+++ The goal is to merge this with the general mgetty FAQ once this
+++ stabilizes and I have understood SGML :)
People like to have users dial in with PPP instead of normal login. This
can be safer and also easier to use / more powerful. Using pppd with
mgetty is twoafold: first, you need to make so that pppd is launched one
way or another. There are two ways:
1. make so that mgetty auto-detects a PPP frame before
(technically: after) even sending the login: prompt.
This means thats the people will not have to login first
(in clear: no ogin:/sword: chat scripts needed).
2. make so that the user first logs in with a special user, and
then either pppd is the user's shell, or the user launches
pppd from there manually.
Although technically possible, method 2 is discouraged and will not be
described here. Method 1 is the suggested method and will be discussed
here.
To use method 1, the following are mgetty pre-requisites:
- mgetty must have been compiled with -DAUTO_PPP (see mgetty's
documentation and other FAQ entries)
- The /AutoPPP/ demonstration line in login.config must be uncommented,
and all arguments checked, such as e.g. path to pppd executable, etc.
Other pre-requisites that will not be detailed here are of course PPP
support in your OS/kernel, a working pppd, etc.
What do you put on the pppd command line in login.config ? It really
depends how you want to handle your incoming PPP connections. Assuming
you assigned the IP address 192.168.2.1 to your PPP server, and that you
want some debugging in the system log (on Linux: /var/log/messages),
you would use something like this:
/AutoPPP/ - a_ppp /usr/sbin/pppd crtscts modem -detach debug 192.168.2.1:
Of course, this doesn't authentify the user, doesn't support
connecting to other computers than the PPP server, and so on. This
above examples forces only the server IP address. See below for
forcing both (only works for one port. For more than one port you need
either per-user IP addresses, explained below, or per-port IP address,
explained here (*)).
For authentification, you must add the auth keyword on the pppd command
line. Then, you have the following choices:
[
(*) a ``better'' approach can be to put all those options in /etc/ppp/options.
You could create an option file per port your are activating, e.g.
if you want to statically set up static addresses per tty, and not
per user. WARNING: this is incompatible with the version presented
here. We assume one IP per user, not one IP per port.
Example:
/etc/ppp/options.ttyS0
pppserver:pppserver-ttyS0 # converted by DNS to IP addresses
asyncmap 0
proxyarp
modem
auth
crtscts
require-chap
ktune
name ppp-server
netmask 255.255.255.0
ms-dns 192.168.15.1
ms-dns 192.168.15.2
AT LEAST: you should not have some options in /etc/ppp/options, and
some more on the command line. Keep everything in the
same place.
]
- you can use a password database in /etc/ppp/, be it chap-secrets or
pap-secrets (chap-secrets contains cleartext passwords, but password
hashes only are transmitted in clear; pap-secrets works mostly like
UNIX authentification: the crypted password is stored and the
unencrypted is transmitted).
auth -pap +chap
auth +pap -chap
- you can use PAP, but with the /etc/passwd database (or possibly even
the PAM authentifications). This is the ``login'' option.
auth +pap -chap login
Assuming you use PAP, you need to modify the /etc/ppp/pap-secrets, unless
you used the login option: in that case, valid users in /etc/passwd make
valid users for PPP. Possibly the IP address is then taken from
/etc/ppp/pap-secrets, still (but I am not sure of it --- I don't use the
login option, I use CHAP anyway).
Note that you can force an IP address for the client either by listing it
on the right of the /etc/ppp/chap-secrets or /etc/ppp/pap-secrets, or in
the command line (192.168.2.1:192.168.2.2 forces 192.168.2.2 as client).
Of course, forcing for both only works either if you have only one
PPP dialup line, or if you assigned specific configurations/addresses
per tty (see the bracketed comments above about /etc/ppp/options.ttySx).
Note that if the client not only authentifies itself to the server but
also requests authentification from the PPP server, things get more
complicated. In most setups you don't need this, so do not use auth
keyword on the pppd client.
Some users report that some distributions ship pppd without the
execute bit set. This will even prevent root from executing it.
chmod 555 `which pppd`
chown root.root `which pppd`
You don't need the setuid or setgid or any other things when
running from mgetty login.config.
Other users reported that pppd version 2.3.7 has a bug which causes
not passing of utmp parameters with /AutoPPP/, ``hence you will never
get a login using /etc/passwd''. Versions 2.3.8 and 2.3.9 seem
unaffected. Well, I don't really understand why utmp should be
related to that problem.
To allow the newly connected user to connect to any computer of the local
network where the PPP server is located, you need this:
- The IP addresses must be in the same routing zone as the ones from
the local network. This means: if the Ethernet network uses
192.168.2.X (or 192.168.2.0/24 as people like to write it), your
PPP server and the PPP users must get assigned addresses in this
zone too.
- You must add the ``proxyarp'' option to the AutoPPP line above. This
tells pppd that it should advertises the user PPP connected address
on the Ethernet.
- Your kernel must have IP forwarding on, and in some cases the option
ktune should also be given to pppd so it can set it for that
interface (assuming you don't forward by default).
Alternatively, you can set up your PPP server with completely different
addresses, but then you need to either have all computers on the Ethernet
to have default route on the PPP server or to have specific routing.
That will not make proprietary non-routable protocols such as NetBEUI
work: typically the ``Network neighbourhood'' of MS-WINDOWS'* will fail.
For that to work, you need to have a WINS server on the network (be it on
the Ethernet or the PPP server itself), and reference it in hard in the
dial-in clients (it works better that way it seems).
You may also want to configure your /etc/ppp/options file, e.g. for
supporting extensions such as the Microsoft DNS or WINS handshake.
Typical problems that can happen:
- /var/log/messages complaining about some ppp-* modules not found
Edit /etc/conf.modules
alias ppp-compress-21 bsd_comp
alias ppp-compress-24 ppp_deflate
alias ppp-compress-26 ppp_deflate
Check that you have those modules in /lib/modules/VERSION/net/.
Typical questions:
Q: What are supported pppd versions ?
A: I don't really know. I use ppp-2.2.0f, which is damn old.
Q: Can you explain the mgetty/pppd interactions ?
A: Basically, mgetty never runs when pppd (or login, or uucico, or
a shell after login) runs. mgetty will be relaunched by init when
the last child dies (be it the shell, pppd, etc).
In more details:
1 the user dials the number, the modem returns CONNECT, mgetty
has the modem line on the other end.
2 mgetty probes the line for a
- fidonet prompt
- PPP sequence
If the appropriate sequence is received, the appropriate program
is launched (depending on login.conf /AutoPPP/ and /fido/ I think.
Else, a login: prompt is sent.
3 Based on the login received and login.conf, the appropriate login
program is launched.
Basically, the call is no longer mgetty's business either at the
reception of the PPP frame, fido frame, or login name. That's why
we don't like to do PPP support in the mgetty mailing-list.
Now, if you don't want to use AutoPPP, you can well have a special
username launching pppd in login.conf, or even a special user, a
password, and pppd as login shell in a way it works (this involves
suid root, special groups, etc). But all this means you need the
client to not just send a PPP frame, but to send a chatting sequence
--- much more complicated.
CHAP or PAP is an additional authentification. You don't need it if
you use a special user + password (no AutoPPP). If you use AutoPPP,
you are advised to also have CHAP or PAP since else your system is
open to any dialer without any authentification (same if the account
has no password, or is specified in login.conf)
Q: How do you tell if my mgetty precompiled binary is recent/contains
support for AutoPPP or other features.
A: I will give typical commands and their results
grep getlogname /var/log/vgetty.ttyS0
-> 10/25 15:22:29 yS0 getlogname (FIDO AUTO_PPP), read:~[ff]}#[c0]!
rpm -q -f `which mgetty`
/usr/lib/mgetty/mgetty -V
Typical configuration example (one which is used):
If after all this, you still have a problem with pppd and mgetty, post to
the mailing-list, but make sure that you:
- show clearly if mgetty does launch pppd or not (ie if it's a mgetty
or pppd problem)
- show an excerpt from the system pppd log.
Maybe you should also try linux-ppp or other mailing-lists if mgetty
seems to NOT be the issue.
|
