This is just a placeholder. Back when Jetsons came with default account setup the user name was “nvidia”, and it is just easy to use that login name as a placeholder versus asking you what your account name is.
Yes, you want to log in to the nano from the nano. If the password works or does not work there, then the evidence for the cause is much more valuable than from a remote host which might have other issues. The nano will never have an issue with character encoding from itself to itself. Other possible issues are also simplified and success or failure of ssh locally becomes much more interesting.
You will always be asked if you trust the source. When you ssh to “localhost” you will be asked. If “localhost” is 127.0.0.1, and you then ssh to 127.0.0.1, then you will be asked again. If you have an alias in your “/etc/hosts” to be able to “ssh nvidia@nano”, then you will be asked yet again if you trust the connection on your first visit.
FYI, every computer has a non-routable address “127.0.0.1”. That address (actually the whole subnet) is blocked if you try to reach it over the internet…it only works from that specific host. There are a large number of applications which use network protocols even when on the local computer. Imagine if those applications only worked when you had internet access? The name “localhost” is synonymous, and is an “alias” to “127.0.0.1”.
You can create custom aliases to simplify life. For example, I have a private network (not touching the internet) on a second ethernet card for different embedded hardware. I’ve done this for about 20 years because it simplifies things (it also has my IP based printer on it which the internet cannot see). The IP addresses I’m naming below are just examples (placeholders), but this is representative to illustrate aliases. Imagine you edit file “/etc/hosts”, and it has this:
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 testalmariposa
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
192.168.1.2 pc
192.168.1.3 printer
192.168.1.4 k1 tk1
192.168.1.5 x1 tx1
192.168.1.6 x2 tx2
192.168.1.7 xv
192.168.1.8 nx
192.168.1.9 nano
In that example the localhost content is generated by the packages during install of the operating system. The rest, starting with “pc”, would be arbitrary names I can use to describe the different systems without memorizing the actual IP address. The following are equivalents (I’m using “ping”, but it could be any network command, including “ssh”):
ping pc is the same as ping 192.168.1.2.ping k1 is the same as ping tk1 and is the same as ping 192.168.1.4.ping x1 is the same as ping tx1 and is the same as ping 192.168.1.5.
And so on. Note that if you are actually logged in to your PC, then either “ssh localhost” or “ssh 192.168.1.2” or “ssh 127.0.0.1” would get you to the same host. The difference is that target address 127.0.0.1 won’t go across a network card and won’t have to compete for any traffic bandwidth. Going through 192.168.1.2 would actually traverse the network card, and if the network went down, then that route would fail.
ssh is designed to keep you from being fooled by “man in the middle” attacks. In the above examples ssh considers these as distinct:
These are in fact the same routes and end up at the same hardware. However, if you’ve never used one of those aliases, then ssh warns you on first connect.
All that aside, and it is still possible you used the wrong address. This is one of the reasons I have a private network on a second network card: I set up the router to always assign the same address for the MAC address of each Jetson device. Addresses will never change. If you are using something like an address assigned by Comcast, then you have no control over this and it might change any time the system is rebooted or any time when the DHCP lease expires and is reassigned.
Glad to hear that this was as simple as reinstalling the correct ssh software. It simplifies life!