After updating my Jetson AGX Xavier to Jetson Linux 35.6.0 following the Over-The-Air Update guide, I ran into an issue.
Post sudo reboot, I confirmed the device was reachable by ping, but SSH attempts using the old credentials (ssh <username>@<ip>) returned:
ssh: connect to host <ip> port 22: Connection refused
Is there a way to restore SSH access remotely without physical intervention and without using USB? I specifically chose OTA over SDK Manager because of this. I only have VPN network access and no physical access.
sorry for my late response, I was on sick leave last week. I tried your ssh-keygen command. It successfully updated the known_hosts on my machine but I still get the ssh: connect to host <ip> port 22: Connection refused error.
I debugged it using nmap and rpcinfo:
$ nmap <ip>
Starting Nmap 7.80 ( https://nmap.org ) at 2024-11-11 09:48 CET
Nmap scan report for <ip>
Host is up (0.0014s latency).
Not shown: 999 closed ports
PORT STATE SERVICE
111/tcp open rpcbind
Nmap done: 1 IP address (1 host up) scanned in 0.07 seconds
$ rpcinfo -p <ip>
program vers proto port service
100000 4 tcp 111 portmapper
100000 3 tcp 111 portmapper
100000 2 tcp 111 portmapper
100000 4 udp 111 portmapper
100000 3 udp 111 portmapper
100000 2 udp 111 portmapper
Apparently only port 111 is open with portmapper service. I organized physical access to this particular Jetson AGX Xavier unit to configure it in person tomorrow. Can I provide any logs that help you diagnose my issue?
I discovered why SSH wasn’t functioning: after the OTA update, the Jetson booted into the initial setup screen. Once I completed the configuration, SSH started working. How can I configure the OTA process to retain the existing setup and bypass the initial setup screen? I have multiple Jetson AGX Xavier units deployed across various countries, so traveling just to input credentials isn’t a cost-effective solution.
Incidentally, once you use the method @JerryChang shows, there will be a home directory with that user in the host PC’s “Linux_for_Tegra/rootfs/”. Any changes you make there will exist after a flash. For example, if you were to edit the “~/.bashrc”, then that would exist after flash. If you were to copy any old ssh keys (either host or user) to that “rootfs/” content, then this too would be instantly present after a flash. If you back up the running Jetson to the “rootfs/”, e.g., via rsync, then this is what you would get after flash.
The part which won’t stay is that during a flash the kernel and/or boot content, including the initrd, can change. Content outside of that can easily be preserved to the flash content of the host PC.