"permission denied" when trying to SSH into Nano 2GB

Hey everyone,

I was following along with the tutorial series on AI here on the developer page with regard to using SSH to interact with my nano 2Gb in headless mode and I ran into some issues. After typing in my IP address and username into the command line I got a message that the “authenticity of the host couldn’t be established”. It then asked me if I wanted to proceed anyway. I typed in ‘yes’ and it then asked me for my password. Once I typed in my password I got this error message: “permission denied. please try again”

Any idea what I might need to do to troubleshoot this situation? Thanks!

By nature of ssh, the first login asking if you trust the host is standard and not an error.

The part where the password is denied is an issue, but the nature depends on a number of details. By default, if you are able to log in locally with that name and password combination, then ssh login should also work (assumes you are not logging in as “root”).

Do you have local login access? Either keyboard/monitor would work, or serial console. If so, then you could run this command on the Jetson, and watch what shows up when you see the permission denied:
sudo tail -f /var/log/auth.log

Sorry I’m a bit of a newb…

Let me see if I understand you correctly. You’re saying that I should attempt to run through the SSH login procedure again from my host computer while also having the nano plugged in to see what it says? I can certainly try…

Another detail I failed to mention is that my password for my nano as well as for ubuntu on my host computer are the same…not sure if that changes anything but figured I should mention…

This is correct.

Having the same password won’t change anything. Neither system will know about the other system’s password. In a way I suppose that simplifies testing since you know the password will always be correct. Just be careful that the ssh login is to the Jetson’s IP address, and not to the host PC’s IP address. You could in fact run a traceroute to the Jetson’s IP address to make sure. I’ll pretend the Jetson has IP address 192.168.55.1. In that case:
traceroute 192.168.55.1

If you don’t have “traceroute”, then:
sudo apt-get install traceroute

I’m pretty sure that i’m routing to the nano’s IP address and not my host pc. On the nano I input ‘ifconfig’ in the command line and got it that way.

Quick update. I have my host PC and nano both operating. I opened a terminal on my nano and entered in the command you recommended. It asked me for my password and when I typed it in and pressed enter i got this: 'sude: tail-f: command not found"

Do I need to install something on my nano?

Make sure there is a space between “tail” and “-f”, and another space between the “-f” and the log file path name. I am also guessing “sude” is a typographic error, but be sure to actually spell it “sudo”.

Both sudo and tail are available by default on all installs, there won’t be anything extra needing install. If either of these are missing, then there are far more serious errors going on.

Sorry yes, ‘sude’ was a typo. Okay, I re-input the command with the spaces you indicated and I received some kind of output that refers to ‘session opened by user root’ etc. What should I be looking for here?

As I read through it a bit closer I am seeing that it’s citing failed attempts by my host machine to login into it the nano. they read as ‘failed password for invalid user [MYUSERNAME] from [HOST IP ADDRESS]’

Apparently what ever password you are typing in from the remote system is not the actual password. There are some cases where this is due to something unexpected, e.g., a character set translation, but this is highly unlikely.

Try logging in locally to the Jetson. Assuming your account name is “nvidia”, try logging in from nvidia locally, but using ssh. While already logged in as nvidia:
ssh nvidia@localhost

What this does is use ssh where user nvidia logs in to user nvidia. You are guaranteed there won’t be any kind of unexpected or rare issue from mixing a remote system in since it is all the local system.

While logging in locally over ssh be sure to monitor sudo tail -f /var/log/auth.log and note if it complains about the password. Try typing your password where it is not hidden, copy it, then paste it when asked for your password. This guarantees a correct password, and if it still fails, then we know it is probably an ssh setup issue.

FYI, if you are typing into a console in the GUI, typically “CTRL-SHIFT-v” will paste.

Hey! Thanks again for following up and for how thorough your responses are…

Okay, I’m going to try this tomorrow morning. I just want to be sure of one thing. When You’re describing logging in locally to the jetson with “nvidia” as my username are you actually instructing me to use the username “nvidia” and follow the instructions accordingly or were you using “nvidia” merely as a placeholder for my username on my nano?

And just to verify: I’m essentially attempting to log into my nano via SSH FROM my nano?

Hey! Quick update…

So I hooked up my nano moments ago and logged in locally to my nano via ssh in the way you described (albeit I was using my own username, not ‘nvidia’) and I feel like I may have discovered something interesting? Perhaps the IP address I was using initially was incorrect…?

When I typed in ‘ssh [USERNAME]@localhost’ it asked if i wanted to continue connecting despite not being able to verify the authenticity of the host-but this is where it got interesting. the IP address it correlated with my nano-the local host was different from the one I attempted to ssh into from my host pc. Am I wrong in thinking that I could have been inputting the incorrect IP the entire time??

okay, another update…

I think I finally did it! My supposition was wrong-the original IP address I had was the correct one. I installed openssh through apt-get and tried ssh’ing into my nano through my host PC. I went through all the normal prompts and when I asked for my password, it accepted it and it output a ‘welcome to ubuntu screen…’

Thanks for toughing it out with me, being patient, and being clear :)

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:

  • ssh nano
  • ssh 192.168.1.9

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!