Cannot save "SSH Connections"

[awasb]

Ran into this on my test system today.

https://jira.ixsystems.com/browse/NAS-116580?jql=text%20~%20ssh%20ORDER%20BY%20created%20DESC

Could someone please verify?

 

[Samuel Tai]

I can confirm this behavior in my 13.0-RELEASE system. The UI is unable to create a new SSH connection, although it can create a new SSH keypair.

 

[Samuel Tai]

It's still possible to create a SSH connection using the API.

1. Run midclt call keychaincredential.query | jq to find the index number of the SSH keypair needed for the new SSH connection. This will be the id property of the JSON entry corresponding to the SSH keypair.
2. Run midclt call keychaincredential.remote_ssh_host_key_scan '{ "host": "<name or IP of remote SSH host>", "port": 22, "connect_timeout": 10 }' to obtain the remote SSH system's host keys.
3. I suspect this UI behavior is due to upstream OpenSSH trying to deprecate ssh-rsa due to it being vulnerable to SHA-1 chosen prefix attacks. If the host scan reveals multiple host keys, select any of the non-ssh-rsa keys for the next step.
4. Run midclt call keychaincredential.create '{ "name": "<Desired name of your SSH connection>", "type": "SSH_CREDENTIALS", "attributes": { "host": "<name or IP of remote SSH host>", "port": 22, "username": "<SSH login account>", "private_key": <index from step 1>, "remote_host_key": "<non-ssh-rsa host key from step 2>", "cipher": "STANDARD", "connect_timeout": 10 } }'
5. The new SSH connection should now appear in the UI.

I tested this on my 13.0-RELEASE system, and it seems to work for me.

 

[awasb]

Thanks a lot! Worked fine. (Though I use different ports. Adapt accordingly. Could not test ssh-rsa, too, since I'm using ed25529 ...)

 

[diggerydoo]

It's still possible to create a SSH connection using the API.

1. Run midclt call keychaincredential.query | jq to find the index number of the SSH keypair needed for the new SSH connection. This will be the id property of the JSON entry corresponding to the SSH keypair.
2. Run midclt call keychaincredential.remote_ssh_host_key_scan '{ "host": "<name or IP of remote SSH host>", "port": 22, "connect_timeout": 10 }' to obtain the remote SSH system's host keys.
3. I suspect this UI behavior is due to upstream OpenSSH trying to deprecate ssh-rsa due to it being vulnerable to SHA-1 chosen prefix attacks. If the host scan reveals multiple host keys, select any of the non-ssh-rsa keys for the next step.
4. Run midclt call keychaincredential.create '{ "name": "<Desired name of your SSH connection>", "type": "SSH_CREDENTIALS", "attributes": { "host": "<name or IP of remote SSH host>", "port": 22, "username": "<SSH login account>", "private_key": <index from step 1>, "remote_host_key": "<non-ssh-rsa host key from step 2>", "cipher": "STANDARD", "connect_timeout": 10 } }'
5. The new SSH connection should now appear in the UI.

I tested this on my 13.0-RELEASE system, and it seems to work for me.

can't seem to run the command for step 4 the shell spits out an error

[keychain_credential_create] A dict was expected
Traceback (most recent call last):
File "/usr/local/lib/python3.9/site-packages/middlewared/main.py", line 140, in call_method
result = await self.middleware._call(message['method'], serviceobj, methodobj, params, app=self,
File "/usr/local/lib/python3.9/site-packages/middlewared/main.py", line 1262,in _call
return await methodobj(*prepared_call.args)
File "/usr/local/lib/python3.9/site-packages/middlewared/service.py", line 495, in create
rv = await self.middleware._call(
File "/usr/local/lib/python3.9/site-packages/middlewared/main.py", line 1262,in _call
return await methodobj(*prepared_call.args)
File "/usr/local/lib/python3.9/site-packages/middlewared/schema.py", line 974, in nf
args, kwargs = clean_and_validate_args(args, kwargs)
File "/usr/local/lib/python3.9/site-packages/middlewared/schema.py", line 932, in clean_and_validate_args
value = attr.clean(args[args_index + i])
File "/usr/local/lib/python3.9/site-packages/middlewared/schema.py", line 596, in clean
raise Error(self.name, 'A dict was expected')

 

[Samuel Tai]

Did you replace the fields between <> in step 4 with the correct values for your circumstance? Also, pay attention to the distinction between single and double quotes. They're in the locations they are to make the shell happy.

 

[diggerydoo]

Did you replace the fields between <> in step 4 with the correct values for your circumstance? Also, pay attention to the distinction between single and double quotes. They're in the locations they are to make the shell happy.

I believe I replaced them with the correct values, the only one I'm not sure about is the host key

 

[Samuel Tai]

Step 2 will retrieve the remote host keys. E.g., you'll get output like:

ssh-ed25519 <Text of ED25519 key>
ssh-rsa <Text of RSA key>
ecdsa-sha2-nistp256 <Text of DSA key>

Pick one of the non-RSA keys, including the ssh-* prefix, and include that as your host key call.

 

[diggerydoo]

Step 2 will retrieve the remote host keys. E.g., you'll get output like:



Pick one of the non-RSA keys, including the ssh-* prefix, and include that as your host key call.

Thank you that was the problem