Lines Matching refs:monitor
37 implementation where one process, the "monitor" is privileged and
198 It consists of a monitor, which retains all privileges and access to
206 The monitor and its companion processes speak a private protocol
210 In practice the OpenSSH monitor protocols relating to user
217 essentials and the monitor serves only services such as signing
220 Note also that the OpenSSH monitor protocol uses the same encodings
231 led to a situation in which the monitor acts as an oracle, willing
237 minimizing and simplifying the protocol spoken by the monitor, but
246 also wish to avoid creating any oracles in the monitor.
248 This approach allows us to have a very simple monitor protocol. Our
249 monitor protocol consists of the following operations:
258 not require a monitor protocol message.
260 By processing all re-key protocol messages in the monitor we prevent
261 the creation of oracles in the monitor. This is so because the
262 monitor signs only material which it has generated and over which an
268 - If the monitor receives SIGHUP, SIGTERM or SIGINT it will call
273 - The monitor does not attempt to update utmpx/wtmpx independently
280 - The sshd server process (the one that will become a monitor)
283 PKCS#11 sessions initialized in the monitor unless
294 the monitor waits aside to read the authentication context that
313 "pre-session," "session" and "monitor."
330 The OpenSSH monitor process implements:
346 monitor as in a server w/o privilege separation.
352 "session" and "monitor."
354 The SUNWssh monitor process implements:
369 monitor protocols.
371 The OpenSSH 3.5p1 monitor protocol, on Solaris, has approximately 20
372 monitor request and corresponding response messages.
374 The SUNWssh monitor protocol has 5 monitor request and response
375 messages; additionally, the monitor processes standard re-key
376 messages (but note: the monitor and the session process IPC is
380 Much of the OpenSSH monitor protocol is a variation of the
382 believe this does not afford the monitor much additional, if any
386 The re-packaging that is done in the OpenSSH monitor protocol is
392 could evolve somewhat in the OpenSSH direction by saving the monitor
393 all transport protection work, but we cannot save the monitor much,
402 The first improvement would be to have a single system-wide monitor.
407 the saved-set-user-id in the monitor to that of the logged in user
413 configure their server and monitor so that no re-key protocol
414 messages need be processed by the monitor.
418 Kerberos V mechanism's replay cache. This would allow the monitor
426 all transport protection and proxy to the monitor all key exchange
429 contents seen there. After authentication succeeds the monitor
432 pass the session keys/IVs/keystate to the monitor which would then
551 +-> monitor start routine, altprivsep_packet_*() routines
552 for communication with the monitor, routines to help
553 with key exchanges, service procedures for the monitor,
576 to/from the monitor
584 +-> adds an event loop for the monitor
596 child processes do not compete for monitor IPC I/O.
602 the monitor's debug and log messages get prefixed with a
603 string ("monitor ") that indicates they are from the
604 monitor
610 the monitor and move the relevant code into the monitor
615 The monitor uses the packet.h interfaces to communicate with the
619 private monitor message used for the other monitor services.
621 The monitor serves the following services:
627 The session and monitor processes communicate over a pipe.
629 All monitor IPC I/O from the session process is blocking (though the
630 pipe is set to non-blocking I/O). The monitor protocol is entirely
635 prevent the monitor from handling SSH_MSG_NEWKEYS messages as a
638 negotiated with client from the monitor.
641 monitor after authentication. In fact, the monitor thinks it's