On your last question, the answer is yes. Look at /etc/ssh/sshd_config. The commented paragraph above "UsePAM yes" tells you which options to disable, and still use PAM for session control. If you allow root logins, (which I wouldn't for administrative access) you don't want to use password authentication because it is a well know target.
A user can use putty's keygen program to generate and save a key pair. Then loading in the private key, on the top of the dialog, an openssh public key is displayed which can be highlighted can copied.
Also look at the sshd_config, ssh_config and sshd manpages. There is an option "AllowUsers" which can list the only users allowed to log in using ssh. A users entry can be of the form username@host, which could limit where a user can log in from. The public key in the authorized_keys file can contain a from= field, but a user logging in could edit it. This is more useful as a means for a security conscientious user to limit where they can log in from.
One problem with Public Key Authentication (PKA) is that you can't enforce the use of a passphrase to protect the users private key.
---
IMHO if you will generate a key pair and distribute it to the users to use, you don't want to do this for a root key pair. The more people with the root private key, the more likely that it will become lost. If it does a strong passphrase will protect it, but some users may save the key somewhere on their laptop. I think it would be better to use a regular account. A user can login, and then use sudo or su to root.
---
Excerpt from sshd_config:
Code:
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
/etc/pam.d/ssh:
Code:
#%PAM-1.0
auth include system-auth
account required pam_nologin.so
account include system-auth
password include system-auth
# pam_selinux.so close should be the first session rule
session required pam_selinux.so close
session include system-auth
session required pam_loginuid.so
# pam_selinux.so open should only be followed by sessions to be executed in the
user context
session required pam_selinux.so open env_params
session optional pam_keyinit.so force revoke
Let's look at system-auth:
Code:
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth required pam_deny.so
account required pam_unix.so
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid < 500 quiet
account required pam_permit.so
password requisite pam_cracklib.so try_first_pass retry=3
password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password required pam_deny.so
session optional pam_keyinit.so revoke
session required pam_limits.so
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session required pam_unix.so
Using PublicKey authentication, I believe that the highlighted lines are the ones that are used.
---
Also look at the manpages for pam_access and access.conf. Having a "session required pam_access" entry in /etc/pam.d/sshd should give you control by editing /etc/security/access.conf. Add entries for the sshd service containing the user's name and valid access point. Or you could restrict all ssh logins to your subnet.
---
I only use PKA, but I haven't done these things with PAM, so be sure to experiment and test it out before implementing. Maybe a real linux admin will chime in and let us know how full of it I am!
Good Luck!
How to configure tcpwrapper for ssh for a user?
