Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
CKPASSWD(8)		   InterNetNews Documentation		     CKPASSWD(8)

NAME
     ckpasswd - nnrpd password authenticator

SYNOPSIS
     ckpasswd [-gs] [-d database] [-f filename] [-u username -p password]

DESCRIPTION
     ckpasswd  is the basic password authenticator for nnrpd, suitable for being
     run from an auth stanza in readers.conf.  See readers.conf(5) for more  in-
     formation on how to configure an nnrpd authenticator.

     ckpasswd  accepts	a  username  and  password from nnrpd and tells nnrpd(8)
     whether that's the correct password for that username.   By  default,  when
     given no arguments, it tries to check the password using PAM if support for
     PAM  was  found  when  INN  was built.  Failing that, it tries to check the
     password against the password field returned  by  getpwnam(3).   Note  that
     these  days most systems no longer make real passwords available via getpw-
     nam(3) (some still do if and only if the  program	calling  getpwnam(3)  is
     running as root).

     When  using  PAM, ckpasswd identifies itself as "nnrpd", not as "ckpasswd",
     and the PAM configuration must be set up accordingly.  The details  of  PAM
     configuration  are  different on different operating systems (and even dif-
     ferent Linux distributions); see "EXAMPLES" below for help getting started,
     and look for a pam(7) or pam.conf(4) manual page on your system.

     When using any method other than PAM, ckpasswd expects all passwords to  be
     stored  encrypted by the system crypt(3) function and calls crypt(3) on the
     supplied password before comparing it to the expected password.  Any  pass-
     word hashing algorithm supported by your libc or libcrypt can be used.

OPTIONS
     -d database
	 Read  passwords  from a database (ndbm, gdbm or dbm format depending on
	 what your system has) rather than by using getpwnam(3).   ckpasswd  ex-
	 pects database.dir and database.pag to exist and to be a database keyed
	 by username with the encrypted passwords as the values.

	 While	INN  doesn't come with a program intended specifically to create
	 such databases, on most systems it's fairly easy to write a Perl script
	 to do so.  Something like:

	     #!/usr/bin/perl
	     use NDBM_File;
	     use Fcntl;
	     tie (%db, 'NDBM_File', '/path/to/database', O_RDWR|O_CREAT, 0640)
		 or die "Cannot open /path/to/database: $!\n";
	     $| = 1;
	     print "Username: ";
	     my $user = <STDIN>;
	     chomp $user;
	     print "Password: ";
	     my $passwd = <STDIN>;
	     chomp $passwd;
	     my @alphabet = ('.', '/', 0..9, 'A'..'Z', 'a'..'z');
	     my $salt = join '', @alphabet[rand 64, rand 64];
	     $db{$user} = crypt ($passwd, $salt);
	     untie %db;

	 Note that this will echo back the password when typed; there are  obvi-
	 ous improvements that could be made to this, but it should be a reason-
	 able  start.	Sometimes a program like this will be available with the
	 name dbmpasswd.

	 This option will not be available on systems without ndbm, gdbm or  dbm
	 libraries.

     -f filename
	 Read passwords from the given file rather than using getpwnam(3).  Each
	 line of the file should look something like:

	     username:$5$Hlb2yXPd$2nOO/QR9P1mnRFr/i6L9ybxbgSDXd4UlatKqbcY4eoB
	     joe:FCjOJnpOo50IE:Old weak hash algorithm used for Joe

	 Each  line  has  at  least  two fields separated by a colon.  The first
	 field contains the username;  the  second  field  contains  a	password
	 hashed  with the crypt(3) function.  Additional colons and data may ap-
	 pear after the encrypted password; that data will  be	ignored  by  ck-
	 passwd.  Lines starting with a number sign ("#") are ignored.

	 INN does not come with a utility to create the encrypted passwords, but
	 OpenSSL can do so and it's also a quick job with Perl (see the one-line
	 example script below).

	 A  line  in filename for the user "user" with the password "pass" would
	 be "user:" followed with the output  of  the  following  command  using
	 SHA-256 as hashing scheme:

	     % openssl passwd -5 pass
	     $5$UIhtJSBOaC0Ap3Vk$nbKgmykshoQ2HmvA3s/nI.X4uhhNHBKTYhBS3pYLjJ6

	 See  the  openssl-passwd(1) man page for the list of hashing schemes it
	 can generate.	You must take one that	your  system  crypt(3)	function
	 handles  (type  "man  3  crypt"  or "man 5 crypt" to find the supported
	 hashing schemes).

	 In case OpenSSL is not installed on your server, you can also	use  the
	 following  Perl  command  which does the same job with SHA-256 (see de-
	 tails below to set "YourSalt" to an appropriate value; 5 is the  prefix
	 for SHA-256, which does not expect any parameters):

	     % perl -le 'print crypt("pass", q{$5$YourSalt$})'
	     $5$YourSalt$V5hqwFg1nhKb5as6md9KTe5b2NyavsMS6dBYVKfp5W7

	 As Perl makes use of crypt(3), you have access to all available hashing
	 schemes  on  your systems.  For instance, if yescript is supported, you
	 can generate an encrypted password with an argument like  "$y$j9T$Your-
	 Salt$"  to  Perl  crypt function, where "y" is the prefix for yescript,
	 "j9T" the parameters passed to crypt_gensalt(3) to generate the  hashed
	 password (these parameters control the yescript configuration, and cor-
	 respond  in  this  example  to the "YESCRYPT_DEFAULTS" flag, the recom-
	 mended flavor which has "j" value in 2023, with cost factor of 4096  as
	 block	count and 32 as block size) and "YourSalt" a string which should
	 be chosen at random and different for each user.  The syntax and  opti-
	 mal length of the salt depend on the hashing scheme (e.g. a length mul-
	 tiple	of  4  for  yescript) and cryptographic recommendations (e.g. at
	 least 32 random bits in length, following NIST  SP 800-63B  recommenda-
	 tions in 2023).

	 To  put  it  in  a nutshell, in the following command, you only have to
	 change the password "pass" and the "YourSalt" random string,  different
	 for each user, and leave the rest of the command as-is:

	     % perl -le 'print crypt("pass", q{$y$j9T$YourSalt$})'
	     $y$j9T$YourSalt$X4tB48vKNDT6mK0vNOc7ppKPWvEsyMg5LwoQfO50r2A

	 A  random salt of 12 characters can be obtained with the following com-
	 mand (the result corresponds to 72 random bits as each character is se-
	 lected in a 6-bit range of 64 possible characters):

	     % perl -le 'print join("",
		   (".", "/", 0..9, A..Z, a..z)[map {rand 64} (1..12)])'
	     k2W/17eJu58r

     -g  Attempt to look up system group corresponding to username and return  a
	 string  like  "user@group" to be matched against in readers.conf.  This
	 option is incompatible with the -d and -f options.

     -p password
	 Use password as the password for authentication rather than  reading  a
	 password using the nnrpd authenticator protocol.  This option is useful
	 only  for testing your authentication system (particularly since it in-
	 volves putting a password on the command line), and does not work  when
	 ckpasswd  is  run  by	nnrpd.	If this option is given, -u must also be
	 given.

     -s  Check passwords against the result of	getspnam(3)  instead  of  getpw-
	 nam(3).   This  function, on those systems that supports it, reads from
	 /etc/shadow or similar more restricted files.	If  you  want  to  check
	 passwords  supplied  to  nnrpd(8) against system account passwords, you
	 will probably have to use this option on most systems.

	 Most systems require special privileges to call getspnam(3), so in  or-
	 der  to  use  this  option you may need to make ckpasswd setgid to some
	 group (like group "shadow") or even setuid root.  ckpasswd has not been
	 specifically audited for such uses!  It is, however, a very small  pro-
	 gram that you should be able to check by hand for security.

	 This configuration is not recommended if it can be avoided, for serious
	 security reasons.  See "SECURITY CONSIDERATIONS" in readers.conf(5) for
	 discussion.

     -u username
	 Authenticate  as  username.  This option is useful only for testing (so
	 that you can test your authentication system easily) and does not  work
	 when  ckpasswd  is run by nnrpd.  If this option is given, -p must also
	 be given.

EXAMPLES
     See readers.conf(5) for examples of nnrpd(8)  authentication  configuration
     that uses ckpasswd to check passwords.

     An example PAM configuration for /etc/pam.conf that tells ckpasswd to check
     usernames and passwords against system accounts is:

	 nnrpd auth    required pam_unix.so
	 nnrpd account required pam_unix.so

     Your system may want you to instead create a file named nnrpd in /etc/pam.d
     with lines like:

	 auth	 required pam_unix.so
	 account required pam_unix.so

     This is only the simplest configuration.  You may be able to include common
     shared files, and you may want to stack other modules, either to allow dif-
     ferent  authentication methods or to apply restrictions like lists of users
     who can't authenticate using ckpasswd.  The best guide is the documentation
     for your system and the other PAM configurations you're already using.

     To test to make sure that ckpasswd is working correctly,  you  can  run  it
     manually  and  then  give it the username (prefixed with "ClientAuthname:")
     and password (prefixed with "ClientPassword:") on standard input.	For  ex-
     ample:

	 (echo 'ClientAuthname: test' ; echo 'ClientPassword: testing') \
	     | ckpasswd -f /path/to/passwd/file

     will  check  a  username  of "test" and a password of "testing" against the
     username and passwords stored in  /path/to/passwd/file.   On  success,  ck-
     passwd  will print "User:test" and exit with status 0.  On failure, it will
     print some sort of error message and exit a non-zero status.

HISTORY
     Written by Russ Allbery <eagle@eyrie.org> for InterNetNews.

SEE ALSO
     crypt(3), nnrpd(8), pam(7), readers.conf(5).

INN 2.8.0			   2023-02-07			     CKPASSWD(8)

Want to link to this manual page? Use this URL:
<https://man.freebsd.org/cgi/man.cgi?query=ckpasswd&sektion=8&manpath=FreeBSD+Ports+15.1.quarterly>

home | help