Host/Target Setup and Configuration
This topic describes how to setup the networking between the host system and the target system, target user account setup and environment for cross-compilation.
DRIVE OS Linux OEM-Config
DRIVE OS LINUX ships with an OEM-config application that allows the end-user to setup a user account using wizard prompts in the UART interface. When the target device boots for the first time after flashing, it automatically runs OEM-config.
Before the target system boots for the first time, you must start a serial application on the host computer. For more instructions, check the Terminal Utility section in the SDK documentation.
Please use the following steps to set up the DRIVE OS LINUX on the target:
1. Allow the system to power on and boot up the operating system.
Once the operating system boots, OEM-config will start and splash the UI on the terminal as shown below. EULA prompt provides Yes, No, and Refresh options. Choosing an option and pressing ENTER executes the choice to OEM-config. To accept the EULA, choose Yes. To reject choose No. To display the EULA contents again, choose Refresh.
Accept the EULA to continue OEM-config to the next steps. Rejecting the EULA safely powers down the system.
2. The first user created is an admin user. Non-admin users can be added in later steps. Click OK.
3. Enter the full real name of the user.
4. Prepare to create a username and password for the first (admin) user.
5. Create a username and password for the first (admin) user.
You must provide a username that satisfies the following regex:
^[a-z_][a-z0-9_-]{0,31}$
This implies that:
• The username must not be empty.
• The username must start with only lowercase letters or an underscore(_).
• The second and subsequent characters can be a lowercase letters, numbers, underscores(_), or a hyphen(-).
• The username must be less than or equal to 32 characters long.
6. Create a password for the first (admin) user.
7. Re-enter the same password for your user account, then select OK and press ENTER.
8. The system will warn the user if the password is weak and recommends for a correction. Select No and press ENTER to go back step 4 and change the password. Otherwise, select Yes and press ENTER to move forward.
The secure login feature from NVIDIA DRIVE OS provides better security for SSH connections by using ECDSA based algorithms.
It also offers persistence of SSH keys and user account metadata across flashing so that the system recognizes the host and the users even after a system reflash.
NVIDIA recommends enabling the secure login feature, and to enable select Yes and press ENTER. Else, if you wish to disable this feature, select No and press ENTER. Entering <Refresh> and ENTER displays the secure login feature prompt message again.
9. If you would like to add another user, select Yes. Otherwise, select No.
10. After this prompt, OEM-config configures the system. The end-user must ensure not to power off the system after pressing <Ok> below. After about 10 seconds, you get the prompt from step 9.
11. At this point, OEM-config has completed the system setup. Press <Ok> to let the system boot to the login prompt.
DRIVE OS Linux User Management
- Steps to Change the Username and Password
NVIDIA DRIVE OS Linux uses Ubuntu tools to manage users. Only admin-users (i.e., sudoers or root user) can change user accounts. The following steps assume that you are an admin user. Enter the password of your current user.
Steps to Change the Username and Password
The following steps describe how to change your username and password in the DRIVE OS Linux filesystem.
Note: | Whenever any change is made to the filesystem such as adding/modifying/removing user login information, ensure that all data is saved prior to resetting. Execute a software shutdown command, such as halt, shutdown, or reboot to the target system to avoid data corruption; otherwise, file system corruption may occur. Once the target system is shut down, you may use physical/electrical shutdown or reset commands, such as tegrareset or aurixreset in the AURIX command terminal. |
Changing the Username
1. Enable administrative account.
• Enable the root administrative account by setting a password for the root account. Use the following command to set a password for root account. You will be prompted for the password of your current user.
$ sudo passwd
2. Close existing user sessions.
• Log out of all sessions, including GUI and consoles of the user that you are changing the username for. You cannot change the username if a session is still alive.
• Use the following command to exit console sessions:
$ exit
3. Log into the system as root account.
• After completing step #2, you will be presented with a login prompt. Proceed to log in using the credentials you established for the root account.
4. Change the username.
• Change the username of the user from ${USERNAME1} to ${USERNAME2} with the following commands:
$ usermod -m -d /home/${USERNAME2} -l ${USERNAME2} ${USERNAME1}
$ groupmod -n ${USERNAME2} ${USERNAME1}
• Log out of the root account using the following command:
$ exit
You have successfully changed the username. Proceed to log in with the new username.
Changing the Password
Note: | When changing the password for the current user, enter the command without sudo as listed below. Entering sudo passwd changes the password for the root user. |
1. Enter the following command to update password.
$ passwd
Enter your existing password and enter the new password.
Changing password for <user>.
(current) UNIX password:
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully.
passwd: password updated successfully.
2. Enter the current password and then the new password.
Adding a Non-Admin User
1. Execute adduser with the new username as input and fill in the information when prompted.
$ sudo adduser <user>
# Where,
# <user> is the username to be added
# <user> is the username to be added
Note: | Non-Admin user can be added to specific groups to get privileged access to components that is otherwise accessible only if the user is root. See section ' Common Groups Used in DRIVE OS Linux Filesystems'. Ensure the Non-Admin user is not added to the 'sudo' or 'adm' group, as this will allow them to run any commands using sudo. |
2. Execute usermod to add the user to the required groups as per the use case requirements of the user.
$ sudo usermod -aG <groups> <user>
# Where,
# <groups> is the list of groups separated by comma.
# <user> is the username of the user.
Example
$ sudo adduser test
Adding user `test' ...
Adding new group `test' (1001) ...
Adding new user `test' (1001) with group `test' ...
Creating home directory `/home/test' ...
Copying files from `/etc/skel' ...
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
Changing the user information for test
Enter the new value, or press ENTER for the default
Full Name []:
Room Number []:
Work Phone []:
Home Phone []:
Other []:
Is the information correct? [Y/n] Y
Adding an Admin User
1. Create a non-admin user <user> by following the instructions in the section Adding a Non-Admin User above.
2. Make the created user <user> an admin user by adding the user to all the groups specified in 'Common Groups Used in DRIVE OS Linux Filesystems' following the instructions in the section Adding a Non-Admin User above.
Common Groups Used in DRIVE OS Linux Filesystems
Group | Description |
adm | Group adm is used for system monitoring tasks. Members of this group can read many log files in /var/log. |
audio | This group can be used to give a set of users, access to sound devices. (e.g., sound timers) |
dialout | Members of this group gets full and direct access to serial ports. |
plugdev | Allows members to mount (only with the options nodev and nosuid, for security reasons) and umount removable devices through pmount. |
sudo | Members of this group can execute any command with sudo (/etc/sudoers) |
video | This group can be used to give a set of users access to a video device (like the framebuffer, the videocard or a webcam). Users may require to be added to this group to run DRIVE OS graphics samples. |
debug | This group can be used to give a set of users, access to profile and debug data of GPUs in the system. |
Removing a User
The steps to remove an admin or non-admin users are identical. Removing users using the steps below also removes their /home/<user> directory.
To remove a user, enter:
$ sudo deluser --backup --remove-home <user>
This backs up and creates a tarball (<user>.tar.bz2) of the deleted user data in the current working directory.
Setting Password as an Admin User
As admin-users are sudoers, they can set the password of any user account with username <username> using the command below. Enter the password of your current user.
$ sudo passwd <username>
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully.
passwd: password updated successfully.
Updating Self-Password as a Non-Admin User
Note: | When changing the password for the current user, enter the command without sudo as listed below. Entering sudo passwd changes the password for the root user. |
Non-admin users can only update their own passwords. The steps below update your user account’s password:
1. Enter the following command:
$ passwd
Enter your existing password and enter the new password.
Changing password for <user>.
(current) UNIX password:
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully.
passwd: password updated successfully.
2. Enter the current password and then the new password.
Disabling user account
The below step allows an admin user (i.e., sudoer) to disable the user account with a username $USER:
$ sudo usermod --expiredate 1 $USER
Disabling the user account ensures, that user account is unusable in any context in the filesystem. The disabled user ($USER) can be re-enabled using the step below:
$ sudo usermod --expiredate “” $USER
Disabling the Secure Login Feature
Secure login feature disablement removes NVIDIA DRIVE OS security SSH config and disables persistence service. There are two (2) options to disable the secure login feature:
1. If the end-user wants to disable the secure login feature, then one option exists at the time of OEM-config.
1. Once the secure login feature disabled, it remains disabled even after bootburn re-flashing the board.
2. To reset the state of secure login, format the persistent partition (/dev/vblkdev2) and then bootburn flashing the board.
2. The second option is to create a (touch can do this) file in the following path:.
/persistence/driveos/security/etc/nvidia/disable_secure_login_feature
1. To make option #2 to work, end-user must reboot the board.
2. To restore SSH config, use the following command:
cp /usr/share/openssh/sshd_config /etc/ssh/
DRIVE OS Linux SSH Server
The shipped NVIDIA DRIVE OS LINUX filesystem driveos-oobe-rfs contains SSH server. However, driveos-core-rfs does not include SSH server. Use the steps below to install SSH server.
Install/Update SSH Server
1. Ensure platform is connected to the internet
2. Update the existing apt database:
# apt-get update
3. Install SSH server package:
# apt-get install ssh
4. When prompted by apt-get (see prompt below), choose the option keep the local version currently installed to ensure DRIVE OS SSH configuration is applied.
Setting Up SSH Server Service
After SSH server is available in the filesystem, use the steps below as root user to start and configure SSH server service to run on every boot:
1. Remove the stamp file to unblock SSH server:
$ sudo rm -f /etc/ssh/sshd_not_to_be_run
2. Start SSH server service on the current boot:
$ sudo systemctl start ssh
3. Start service to add SSH host-keys to the target:
$ sudo systemctl start nv_ssh_host_keys
After completing the steps above, the SSH server service is started. Additionally, it runs on every boot. SSH clients may now connect to this SSH server.
SSH Server Configuration File
NVIDIA DRIVE OS Linux contains an SSH server configuration file sshd_config that pre-configures the following :
• Permits only connections with Elliptic Curve Digital Signature Algorithm (ECDSA) host key.
• Disables compression.
• Permits specific key exchange, host signature, and session encryption algorithms.
NVIDIA DRIVE OS Linux recommends that you configure strong security options for the following SSH parameters:
• Client Verification via key exchange: Parameter KexAlgorithms from sshd_config to set the supported key type(s) for client verification.
• Host Signature: Parameter HostbasedAcceptedKeyTypes from sshd_config to set the supported key type(s) for host verification.
• Session Encryption: Parameter Ciphers from sshd_config to set the supported SSH session encryption algorithm(s).
The table below suggests recommended strong values to enable recommended security features; the default option is highlighted in the table below.:
Option | Client Verification | Host Signature | Session Encryption |
1 | ecdh-sha2-nistp256 ECDH [SP 800-56A] over secp256r1 [SEC2-V2] with SHA-256 [FIPS 180-4] | ecdsa-sha2-nistp256-cert-v01@openssh.com ECDSA [FIPS 186-4][ANS X9.62] over secp256r1 [SEC2-V2] with SHA-256 [FIPS 180-4] | aes128-gcm@openssh.com GCM [SP 800-38D] with AES-128 [FIPS 197] |
2 | ecdh-sha2-nistp384 ECDH [SP 800-56A] over secp384r1 [SEC2-V2] with SHA-384 [FIPS 180-4] | ecdsa-sha2-nistp384-cert-v01@openssh.com ECDSA [FIPS 186-4][ANS X9.62] over secp384r1 [SEC2-V2] with SHA-384 [FIPS 180-4] | aes256-gcm@openssh.com GCM [SP 800-38D] with AES-256 [FIPS 197] |
3 | (Default) ecdh-sha2-nistp521 ECDH [SP 800-56A] over secp521r1 [SEC2-V2] with SHA-512 [FIPS 180-4] | (Default) ecdsa-sha2-nistp521-cert-v01@openssh.com ECDSA [FIPS 186-4][ANS X9.62] over secp521r1 [SEC2-V2] with SHA-512 [FIPS 180-4] | (Default) aes256-gcm@openssh.com GCM [SP 800-38D] with AES-256 [FIPS 197] |
Switching Options in the SSHD Configuration File
DRIVE OS Linux contains the snippets for all three (3) options with exactly one option (option 3) enabled as shown below. The options 1, 2, and 3 are mutually exclusive and exactly only one option can be active at a time.
# option 1
# Use algorithms as per DRIVE recommended options: 1,2, or 3
#KexAlgorithms ecdh-sha2-nistp256
#HostbasedAcceptedKeyTypes ecdsa-sha2-nistp256-cert-v01@openssh.com
#Ciphers aes128-gcm@openssh.com
# option 2
#KexAlgorithms ecdh-sha2-nistp384
#HostbasedAcceptedKeyTypes ecdsa-sha2-nistp384-cert-v01@openssh.com
#Ciphers aes256-gcm@openssh.com
# option 3 (default)
KexAlgorithms ecdh-sha2-nistp521
HostbasedAcceptedKeyTypes ecdsa-sha2-nistp521-cert-v01@openssh.com
Ciphers aes256-gcm@openssh.com
To switch from one option to another
1. Comment out the three (3) lines corresponding to the current option.
2. Uncomment the three (3) lines corresponding to the new option.
3. Restart SSHD using the command below as the root user:
$ sudo systemctl restart ssh
As an example, assume that the current option is option 3 (from the snippet above).
To switch to option 2, execute the following steps:
1. Comment out the three (3) lines following # option 3.
2. Uncomment the three (3) lines from the line below # option 2 until the line above # option 3.
3. Restart SSHD using the command below as the root user:
$ sudo systemctl restart ssh
4. SSHD now uses encryption algorithms from option 2.
SSH Key-Based Authentication from Clients to Server
DRIVE OS Linux shipped SSHD tries key-based authentication first and falls back to password-based authentication when the former is unavailable. The following sections describe how to set up a user-specific authentication key, add it to the list of trusted-keys, and use the key to authenticate (instead of the password) to the SSH server.
Create a new key-pair at the client side
The first step is to create a public/private key pair using the command:
$ ssh-keygen -t ecdsa
Continue through the prompts by pressing ENTER and these steps save the key to ~/.ssh.
Set up the server side to register key
The next step is to add the contents of the client (user-specific authentication) public key ~/.ssh/id_ecdsa.pub into the text file ~/.ssh/authorized_keys.
Use the new key at the client side to connect to the server
Only the user who created the key can log in to the SSHD server (using the registered keys). At the client side, connect to the server using the ssh command:
$ ssh <user>@<target_ip>
The setup done above is one-directional (i.e., from client to server). To similarly setup in a reverse direction (i.e., from server to client), the above steps must be swapped with regards to client/server and executed to setup key-based authentication from the server to client-side.