If you set
UsePam no, then
sshd itself will do the job of the PAM modules, as best as it can.
sshd is running as root, it can use
getspnam(3) function to get the user's password hash and other information from
/etc/shadow (or from NIS, LDAP or any other storage location supported by the C library of the system), select the password hashing algorithm by looking at the beginning of the hash, then hash the password entered by the user with the salt from the
getspnam(3) result using
crypt(3). The result is then compared to the complete password hash retrieved by
getspnam(3). If they match, the password authentication is successful.
Account verification step is again pretty simple: the password expiration information is included in the
getspnam(3) results, and another check is made that the user's shell exists and is listed in
Session creation includes a number of steps whose details depend on the type of Linux or Unix the service is running on. But typically, for a shell session, the
sshd child process handling this specific connection would record the session information to the
wtmp files, set up a pseudo-TTY, then
fork() another child process that would take on the user's UID and group memberships, switch to the user's home directory and call
setsid() to become a session leader. This process would then
exec() the user's shell.
When the shell dies, the
sshd child process holding the master end of the pseudo-TTY would then perform any necessary clean-up actions, like recording the end of session in the
This is roughly how a Unix session was handled before PAM was invented.