Method to flash a rootfs without including SSH

I am customizing the rootfs on Orin Nx and would like the final rootfs to be without SSH, at least not including the SSH server.

However, I believe that the flash script provided by Nvidia, specifically ‘’ and ‘’, expects sshd to be present in the rootfs. Since I do not fully understand how SSH is utilized in recovery images and the like, I am unable to decide how to correctly modify the script.

In order to use a rootfs without SSH on Orin NX, I would appreciate advice on how I should edit the script or if there is a better alternative approach.
Thank you for your time.

initrd flash requires ssh. But initrd flash is using initrd to flash. Not directly the rootfs.

Hi, Wayne

I might not fully understand the proposed approach.
Is the intention to ‘copy sshd from a different location instead of rootfs when creating a recovery image with’?
Also, could you please explain the scope of using SSH within the created recovery image?
When is this recovery image used other than during initrd flash? And, does it need to include SSH at those times as well?


I don’t think removing ssd from your rootfs will make your flash failed. You can try it first.

It has been executed. If the ssh package is not included in the rootfs, errors occur when copying the contents of recovery_copy_binlinst.txt and during the editing of the Filesystem in prepare_sshd_files

please share me the log and the command when running above.

Since it results in an error at the stage before flashing, I only have the console log from the Host PC, but here it is. Thank you.
hostPC_console.log (18.8 KB)

Hi koichi.tanoiri,

I’ve verified the following workflow on the Orin Nano devkit with JP5.1.2(R35.4.1).
The basic idea is creating a golden rootfs w/o SSH server/client.
It should meet your requirement of flashing rootfs w/o SSH.

1. Flash your board normally
$ sudo ADDITIONAL_DTB_OVERLAY_OPT="BootOrderNvme.dtbo" ./tools/kernel_flash/ --external-device nvme0n1p1 -S 10GiB -c tools/kernel_flash/flash_l4t_external.xml -p "-c bootloader/t186ref/cfg/flash_t234_qspi.xml"  --showlogs --network usb0 jetson-orin-nano-devkit internal

Remove SSH server and client
$ sudo apt-get --purge remove openssh-server
$ sudo apt-get --purge remove openssh-client

2. Clone rootfs golden image from NVMe w/o SSH server/client
Put the target device into recovery mode

Run the following command to enter initrd
$ sudo ./tools/kernel_flash/ --initrd jetson-orin-nano-devkit mmcblk0p1

(plug USB drive)
$ mount /dev/sda /mnt
$ dd if=/dev/nvme0n1p1 of=/mnt/golden.img.raw
$ sync
$ umount /mnt

(plug USB drive and copy golden.img.raw to PC)
a. Verify if the golden.img.raw could be mounted successfully
 $ sudo mount -t ext4 -o loop golden.img.raw /mnt
 $ sudo umount /mnt
b. copy golden image to your BSP package
 $ cp golden.img.raw <Linux_for_Tegra>/bootloader/system.img.raw
c. Generate system.img
 $ sudo ./mksparse --fillpattern=0 system.img.raw system.img

3. Flash your board with existed system image(w/o SSH server/client)
$ sudo EXTOPTIONS="-r" ADDITIONAL_DTB_OVERLAY_OPT="BootOrderNvme.dtbo" ./tools/kernel_flash/ --external-device nvme0n1p1 -S 10GiB -c tools/kernel_flash/flash_l4t_external.xml -p "-c bootloader/t186ref/cfg/flash_t234_qspi.xml"  --showlogs --network usb0 jetson-orin-nano-devkit internal

1 Like

Hello Kevin,

Thank you for your response. I understand that the method you suggested, at the point of “1. Flash your board normally,” assumes that the rootfs already includes SSH. Is my understanding correct?
If so, I believe the method you suggested would result in SSH being excluded only from the system.img. This implies that other images, such as recovery.img, would contain SSH.
I apologize for the lack of detail earlier, but I am currently using a script modified to work in an environment where only recovery.img includes SSH. I have confirmed that this script can write, and I expect it to have a similar effect to the method you proposed.
However, I’m not fully clear on when recovery.img is invoked, so I’m concerned about the security implications of being able to connect via SSH while recovery.img is operating (for instance, during updates, would it be possible to connect via SSH?).

Therefore, I would like to understand:

  • Is it possible to flash without including SSH in recovery.img and similar files?
  • If it’s highly complex, in what scenarios is recovery.img used, and what precautions should be taken (or are they unnecessary)?

I look forward to your guidance.


Yes, initrd flash would use SSH under <Linux_for_Tegra>/rootfs

recovery.img is used in image-based OTA
If you remove ssh from recovery image, that does not affect OTA, but you can never access the device remotely once the device meet any issue in OTA.

May I know what’s your use case? Would your product have network or remote access or OTA?

Thank you for your response.

If it’s possible, that would indeed be exactly what I’m looking for. I thought ssh was necessary in the recovery.img because when I removed the ssh content required by, the initrd flash script stopped due to an ssh failure. If the flash process without including ssh in recovery.img or system.img can be achieved through not too complex modifications to the script, I would appreciate your guidance on this method.

While the product does have network capabilities, I would like to prevent direct access like ssh. The details of updating via network are still being worked out, but the idea is to only put the img in a specific area via network and perform the update operation on the product side. However, if you can complete the flash process without including ssh in recovery.img and system.img, there is no problem without digging any deeper.

I look forward to your assistance.

Please refer to the following steps to remove SSH server in recovery image.

1. Remove the following line in <Linux_for_Tegra>/tools/ota_tools/version_upgrade/recovery_copy_binlist.txt
-	all:<ROOTFS>/usr/sbin/sshd:/bin/sshd

2. Remove the following line in <Linux_for_Tegra>/tools/ota_tools/version_upgrade/
-	/bin/sshd -E /tmp/sshd.log

3. Add the following line in <Linux_for_Tegra>/tools/kernel_flash/
	cp "${INITRDDIR_L4T_DIR}/"*.sh "${working_dir}/initrd/bin"
+	cp "${ROOTFS_DIR}/usr/sbin/sshd" "${working_dir}/initrd/bin"
	cp "${ROOTFS_DIR}/usr/sbin/flash_erase" "${working_dir}/initrd/usr/sbin"

You could remove the SSH server(sshd) in recovery image with the above steps, but we don’t guarantee that there’s other side effect w/o SSH server.

Thank you for your response; I’ll give it a try. However, I am concerned about your statement:

Thus, I have two questions:

  1. If there are implications, I understand it to affect only OTA updates. Is my understanding correct, or is there a misunderstanding?
  2. I would like to confirm which Nvidia-provided update processes and applications are referred to by OTA updates. For instance, I thought that procedures like nvbootctrl and nv_update_engine, introduced in Update and Redundancy — Jetson Linux Developer Guide documentation, are not wireless updates. Do these get affected as well?

Thank you for your assistance.

Update Engine is deprecated since R35.2.1.
Please refer to capsule update instead

Since the method I shared is not officially supported and we don’t verify this use case and test it completely. You could just refer to the developer guide and check if the required feature working in your case.

Thank you for your response.

I apologize, I was mistaken about the specific area of concern.

I understand that this use case has not been rigorously tested. However, I would like to inquire about the Nvidia-provided applications and scripts, specifically which ones utilize sshd. Is it possible to get this information? I am particularly interested in confirming whether there is any impact on the capsule updates that were corrected above.

Thank you for your assistance.

Capsule update is used to update bootloader.
I’ve confirmed with internal that capsule update would not be affected by the sshd.
It should work in your case.

1 Like

Thank you for your confirmation.
Your response has resolved my questions.

Thank you for your prompt reply.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.