>> continued from previous page
Scenario: SSH via SMB
The first scenario we're going to set up will be a Linux server tuned so that any connections to it via the SSH protocol will be authenticated via SMB (Server Message Block) to a Windows server. While a Windows NT 3.51, NT 4, 2000 or XP server should work, we used a Microsoft Windows 2000 Advanced Server.
Although the SSH protocol can use passwords or certificate keys for authentication, SMB authentication uses only passwords. We'll use passwords for the SSH sessions; were we to use certificates, SMB authentication would not be involved in the authentication. You can use any PAM-aware SSH server, but we recommend the OpenSSH server that ships with Red Hat 7.2, which has already been integrated.
To do this, we'll need a PAM module that is not included by default in a Red Hat Linux 7.2 system (see
"Windows Domain Authentication in PAM," for information on downloading and compiling the module, and the SMB challenge-response authentication).
Our setup is shown in "SSH Service Authentication via SMB Challenge/Response." On the Linux SSH server, make sure the SSH server is installed by running the command rpm -q openssh openssh-server, which should return the output:
openssh-2.9p2-7
openssh-server-2.9p2-7
The version numbers may be different.
The SSH server can be configured by editing the file /etc/ssh/sshd_config, though the default values should be acceptable. The SSH protocol can use passwords or certificate keys for authentication. For this example, we want to use passwords, but that too is the default for SSH.
We installed and configured pam_smb, then edited /etc/pam.d/sshd so it looks like "Modified SSHD PAM Configuration". (Doing so requires adding only one line, the first auth line.)
We have instructed the PAM system so when SSH connections occur, it should first try to use SMB authentication to verify the SSH user. If the user name/password pair provided is accepted by the Windows domain, allow the user access. Should the pair not be excepted, use them to authenticate according the the system-auth configuration. Should that fail, deny the user access. This has configured the SSH service to use pam_smb module as a rule for authentication.
Finally, we need to add users to both the Linux server and the Windows domain. Here lies an obvious deficiency with this solution. We have provided an enterprise-scalable authentication mechanism but not an enterprise-scalable account-management mechanism.
We must somehow make sure that for every user in the Windows domain, that same user exists on the Linux server (see "Windows 2000 Services for Unix"). We'll add the users by hand with User Manager on Windows and by running useradd on Linux. You need to provide a password for the new user account in the Windows domain. You probably don't want to provide a password for the Linux account, as that password will not be kept synchronized with the Windows domain password. If the Linux password exists, however, it will be the fallback should the domain reject the password.
When a user connects to the Linux server via SSH, the user's client sends the password to the server (via an encrypted tunnel). The server will connect to the PDC (primary domain controller) or BDC (backup domain controller) and request an authentication negotiation, known as an SMBNegProt Request. The PDC responds to the SSH server with an SMBNegProt Response, which includes a challenge. The SSH server uses the password it received from the user to respond to the challenge in an SMBsesssetupX Request.
If the password provided by the user at the beginning of the SSH connection is the same one that the user has in the Windows domain, the PDC will issue an affirmative SMBsesssetupX Response. The SSH server will take the affirmative response as authorization to let the user continue logging into the Linux server via SSH. At no time does the password travel in plain text.
RSS
