SSH "timed out" error after headless setup

Autonomous Machines Jetson & Embedded Systems Jetson Nano
1

I set up my jetson nano aa couple days ago. After setup, i tried to ssh in, but I couldn’t. I keep getting a “Connection timed out” fatal error from PuTTY. I’ve tried:
checking the status with sudo systemctl status ssh (its active)
reinstalling it with sudo apt-get install openssh-server
disabling firewall on my windows machine
restarting ssh - sudo systemctl start ssh
I’ve also tried using window’s remote desktop connection, also no luck
and some other things I forgot.
If anybody knows how to fix this, please let me know

3

Hi aranis.das,

Are you using the devkit or custom board for Jetson Nano?
What’s your Jetpack version in use?

Do you hit any issue during system configuration setup?

Is your network connection worked?
Please share the result of ifconfig on your board.

4

I can’t provide much help on Wi-Fi, but there is some standard Ubuntu (and many other distributions) behavior that might apply.

Wired networking is normally set up much earlier in boot, before the GUI runs. Ubuntu (and others) tend to only set up Wi-Fi when the user logs in to the GUI. It doesn’t have to be that way, and you could set this up to run when a command line mode is reached (either multi-user or single user with networking). Managed network setup though can be confusing, and I personally stick to wired.

However, since you have PuTTY, you can use serial console as well, or wired, for debugging. I’ll add this to the ifconfig information requested by @KevinFFF:

  • ifconfig
  • iwconfig
  • route
  • rfkill --output-all
  • nmcli
1 Like
5

Yes I have setup wireless connection. It works since I’ve used it to update. Using the devkit. Not sure about the Jetpack version. Is it nessesary for SSH? I thought it comes with the OS?
I did have an issue, but I fixed it according to this thread
Here’s the result of
ifconifg:
docker0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 172.17.0.1 netmask 255.255.0.0 broadcast 172.17.255.255
ether 02:42:09:1b:a9:bb txqueuelen 0 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

eth0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether 48:b0:2d:c1:41:5c txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 151 base 0x6000

l4tbr0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.55.1 netmask 255.255.255.0 broadcast 192.168.55.255
inet6 fe80::b4d3:34ff:fec2:f955 prefixlen 64 scopeid 0x20
inet6 fe80::1 prefixlen 128 scopeid 0x20
ether b6:d3:34:c2:f9:55 txqueuelen 1000 (Ethernet)
RX packets 835 bytes 116672 (116.6 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 78 bytes 9120 (9.1 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10
loop txqueuelen 1 (Local Loopback)
RX packets 195 bytes 15305 (15.3 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 195 bytes 15305 (15.3 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

rndis0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::b4d3:34ff:fec2:f955 prefixlen 64 scopeid 0x20
ether b6:d3:34:c2:f9:55 txqueuelen 1000 (Ethernet)
RX packets 883 bytes 120799 (120.7 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 102 bytes 17603 (17.6 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

usb0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::b4d3:34ff:fec2:f957 prefixlen 64 scopeid 0x20
ether b6:d3:34:c2:f9:57 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 473 bytes 97100 (97.1 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.0.220 netmask 255.255.255.0 broadcast 192.168.0.255
inet6 fe80::393:2ba9:49a4:9862 prefixlen 64 scopeid 0x20
ether 78:8c:b5:a0:13:b5 txqueuelen 1000 (Ethernet)
RX packets 920 bytes 1263279 (1.2 MB)
RX errors 0 dropped 6 overruns 0 frame 0
TX packets 696 bytes 77879 (77.8 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

iwconfig:
wlan0 IEEE 802.11bgn ESSID:“SSID” Nickname:“WIFI@REALTEK”
Mode:Managed Frequency:2.422 GHz Access Point: 6A:AF:97:17:F5:EA
Bit Rate:72.2 Mb/s Sensitivity:0/0
Retry:off RTS thr:off Fragment thr:off
Power Management:off
Link Quality=97/100 Signal level=72/100 Noise level=0/100
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
(I renamed the SSID to SSID)

route:
Destination Gateway Genmask Flags Metric Ref Use Iface
default _gateway 0.0.0.0 UG 600 0 0 wlan0
default _gateway 0.0.0.0 UG 32766 0 0 l4tbr0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 wlan0
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
192.168.0.0 0.0.0.0 255.255.255.0 U 600 0 0 wlan0
192.168.55.0 0.0.0.0 255.255.255.0 U 0 0 0 l4tbr0

nmcli:
“Realtek 802.11n NIC”
wifi (r8188eu), 78:8C:B5:A0:13:B5, hw, mtu 1500
ip4 default
inet4 192.168.0.220/24
route4 0.0.0.0/0
route4 192.168.0.0/24
route4 169.254.0.0/16
inet6 fe80::393:2ba9:49a4:9862/64
route6 ff00::/8
route6 fe80::/64
route6 fe80::/64

l4tbr0: connected to l4tbr0
“l4tbr0”
bridge, B6:D3:34:C2:F9:55, sw, mtu 1500
inet4 192.168.55.1/24
route4 192.168.55.0/24
route4 0.0.0.0/0
inet6 fe80::1/128
inet6 fe80::b4d3:34ff:fec2:f955/64
route6 ff00::/8
route6 fe80::/64

6

thanks for the input. I provided all the info. I also prefer wired, but I need SSH to run for a graphical interface. Unless there is a way to do serial and get a graphical interface?

7

Note: In forums you can use the “pencil” icon to edit your existing posts. For those logs of command output it is advised to highlight those with a mouse, and then click on the “code” icon (looks like “</>”). This preserves formatting and goes to a monospace font.

What do you see from “rfkill --ouptut-all”?

Btw, setting up keys and general Wi-Fi setup is different than changing the stage in boot whereby Wi-Fi tries to run and connect. I am assuming the Wi-Fi is set up correctly, but failing to run in text-only mode (before the GUI runs). Ubuntu assumes a per user login setup for Wi-Fi, but you need Wi-Fi to run automatically before the GUI stage is reached (because you don’t have a GUI, and are “headless”, this would be a long wait).

In part you might want to use this as a reference:
https://www.linuxbabe.com/ubuntu/connect-to-wi-fi-from-terminal-on-ubuntu-18-04-19-04-with-wpa-supplicant

Please note that part of that may already be set up, but if for example a passphrase is part of your GUI login, then you’d still need to reference that during early (non-GUI) startup of the Wi-Fi. In that URL above, note that the Wi-Fi is being removed from NetworkManager. This allows manual setup, and is part of the reason why Wi-Fi is currently bound to a GUI login. I can’t guarantee it, but I think this applies to Ubuntu 18 without change compared to Ubuntu 20 or 22. See if that works.

8

I tried using this command:
sudo wpa_supplicant -c /etc/wpa_supplicant.conf -i wlp4s0
and it made things worse. The name of my machine is now ubuntubox and the wifi does not have an access point. when i run ifconfig wlan0 doesnt show up anymore, and pinging anything just makes it do nothing.

I also cant reinstall the image on an sd card since my computer doesnt reogonize it. Really not sure what to do at this point…

The text backquoted was before. I reset the network manager and the wifi seems to work again (still confused about the host name change though).

rfkill --output-all gives me an error:
rfkill: unrecognized option ‘–output-all’

So which part of the link should I follow? If I’m not mistaken we are trying to remove wifi and force a manual setup to get a GUI login?

9

Update: So ssh into the client does work. Putty is still timed out. I followed Step 3 :Auto connect at boot time and made the changes.
gudboy007@ubuntubox:~$ ssh gudboy007@192.168.0.220
The authenticity of host ‘192.168.0.220 (192.168.0.220)’ can’t be established.
ECDSA key fingerprint is SHA256:LbBvC+TuqCEBz+VCFoCQJ9gizI8ZSfV2WP/6w+vj4GY.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added ‘192.168.0.220’ (ECDSA) to the list of known hosts.
gudboy007@192.168.0.220’s password:
Welcome to Ubuntu 18.04.6 LTS (GNU/Linux 4.9.337-tegra aarch64)

To restore this content, you can run the ‘unminimize’ command.

Expanded Security Maintenance for Infrastructure is not enabled.

0 updates can be applied immediately.

82 additional security updates can be applied with ESM Infra.
Learn more about enabling ESM Infra service for Ubuntu 18.04 at

Last login: Tue Aug 15 17:53:46 2023
gudboy007@ubuntubox:~$

The windows config and the putty still do not. what can be the reason?

10

I’m thinking the “--output-all” is for a newer Ubuntu release. However, just “rfkill” should show good information.

The default is that mobile connections are managed. They’re designed to run on GUI login. I’m not a Wi-Fi expert, but basically you’re disabling management so that Wi-Fi can be set to just be “on” at the “multi-user.target” boot stage (text mode, which is achieved even without login; ssh for example uses text mode unless you tell it to forward X GUI events).

Now if something in the setup changes you’ve made allows ssh to work, then so far as ssh goes, it is set up. So my question is this: When you say “So ssh into the client does work. PuTTY is still timed out”, are you saying ssh from some outside computer into the Jetson works, despite PuTTY not working?

When ssh works from some outside computer, but not from another, and assuming you can ping the Jetson from the failing PuTTY computer, it implies one of two things:

  • Firewall issues. Since you can ping this is not likely, but firewalls understand protocols and block differently depending on protocol (ping is ICMP, the ssh from PuTTY would be TCP, although I think it could be set to use UDP).
  • The ssh client or host itself is blocking this. This is very likely, and I will elaborate on why.

A command line ssh connection tends to provide more information when the connection is blocked due to unknown or incorrect keys. With a GUI application, if something changed, it might not do anything more than refuse, and not tell you what changed. You mentioned a host name change, and this is one of the things which will trigger blocking until you ok using the new credentials.

I don’t know enough about PuTTY to say for sure how to do this. However, from what I’ve read, one would use a “cleanup” feature. One way seems to be this:
https://www.siliconhouse.net/support/putty/

Here is a larger search with other solutions, essentially doing the same thing, but explained in videos or other articles:
Google Search for: “windows” “putty” how to clear a connection credential

I will suggest though that the Jetson end is doing as expected, and if a cached credential has changed, then the other side of the connection is what will cause a refusal.

11

Thanks for replying

ssh does not work anywhere expect for the same serial putty session. I am basically running the ssh on the already running terminal from putty. But doing ssh from the start in putty, or anywhere else for that matter, gives me a timeout error.

rfkill does nothing. rfkill list all also does nothing, and everything else returns an error

As per cleaning the credientials, I tried the first link and a tutorial. cleanup did not work and returned an error, and the other tutorial i looked at had a registry file called
ssh-hostkeys but I didn’t.

Bottom line is, I want to run opencv and interface with the camera i have
But every tutorial i see goes through the graphical setup, and configures ssh after the initial setup to start running applications and stuff like gstreamer and opencv projects on CSI cameras.

12

Serial is not ssh. PuTTY and some other clients are capable of using either ssh or serial, but they are 100% unrelated. So we have to say there is no ssh rather than saying it only works from some locations.

rfkill not showing Wi-Fi devices implies there is no driver loaded for a Wi-Fi device.

Before moving forward with Wi-Fi, if you are logged in at the Jetson (doesn’t matter if it is GUI or command line or serial console), are you able to connect from the Jetson to the Jetson via this (it’ll ask if you consider it valid on the first connect):
ssh localhost
(then log in with your regular login, and log out)

Basically this just confirms if ssh itself is listening. If it is, then you should be able to connect over wired ethernet when that is set up. If that does not work, then ssh itself needs setup before any network would succeed.

Note that there is a minor exception. The USB cable port used for flashing also provides a virtual wired USB network device to the host PC. The host PC has to ok this in some cases, and might be blocked on Windows if security is not told to use this device. If this device is set up, then the host could ping the Jetson via “ping 192.168.55.1”, and the Jetson could ping the host via “ping 192.168.55.100”. This is not the wired or Wi-Fi which I speak of though.

I see in a previous ifconfig wlan0 with address 192.168.0.220. This might be from Wi-Fi. If this still shows up on ifconfig from the Jetson, then on the host PC, try to ping 192.168.0.220. This would establish if that network device and route are working. Then, if the previous ssh to localhost succeeded, try from the host PC to use ssh to 192.168.0.220. If this works, then we’ve made progress in verifying ssh and much of networking.

The part which is confusing is that rfkill shows nothing on the Jetson. A previous iwconfig shows a Realtek wireless device, and is measuring signal levels with a strong signal-to-noise ratio. I don’t see an address assigned to the device, but rfkill should still see the existence of the device.

Go ahead and try the ssh experiments, and the ping experiments. Let’s see how those go, then we will again investigate why Wi-Fi does not exist from rfkill (I don’t know enough, but perhaps rfkill requires a device to be managed…but I doubt that is a requirement).

13

Yes, it showed:

“Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added ‘localhost’ (ECDSA) to the list of known hosts.”

Also yes, pinging to my IP does work and the google dns works aswell (8.8.8.8).

ssh username@ip does not work. the ssh still shows a timed out error.
I tried ssh(ing?) directly into the IP on powershell with:
ssh 192.168.0.220
it also showed the timed out error

By nothing I mean it just prompts be back to the command line without doing anything (same case with rfkill list all). Maybe something isn’t installed?
I also tried running “lspci | grep Network”, which is supposed to show the network interfaces. Nothing showed up…

I tried sudo lshw -c network -businfo, which is supposed to show the bus connections for network and it shows:

Bus info Device Class Description

pci@0000:01:00.0 eth0 network RTL8111/8168/8411 PCI Express Gigabit Ether
dummy0 network Ethernet interface
usb0 network Ethernet interface
usb@1:2.3 wlan0 network Wireless interface
rndis0 network Ethernet interface

Dont’ know if it helps but I am using this wifi adapter

14

We’re making progress. On the Jetson, monitor “sudo tail -f /var/log/auth.log”. Then, from the host PC (I assume PuTTY on Windows), try to connect via ssh (not serial, although you could have serial running as well). Watch the log during the connect attempt. If you see anything as a result of the login attempt, then I think it is the Jetson denying the login. If nothing shows, then it is probably the host PC denying the attempt.

For a more detailed debugging tool to ssh login, I think you have to use a Linux host PC. I don’t think Windows has the same abilities, at least not without purchasing a third party enhanced version of ssh. Or, if it has this, I don’t know how to get at that much detail (maybe there is a way). On a Linux PC using command line, for example, one can see identity settings via “ssh -G name@host”. The one which is really useful is “ssh -v name@host” (which can be combined with logging via “ssh -v name@host 2>&1 | tee log_ssh.txt”).

If the auth log did not respond to the connection attempt, you’ll probably need to use a Linux host PC to try the connect using “ssh -v”.

Incidentally, Wi-Fi, or wired won’t matter if you are on the same subnet. Just substitute the IP address for the “host” I used as a name in the ssh connections. “name” is of course your login name on the Jetson.

15

Yeah it shows nothing:
Aug 17 12:04:23 ubuntubox sudo: pam_unix(sudo:session): session opened for user root by gudboy007(uid=0)
the 12:04:23 is me logging into serial. When I tried ssh, it did not put anything new.
How can i run linux? is there a way to get a virtual machine running?

16

I don’t know much about setting up a VM, so I can’t help with that. I can tell you that VMs can be frustrating since passing through USB or ethernet from the host PC is often set up wrong and causes headaches. On the other hand, your host PC would still need to be set up to allow this connection since networking of a VM is passed through via the parent o/s, and it is likely the parent o/s is blocking the network attempt.

I don’t know which particular version of Windows you are using, but I’m guessing there is a forum somewhere related to PuTTY on that version of Windows asking how to allow ssh out, or to verify that it is allowed. This would probably be the next step since (A) you know ssh from the local Jetson works, (B) the local ssh connect will show up in logs, (C) you can ping the Jetson, but (D) nothing logs from a Windows connect attempt. I just don’t know enough about Windows setup (nor which particular flavor of Windows you use) to either verify ssh is allowed, nor to edit permissions. Likely it is in some firewall setup where you’d name PuTTY to be allowed.

Tip: Regular ssh is TCP port 22.

17

okay so here’s an update:
i did two things:
ran sudo ufw allow 22/tcp , which is supposed to allow the port
and i connected via ssh user@server-domain instead of user@public-ip on powershell (admin mode)
and to my suprise, it did work. But I still cannot connect directly to the IP, and hence cant establish a remote desktop connection (which is the main thing I want)
furthermore, the user@server-domain connection stops aburptly after i disconnect the serial communication or the wire on putty
so it might not be great after all, but atleast one ssh command partly works

where should I go from here? I’ve installed xrdp and xfce, which are used in remote desktop protcols, but they are useless right now because I cant connect via the remote desktop config in the first place.

update:it works now somehow
all you have to do is ditch the IP address and connect via user@domain instead

click the dropdown when you get remote desktop
enter your username and domain credentials (you see this in the ubuntu terminal as name@domain)
make sure you have xrdp installed via:
sudo apt-get install xrdp
hope this helps someone

@linuxdev is this okay for setup? running it like this works but is unreliable. Is there a way to use serial communication and connect to the jetson? How can I start running c++ stuff on this?

Also, thanks so much for sticking with me through this.

19

When it matters if you use a named address versus dotted-decimal address, then “typically” it is the ssh client itself which is blocking (assuming there is ping). Consider:

  • If you can ping, then you are using the ICMP protocol to prove the route itself is working.
  • ssh will use TCP. Mostly verification of ICMP implies TCP can work too, but only if no firewall is blocking it, and only if TCP protocol is supported along the route. I’ve never known TCP to not be supported along the route.
  • This also assumes you are on the same subnet. Going through the DMZ of a router from one device to another within the DMZ will only block if you have a managed switch (mostly limited to larger commercial businesses; it is rare for a home to have a managed switch as they are much more expensive).
  • XRDP is a remote desktop protocol. This is not used for ssh, but it is used for some remote GUI software. Example: Virtual desktops, e.g., VNC. If XRDP is required, then it might be that you are using ssh as a tunnel for the XRDP. When using PuTTY I don’t think XRDP would be involved, although an XRDP application could itself use the ssh connection…this in turn implies it isn’t just text-based traffic, but perhaps a GUI. If you are not using PuTTY for only text-based command line connection, then you might add that information (or suggest that you are in fact only using text command line).
  • It is possible that if you install XRDP somewhere, that this could have an effect on other network settings and indirectly fix or alter existing networking.

You can run a text-based editor over ssh without anything special. You’d have to know your text editor, and that isn’t always easy. Example: vi (these days it is vim). I use vi a lot, and it does not require a GUI. pico is another easier to use editor (it doesn’t have much learning curve), but it doesn’t context highlight or have any advanced features.

If you want remote display a GUI application, and if your host PC is Linux (not Windows or Mac), then you can often enable X event forwarding via ssh and run something like kate or codeblocks (or anything GUI). This depends on the ends of the remote and local understanding X events (X client-server model). See:

To run cross platform GUI with no restrictions implies you must install a remote desktop server on the remote end, and a remote desktop client on the local end. This is beyond what I can help with, but examples are:

  • VNC
  • TurboVNC
  • VirtualGL
  • RealVNC
  • Vino
    (I think latter this is the closest to officially supported, but I don’t know if there is a Windows client for Vino)

If any virtual desktop is not installed correctly, you risk causing graphics to fail (and CUDA). You want to be certain that this desktop works specifically with the Jetson without reverting to software rendering (meaning the GPU driver would no longer load and all work would be on the CPU). I don’t use any virtual desktop, so I am the wrong guy to tell you what works best.

Incidentally, any remote desktop has its own security which is similar to ssh. Quite often such applications run through an ssh tunnel, and even if the tunnel works, would still fail if the remote desktop requirements are not met (including security and protocols like XRDP, which is part of a network protocol on top of other protocols).

1 Like
21

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