Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Authenticate users with central user management #486

Closed
mattiaswal opened this issue May 15, 2024 · 4 comments
Closed

Authenticate users with central user management #486

mattiaswal opened this issue May 15, 2024 · 4 comments
Labels
is:question Issue is actually a question.

Comments

@mattiaswal
Copy link

I have been using netopeer2 as netconf server and the users are described in ietf-system and becomes entries in /etc/shadow,
This has worked before, but now (since the ietf-netconf-server YANG upgrade and libnetconf refactor),
it is also required to specify them in in ietf-netconf-server as well.

{
    "ietf-netconf-server:netconf-server": {
	"listen": {
	    "endpoints": {
		"endpoint": [
		    {
			"name": "default-ssh",
			"ssh": {
			    "tcp-server-parameters": {
				"local-address": "::"
			    },
			    "ssh-server-parameters": {
				"server-identity": {
				    "host-key": [
					{
					    "name": "default-key",
					    "public-key": {
						"central-keystore-reference": "genkey"
					    }
					}
				    ]
				},

				"client-authentication": {
				    "users": {
					"user": [
					    {
						"name": "admin",
						"libnetconf2-netconf-server:keyboard-interactive": {
						    "libnetconf2-netconf-server:use-system-auth": {}
						}
					    }
					]
				    }

				}
			    }
			}
		    }
		]
	    }
	}
    }
}

Why this change? Or am I doing something wrong?

@michalvasko
Copy link
Member

This is how it was supposed to work form the very beginning but the YANG module had issues so we opted for the simplest approach. With these updates, using the current drafts, the issues were fixed so we implemented it the way originally intended. In addition to being compliant with the YANG module, this gives explicit control over users that can log into the NETCONF server, not simply all the system users (may not matter to you but there are use-cases when it does).

Nevertheless, we will likely bring the original behavior back as well in the future, and you will be able to explicitly enable all the system users.

@michalvasko michalvasko added the is:question Issue is actually a question. label May 15, 2024
@mattiaswal
Copy link
Author

This is how it was supposed to work form the very beginning but the YANG module had issues so we opted for the simplest approach. With these updates, using the current drafts, the issues were fixed so we implemented it the way originally intended. In addition to being compliant with the YANG module, this gives explicit control over users that can log into the NETCONF server, not simply all the system users (may not matter to you but there are use-cases when it does).

Nevertheless, we will likely bring the original behavior back as well in the future, and you will be able to explicitly enable all the system users.

I think you do not need to define the users in ietf-netconf-server YANG to be comply with the YANG. The yang model states (ietf-ssh-server):

  feature local-users-supported {
    description
      "Indicates that the configuration for users can be
       configured herein, as opposed to in an application
       specific location.";
  }

I interpret it as disable this feature and use shadow/pam on linux.

@michalvasko
Copy link
Member

Okay, but like I said, we do want to support this use-case. How exactly to support the system users has not yet been decided, we may use this feature if it seems sensible but we have tried to have a fixed feature set for now.

@mattiaswal
Copy link
Author

Thanks for the quick answer. I can work around the problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
is:question Issue is actually a question.
Projects
None yet
Development

No branches or pull requests

2 participants