How to ssh to Jetson Thor

Robotics & Edge Computing Jetson & Embedded Systems Jetson Thor
1

I just installed the Jetson BSP (ISO r38.2-08-22) via USB stick on Jetson Thor and can login the system (Ubuntu 24.04.3 LTS).

I can use serial to access Thor from my MacBook via the USB cable but it kinda buggy so I want to setup ssh for stable access. I did the same thing as I have done for AGX orin, writing the following in the ~/.ssh/config on my MacBook:

Host myhost
    HostName myhostname.local
    User myusername

then I tried `ssh myhost` and it just stuck there (the same command works for Jetson AGX orin).

I tried to ping 192.168.55.1 and it got timeout.

I also looked at this blog but the ifconfig command on Jetson Thor didn’t show me the eth0 or usb0 sections.

Is there anyone that can tell me how to ssh to this Jetson Thor? Thanks!

2

Are you trying to ssh from Jetson to Mac, or from Mac to Jetson? The information below perhaps covers more information than you need since I’m sort of describing both ends.

Note: If your Jetson and host PC are connected via an Ethernet switch, then much of what follows is unnecessary. The descriptions related to the USB network addresses 192.168.55.1 and 192.168.55.100 would not be an issue, and you’d just use the address of the Jetson and the address of the host PC for normal Ethernet.

ssh is able to provide some more verbose debugging output, for example:
ssh -v myhost

You could record this for a log (it won’t record passwords):
ssh -v myhost 2>&1 | tee log_ssh.txt

However, it sounds like this is networking in the case of ping failure (but it might just be using the wrong IP address). If you are on the host, and the USB cable is plugged in and working as a network router, then you can ping from host to Jetson:
ping 192.168.55.1

If you are on the Jetson, and want to ping the host, you can:
ping 192.168.55.100

Can you clarify if you want to ssh from Mac to Jetson, or from Jetson to Mac? Also, if you are going to use the regular Ethernet networking, or if you are depending on the USB virtual networking of the Jetson.

Case: Common to Both Ends

It is useful to describe the USB cable network setup if you want to debug it. The Jetson, on the correct USB port, looks like a network router device. When plugged in to the host PC (or Mac) USB’s type-A port (or with a bit of “Jedi mind trickery”, a type-C port), the host PC will see a router. If all goes well, then the host sends a DHCP request to the router (Jetson), and assigns an address to the host side of 192.168.55.100. This makes it possible for network packets between the two, but ssh setup is its own topic.

If the host PC has security, then it might reject assigning a network address to the virtual router provided by the Jetson. I would expect ping to fail (or if the host is not set to reply to ICMP protocol for security reasons, then ping would again fail for a slightly different reason, but that reason would not be Jetson failure…it would be a host PC configuration issue).

Case: PC (Mac side) Testing of SSH

The host PC might accept that network device and set up for address 192.168.55.100, and work, but still have ssh issues (this is true regardless of whether or not you use the virtual wired Ethernet over USB, or if you use the actual Ethernet wired networking). I’m not sure, but on a command line I think a Mac might respond to looking at network interfaces with ifconfig (or maybe sudo ifconfig; newer Linux uses “ip -s addr”). Once that is working, then ssh has its own security.

From the Mac can you ssh to the same account on the Mac as both local and remote end? This means ssh is being used in loopback whereby you use ssh directly from the PC/Mac and account name to that same PC/Mac and account name (not involving the Jetson except if you use the 192.168.55.100 address, but this is incidental). There won’t be any network issues in loopback. If ssh works in loopback, then it becomes possible for ssh to work from remote.

If ssh security is involved, then ssh might not ever respond from remote (technically, ssh security could prevent loopback too, but it is the least complicated test; ssh from remote adds more to the requirements simply by being a host the local PC has never seen). The verbose ssh listed at the start of this reply is quite useful in knowing if security is involved.

Case: Jetson Testing of SSH

The previous paragraph can be inverted, and from the other system you can also perform loopback ssh, and ssh to the other system’s IP address. On the Jetson side loopback for virtual wired USB Ethernet goes to 192.168.55.1; the same thing on loopback for host PC side is 192.168.55.100. You can use ssh -v if there are issues and use that to see why ssh is failing (assumes the IP address is valid). Then you can also ping or examine by swapping account login name and IP address for the appropriate “to or from” remote or local device (local or remote is just a perspective from which system you are logged in to before trying to start ssh).

All of the previous testing can skip the USB addresses entirely if you have wired Ethernet addresses. On the Jetson side you can gather information about available devices and assigned addresses via:
ip -s addr

If you need to log something for a forum post, then you can just append " 2>&1 | log_name.txt", e.g., “ip -s addr 2>&1 | tee log_jetson.txt” or “ip -s addr 2>&1 | tee log_mac.txt”. Similar for “ssh -v”.

3

Thanks for the reply. I am trying ssh from my PC (Mac side) to Jetson Thor via a USB cable (not sure if that is the USB virtual networking you are referring to).

The log for `ssh -v myhost` is:

OpenSSH_9.9p2, LibreSSL 3.3.6
debug1: Reading configuration data /Users/mymac/.ssh/config
debug1: /Users/mymac/.ssh/config line 13: Applying options for myhost
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/100-macos.conf
debug1: /etc/ssh/ssh_config.d/100-macos.conf line 1: Applying options for *
debug1: Reading configuration data /etc/ssh/crypto.conf
debug1: /etc/ssh/ssh_config line 57: Applying options for *
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug1: Connecting to myhostname.local port 22.

The log for `ping 192.168.55.1` on my PC (Mac side) terminal is:

PING 192.168.55.1 (192.168.55.1): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
...
5

If both Thor and mac are attached to a network. From your mac

ssh username@ip_address_thor

1 Like
6

Hi
If your Thor device and host PC are in same LAN(local area network), you should be able to login the Thor device through ssh, without additional configuration.

7

The USB cable networking is indeed the “virtual networking”.

From the ping failure it is evident that the USB wired virtual networking has not succeeded. I’m guessing that if you are already logged in to the Jetson that you can succeed with “ssh name@localhost” (this is an ssh loopback; it is ssh from your account on the Jetson while logged in to the Jetson to the same account on the same Jetson). There won’t be a network issue locally, but you can verify that ssh is installed and working on the Jetson this way.

The rest of solving this is to find out why the Mac did not set up the virtual network. I don’t know much about a Mac, but some of the console command lines are just a standard *NIX/Linux command set, e.g., ls. There are many computers in the world which have security set up such that plugging in a random USB device is disabled from creating a network, but I have no idea how to test this on a Mac.

You can either (A) debug the Mac’s response (security) related to plugging in and accepting a USB router, or (B), if the wired network is available on the Ethernet port, use that address instead. Are the Mac and Jetson on the same wired network? If so, then just use the other address, verify ping works, and then use ssh as you’ve been trying.

Wi-Fi also works, but I seldom suggest using that because setup is a whole new level of mess. If you happen to have Wi-Fi working though, then that IP address would work the same as wired Ethernet.

8

Here is something I have tried. (I have a MacBook and a linux workstation (Ubuntu 24.04.2 LTS) to serve as hosts, and try to connect to the Jetson Thor; Finally I also test with Jetson AGX Orin)

On Thor:

“ifconfig” shows (I only showed the ones with “inet“):

  • docker0 (inet 172.17.0.1)
  • l4tbr0 (inet 192.168.55.1)
  • lo (inet 127.0.0.1)
  • wlP1p1s0 (inet 172.16.XXX.XXX)

“ping” test:

  • localhost (success)
  • 172.17.0.1 (success)
  • 192.168.55.1 (success)
  • 192.168.55.10 (failure)
  • 172.16.XXX.XXX (success)

On Workstation (connect Thor with it via USB)

“ifconfig” shows:

  • docker0 (inet 172.17.0.1)
  • enp129s0 (inet XX.222.32.123)
  • lo (inet 127.0.0.1)
  • wlp130s0f0 (inet 172.16.XXX.XXX)

“ping” test:

  • localhost (success)
  • 172.17.0.1 (success)
  • 192.168.55.1 (failure)
  • 192.168.55.10 (failure)
  • XX.222.32.123 (success)
  • 172.16.XXX.XXX (success)

On MacBook (connect Thor with it via USB)

“ifconfig” shows:

  • lo0 (inet 127.0.0.1)
  • en0 (inet 172.16.XXX.XXX)
  • utun12 (inet XX.5.2.249)

“ping” test:

  • localhost (success)
  • 172.16.XXX.XXX (success)
  • 192.168.55.1 (failure)
  • 192.168.55.10 (failure)
  • XX.5.2.249 (success)

On MacBook (connect Orin with it via USB)

“ifconfig” shows (additional):

  • en9 (inet 192.168.55.100)

“ping“ test:

  • orin-hostname.local (success // I wrote this hostname in the ~/.ssh/config)
  • 192.168.55.1 (success)
  • 192.168.55.10 (failure)
  • 192.168.55.100 (success)
PING orin-hostname.local (192.168.55.1): 56 data bytes
64 bytes from 192.168.55.1: icmp_seq=0 ttl=64 time=2.235 ms
64 bytes from 192.168.55.1: icmp_seq=1 ttl=64 time=1.623 ms

The Orin ssh connection is very easy, but the same setup on Thor doesn’t work. Do you have any suggestions based on these results? Thanks.

9

[SOLUTION] I figured it out - I have been USING THE WRONG USB-C PORT ALL THE TIME. I used the DEBUG USB-C port under the removable lid cover, which I guess only does serial transmission. After I switched to the USB-C port on the left of the HDMI/DP port, IT WORKS!

2 Likes