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

Unable to specify the DHCHAP key (hostkey) to other files. #429

Open
SwatiChaw opened this issue Sep 19, 2024 · 6 comments
Open

Unable to specify the DHCHAP key (hostkey) to other files. #429

SwatiChaw opened this issue Sep 19, 2024 · 6 comments
Assignees
Labels
enhancement New feature or request
Milestone

Comments

@SwatiChaw
Copy link

During my exploration of nvme-stas for auto discovery and connect when NVMe-oF target is configured with authentication, seem couple of things are not working as per expectation.

To set the context, when a target is configured with Uni-directional authentication, the dhchap key need to configure to file /etc/stas/sys.conf.doc at initiator. Based on the details mentioned in the field description following experiment are performed.

# key: The host's DHCHAP key to be used for authentication. This is an
# optional parameter only required when authentication is needed.
# A value starting with "file://" indicates that the Host Key can
# be retrieved from a separate file. Typically, nvme-cli saves the
# Host Key in /etc/nvme/hostkey. For compatibility with nvme-cli,
# nvme-stas defaults to looking for the existence of this file and
# will read the Key from it. Otherwise, you can overwrite the default
# Key by specifying its value here or specifying another file that
# contains an alternate Host Key to use.
# Type: string
# Default: file:///etc/nvme/hostkey

System Details:

Component Version
NVMe-STAS 2.3.1
OS Ubuntu 24.04 LTS
Kernel 6.8.0-45-generic

Experiments Summary:

SNO Description Result Status
1 Configure the DHCHAP key in /etc/nvme/hostkey file and set the correct file path in key filed of /etc/stas/sys.conf.doc file. (eg: key=file:///etc/nvme/hostkey) The test subsystem got connected automatically PASS
2 Delete /etc/nvme/hostkey file and configure the DHCHAP key in /etc/nvme/hostkey2 file. Set the file path /etc/nvme/hostkey2 in key filed of /etc/stas/sys.conf.doc file. (eg: key=file:///etc/nvme/hostkey2) The test subsystem was not connected automatically FAIL
3 Set the DHCHAP key directly into the key filed of /etc/stas/sys.conf.doc file. (e.g: key=DHHC-1:01:3mR5goAg1lA1uFfXqcP+E6HBapjfrksp6fSsMmQGqd1m7+7l:) The test subsystem was not connected automatically FAIL

Could you please explain if it is a right behavior?

@martin-belanger
Copy link
Collaborator

Hi @SwatiChaw - Thanks for reporting this issue.

I guess I should have clarified that the file /etc/stas/sys.conf.doc (with a .doc at the end) is just a template file used to document how to configure nvme-stas. Therefore, nvme-stas does not look at that file at all. Instead, nvme-stas looks for /etc/stas/sys.conf (without a .doc at the end). If /etc/stas/sys.conf is not present (the default), then nvme-stas uses defaults values, which are documented in /etc/stas/sys.conf.doc.

Users that do not want to use the default configuration should create /etc/stas/sys.conf (this can be done with cp /etc/stas/sys.conf.doc /etc/stas/sys.conf) and then edit /etc/stas/sys.conf to make the desired changes.

Please try the same test but using /etc/stas/sys.conf instead of /etc/stas/sys.conf.doc and let me know if that fixes the issue.

Thanks.

@SwatiChaw
Copy link
Author

SwatiChaw commented Sep 20, 2024

Hi @martin-belanger,

Thanks a lot for the clarification.

I have re-run the same test with the suggested changes. All tests Passed this time.

I want to try one more scenario where Target is configured with 4 subsystems (subsystem1, subsystem2, subsystem3, subsystem4), each configured with a different hostkey(from a single host).

For e.g.
A single host (say Host 1) configured with hostkey1, hostkey2, hostkey3, hostkey4 to access each subsystem respectively as shown below -

Host1 configured with hostkey1 ---> to access subsytem1
Host1 configured with hostkey2 ---> to access subsytem2
Host1 configured with hostkey3 ---> to access subsytem3
Host1 configured with hostkey4 ---> to access subsytem4

During the manual connect, using nvme-cli, a different hostkey can be passed with each connect command from a single host to connect to different subsystems. But I am not sure how to achieve the same with auto-discovery. Could you suggest if this scenario can be tested using nvme-stas? and if possible, how to achieve this?

@martin-belanger
Copy link
Collaborator

IIRC, you should be able to manually configure each subsystem in /etc/stas/stacd.conf and specify dhchap-ctrl-secret for each subsystem. Basically, in /etc/stas/stacd.conf you can configure each subsystem with the exact same parameters (or at least very similar parameters) that you would pass to nvme-cli.

For example:

controller = transport=tcp;traddr=192.168.10.1;dhchap-ctrl-secret=<some-secret>;nqn=nqn.1988-11.com.dell:PowerSANxxx:01:20210225100113-454f73093ceb4847a7bdfc6e34ae8e28;   etc...

This is something that I have not tested much because at the time that I implemented nvme-stas authentication was still fairly new in libnvme and going through constant changes. This is something I will need to revisit when I get a chance.

@martin-belanger
Copy link
Collaborator

Forgot to mention that when you're done changing the configuration you can apply the changes as follows:

sudo systemctl reload stacd

OR

sudo systemctl restart stacd

@SwatiChaw
Copy link
Author

SwatiChaw commented Sep 23, 2024

Hi @martin-belanger

Thanks for sharing the details.
My query was regarding the dhchap-secret(hostkey) for unidirection authentication.
nvme-cli gives the option to specify a new dhchap-secret(hostkey) for the same hostnqn to connect to different subsystems in the target ->

root# nvme connect --help
Usage: nvme connect [OPTIONS]

Connect to NVMeoF subsystem

Options:
[ --transport=, -t ] --- transport type
[ --nqn=, -n ] --- subsystem nqn
[ --traddr=, -a ] --- transport address
[ --trsvcid=, -s ] --- transport service id (e.g. IP
port)
[ --host-traddr=, -w ] --- host traddr (e.g. FC WWN's)
[ --host-iface=, -f ] --- host interface (for tcp
transport)
[ --hostnqn=, -q ] --- user-defined hostnqn
[ --hostid=, -I ] --- user-defined hostid (if default
not used)
[ --dhchap-secret=, -S ] --- user-defined dhchap key (if
default not used)

nvme connect -t tcp -n ${subsystem1} -a 10.129.136.200 -s 4420 --hostnqn=nqn.2014-08.org.nvmexpress:uuid:$hostid --hostid=$hostid --dhchap-secret=$hostkey1

nvme connect -t tcp -n ${subsystem2} -a 10.129.136.200 -s 4420 --hostnqn=nqn.2014-08.org.nvmexpress:uuid:$hostid --hostid=$hostid --dhchap-secret=$hostkey2

nvme-cli allows connecting to multiple subsystems, from the same host, with a different hostkey,

Is this supported in automated discovery? I don't see "dhchap-secret" specified in /etc/stas/stacd.conf

@martin-belanger
Copy link
Collaborator

Ah! Now I see what you mean. The option to specify a different host key (dhchap-secret) per controller is not currently supported by nvme-stas. However, adding support should not be too complicated. I can have a look at it.

On the other hand, I'm not sure in which circumstances one would want to configure multiple host keys. There's already a lot of keys to configure all over the place. If one has to do this on several hosts (think 100s of hosts) it can get pretty tedious.

By the way, I don't know if you're familiar with the work done by the nvmexpress group (https://nvmexpress.org/), but you may want to have a look at TP8019 - Authentication Verification Entity for_DH-HMAC-CHAP 2022.12.14a. This document discusses an authentication server where all the keys/secrets can be configure in a central place.

@martin-belanger martin-belanger self-assigned this Oct 14, 2024
@martin-belanger martin-belanger added the enhancement New feature or request label Oct 14, 2024
@martin-belanger martin-belanger added this to the 2.4 milestone Oct 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants