So, there are usually four sshd processes involved in handling a connection: 1 - master sshd, listens for incoming connections. When it accepts one it forks an

So, there are usually four sshd processes involved in handling a connection: 1 - master sshd, listens for incoming connections. When it accepts one it forks and executes a new sshd to handle it. It executes a new sshd to ensure that each one gets different runtime randomisations (ASLR mappings, PRNG state, etc.) 2 - privileged sshd. This is the result of the fork+exec of (1) above. It does absolutely no packet processing and exists only to perform options that require privilege or access to sensitive data (e.g. the host keys). As soon as it starts, it forks an unprivileged process. 3 - pre-auth sshd. This is the first unprivileged process forked by #2. It is responsible for packet processing and most crypto (except that which touches sensitive data). This process runs in chroot, In recent OpenSSH versions, this process is sandboxed using systrace, seccomp-bpf, OS X seatbelt or (if none of these are supported) restrictive rlimits. It exits as soon as the user is authenticated. 4 - post-auth sshd. This is forked from the #2 process after authentication completes. It runs with the privileges of the user and handles network packets and crypto much like #3. Most of this (except the re-exec and sandboxing) is described in Niels Provos' original privsep paper: http://www.citi.umich.edu/u/provos/ssh/privsep.html http://www.citi.umich.edu/u/provos/ssh/privsep.html