Unable to ssh or download on Nvidia Tegra TK1

Previously I was able to ssh onto the Nvidia Tegra board running L4T 21.2. Recently i am unable to ssh onto the board. When I try to download anything the browser crashes. Any idea why this could be happening or how could I solve it?

I also tried this:
sudo apt-get remove openssh-client openssh-server
sudo apt-get install openssh-client openssh-server
Doesn’t work

Are you able to run this?

sha1sum -c /etc/nv_tegra_release

How is this tk1 connected to the network…private ethernet? Static IP address? DHCP? Public internet? If public internet, via a router which firewalls incoming? If anything outside has any kind of access, did you change the “ubuntu” default password before making it public?

What is the output of “ifconfig”?

I am able to run the command you mentioned above. I am connected to my University Network via wired connection. I did not make any changes to the network settings.

The output of ifconfig and the mentioned command is below.

ubuntu@tegra-ubuntu:~$ ifconfig
eth0 Link encap:Ethernet HWaddr 00:04:4b:2c:24:f5
inet addr:129.174.124.167 Bcast:129.174.124.255 Mask:255.255.255.0
inet6 addr: fe80::204:4bff:fe2c:24f5/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:13141 errors:0 dropped:0 overruns:0 frame:0
TX packets:4268 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:7798946 (7.7 MB) TX bytes:809631 (809.6 KB)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:1628 errors:0 dropped:0 overruns:0 frame:0
TX packets:1628 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:280408 (280.4 KB) TX bytes:280408 (280.4 KB)

ubuntu@tegra-ubuntu:~$ sha1sum -c /etc/nv_tegra_release
/usr/lib/xorg/modules/extensions/libglx.so: OK
/usr/lib/xorg/modules/drivers/nvidia_drv.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvsm.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvapputil.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvomx.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libglx.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvdc.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvrm_graphics.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvparser.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvmm.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvtvmr.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvwinsys.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvavp.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvmm_camera_v3.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvfusebypass.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvomxilclient.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvodm_query.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libjpeg.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvmmlite_utils.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvmm_contentpipe.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvmmlite_image.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvtestresults.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvos.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvmmlite_audio.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvrm.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvodm_imager.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libtegrav4l2.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvmm_parser.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvtestio.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvmm_utils.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvddk_vic.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvmmlite.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvmmlite_video.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvtnr.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvddk_2d_v2.so: OK

It looks like the basics are ok. Since you are connected to the public, I hope you changed the ubuntu default password…if not it’s a prime target for trouble.

I’m not around my devel setup right now, but I’d recommend checking logs while trying ssh. The "tail -f " will watch the file and tell you live as logs are updated. Not sure which files to check, but probably /var/log/secure, /var/log/messages, and maybe something else like dmesg. If you see an attempt to get in, then you know the failure is likely at the Jetson end…if you don’t see the attempt, perhaps your machine you run ssh from is blocked for some reason.

I have not changed the ubuntu default password. Why is that an issue?
I do not think it is the host that is the problem as I am unable to ssh from other systems as well.
I will try the other things you mentioned when I am around the board tomorrow.
If in the meantime you figure something out Please do let me know as I really need to install my applications on the board ASAP.
Thanks a ton!

Lack of password change means your administrator/root password is now available to anyone port scanning. Anyone can log in and do anything they want and there is absolutely no security other than firewalls against the outside world. Root kits can be installed, any file can be added or deleted (including the entire operating system), firewalls themselves and other security can be modified. Your password is published, standard, and absolutely known to all third parties until you change it. If logs were enabled to be verbose and note every port scan attempt you could watch such attempts arrive every minute of every day on a public network like a university. Your ssh might even work, but someone could have changed its password.

Since you know all outside locations fail, it could be a policy from your network’s routing (university), not the Jetson, but I agree the odds are rather high that the failure is at the Jetson itself. There’s just no way to know more without seeing the logs while attempting ssh login.