Doc /

INN - authentication

< INN - filtering spam, cleanfeed and postfilter | Configure the INN nntp server (2021/2022) | INN - nocem >

What is authentication

Authentication is a way of knowing who can post to your server. AFAIK, INN can use most usual systems. On Linux, the simpler is to create a system account for each user, but you may not want to do this.

Why you may not ask for it:

here the arguments of aioe, one of the older news server, with no authentication.

in case it will be removed by article expiration, here the quotes: has been running without authentication for about 22 years and 
has never caused major abuse problems.
Authentication has two problems: it must be managed and it requires the 
retention of personal data.
A system without authentication is much easier to manage because the 
administrative part consists only in keeping the part of the logs that 
indicates who posted each message. You have no other obligations.
When creating an authentication-protected system, you must allow users 
to register in a way that makes hard to create fake identities. Nowadays 
this takes time, a lot of system resources and in any case it doesn't 
guarantee you won't have problems. Doing without authentication means 
you don't have to worry about CAPTCHAs, users who use 1234 as passwords, 
people asking you what 'username' means.
In recent years, managing users' personal data has become complicated 
for small projects. Since name, surname, email and date of birth are 
considered personal data, if you collect this data to identify your 
users when they register then the processing of this data requires 
cautions. You have to keep this data safe and this is expensive; you 
have to equip yourself with procedures to manage this data and this is 
complicated and requires writing several documents; you must have 
systems that allow you to identify who is accessing the data and which 
data is being read. If you don't do these things you risk a hefty fine.
Then you have to manage the crazy guys: if someone writes you an email 
and asks you what personal data you have on file, you have to answer 
quickly and correctly even if he registered three years ago and logged 
in twice in total. If someone asks you to delete his personal data you 
must obey and you must also delete them from the backups. For long-lived 
servers this can become a serious problem. If you give up 
authentication, you solve all these problems at once: you simply do not 
collect, process and store personal data of users.

How to do it

If you want to allow access only to authenticated users, the doc is here:

in french, may be translated soon by his author

automatic translation with deepl, better than nothing, but use with care:

The readers.conf file

Once the noreader parameter in pathetc/inn.conf is set to false (the default), all connections initiated by remote hosts not specified in pathetc/incoming.conf and connections initiated by remote hosts specified in pathetc/incoming.conf but sending the MODE READER command are handled by the nnrpd authentication daemon.

The pathetc/readers.conf file is used by nnrpd to determine if a read or write request to the server is allowed or not.

The authentication will be done from a file containing all the necessary information (username and password). To create this file we will use the program /usr/bin/htpasswd.

This program is not provided by the inn2 package and is installed on your system if you have installed an HTTP server such as Apache httpd or lighthttpd.

If you do not want to install an HTTP server on your server, this online tool should be useful.

In any case, this file will contain a line for each user you want to allow access to.

news ~$ htpasswd -nbd toto sesame >> /var/lib/news/users news ~$ chmod 640 /var/lib/news/users

The previous command will add to the pathdb/users file the user toto with the password sesame.

You can also edit the pathdb/users file with a simple text editor and add the authentication information provided by an online generator.

The important thing is that each line of the file must have a unique user:password pair.

Unfortunately the `-d' option of htpasswd will truncate your passwords to 8 characters.

Be careful not to exceed this limit, otherwise your users will not be able to be properly authenticated.

Once your users are created, change the access permissions to this file to allow nnrpd to extract the information it needs.

Now that the pathdb/users file is created and duly filled in, we can tackle the configuration of the permissions themselves.

It is possible to manage these authentications and authorizations very finely and by different means, however we will be content to authorize read access to all the groups available on your server to anyone who requests it and to authorize write access only to authenticated users.

To do this we will create an authentication class and two access classes as follows:

auth all {

    auth: "ckpasswd -f /var/lib/news/users"
    default: "anonymous"


Above we tell nnrpd that authentications will be done using the ckpasswd program (auth: "ckpasswd -f /var/lib/news/users") which will check the authentication information in the /var/lib/users file we just created. However, we also tell it that a non-authenticated user will have the name anonymous (default: "anonymous").

access full {

    users: "*,!anonymous"
    newsgroups: "*,!control,!control.*,!junk"


Next we describe the access permissions that all users except anonymous will have (users: "*,!anonymous").

Here we allow access to all groups except control (and all its subgroups) and junk (newsgroups: "*,!control,!control.*,!junk").

access read_only {

    users: anonymous
    newsgroups: "*,!control,!control.*,!junk"
    access: R


Finally, we define the access permissions for the unauthenticated user anonymous.

Here we give him access to the same groups as if he was authenticated but read-only (access: R).

Note that if you define several access classes, only the last corresponding class will be taken into account by nnrpd (last win).

You can comment out all the other lines in this file.

You can find all kinds of useful information in the man page of readers.conf (man readers.conf).

Translated with (free version)

Readers.conf doc

I didn't (yet?) use this, so have no personal info on it.

< INN - filtering spam, cleanfeed and postfilter | Configure the INN nntp server (2021/2022) | INN - nocem >