Description of problem: Many people consider PAM a security problem waiting to happen. Best / most secure practices for sshd have always been to turn it off all but rsa/dsa logins . This way users can't screw the sysadmin by choosing losing passwords. The passwords are effectively random numbers chosen by the computer. The search space is way to large for even the fastest computer to navigate. With PAM enabled all sorts of other authentication methods are allowed, plus the highly non-intuitive pam configuration files come into play. Not being able to turn PAM off is causing me to reevaluate my choice of fedora from a security standpoint. Does one really have to grab the upstream sources and compile oneself in order to get basic security back? Version-Release number of selected component (if applicable): openssh.x86_64 5.8p2-23.fc16 @updates openssh-askpass.x86_64 5.8p2-23.fc16 @updates openssh-clients.x86_64 5.8p2-23.fc16 @updates openssh-server.x86_64 5.8p2-23.fc16 @updates How reproducible: always Steps to Reproduce: 1. enable sshd and try to log in. 2. 3. Actual results: Dec 28 14:53:07 ancho sshd[950]: WARNING: 'UsePAM no' is not supported in Fedora and may cause several problems. Expected results: No gripe about pam being off and honoring the off setting! Additional info: Is this change endorsed by the upstream openssh developers? Fedora shouldn't be overriding these kinds of security settings. Peoples expectations are that when they turn PAM off, that the software doesn't in trojan fashion turn the option back on.
This message is only warning and you can still use 'UsePAM no' but your system probably won't work correctly since pam is needed for multiple things in Fedora, see #757545 There is comment in UsePAM section in sshd_config: # 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'. If you want only publickey authentication then set: UsePAM yes PasswordAuthentication no ChallengeResponseAuthentication no GSSAPIAuthentication no $ ssh -v test@f16-openssh ... debug1: Authentications that can continue: publickey debug1: Next authentication method: publickey debug1: Trying private key: /home/plautrba/.ssh/identity debug1: Offering public key: /home/plautrba/.ssh/id_rsa debug1: Authentications that can continue: publickey debug1: Trying private key: /home/plautrba/.ssh/id_dsa debug1: No more authentication methods to try. Permission denied (publickey).