Locked out due to "wrong password" after a period of time


We have our Jetson AGX Xavier running Jetpack 4.4.1, and we connect to it using SSH over a public network. Locally there are stored IP addresses which exclusively have SSH access to the computer so no one else can connect to it than my team. The computer is usually turned on for long periods of time.

This setup has been well until it suddenly throws “wrong password” when we try to log into it. This goes for both the SSH connection and when we try to connect to it locally effectively locking us out of it. To resolve this we simply re-flashed it and reinstalled everything. But up until now this has happened an additional two times, and re-flashing each time is quite time consuming.

Has anybody else ran into the same issue, or know what the problem might be? Thanks in advance!

It sounds like someone got in and actually changed the password. I know you said you limited it by IP address, but other than that, is this protected by being behind a router, or is it using a publicly facing IP address?

By far the best method of providing access is via ssh key, and disabling password access. There are variations on this, but let’s say you are a regular user, and your login name is “ubuntu”. If you have a key already, then all you have to do to set up the Jetson for access from a PC is this (I’m pretending “jetson” is an IP address, and this is run from a user on a PC):
ssh-copy-id ubuntu@jetson
(then follow the prompting)

For generating keys I prefer RSA 2048-bit or more (4096 is best, I would only use 2048-bit with something underpowered and very slow). If you examine your user’s “~/.ssh/” there would be something similar to (assuming RSA):

# This is what the local machine accepts as that user, not relevant on the PC:
# This is a private key to never be shared and to never be readable by anyone but this user:
# This is a public key and is shared freely. If you've shared this to the Jetson, then this is
# what the Jetson's ~/.ssh/authorized_keys will have in it (and anyone can read it):
# This is just an address-to-account list of what you've said "yes, it is ok to use this" to:

To generate a 4096-bit RSA key, along with a note (you can customize the note):

ssh-keygen -t rsa -b 4096 -C "myname@this_pc_identifier"

This is far far more convenient for developing as well. You could in fact completely disable password-based ssh login via the “/etc/ssh/sshd_config” file. Root has a custom identifier for this specific purpose, and it can choose among “no root ssh login”, “root ssh login only by key”, or “root ssh login including key or password”. The identifier in the file for this has comments with it, and is “PermitRootLogin” (commenting this out effectively denies root, but you can enable root to some particular degree, e.g., setting it to “without-password” means key login, but not password login). You would need to do some reading on sshd_config to see all that it can do. An example would be to temporarily unlock root login locally, set a password, enable root login, have a user ssh to root@that_address, then disable both root password and root password over ssh (this would mean someone with that key could login to root without password, but no password would be accepted either locally or over ssh).

One obscure problem which can show up, but wouldn’t just change (this would always be a problem, or never be a problem, and would not randomly show up) is if the character encoding changes. For example, if the Jetson is looking at passwords as UTF-8, but you are using ssh from a host that uses UTF-16, then probably the password would fail (at least for some characters). You could examine that user’s character set at both ends via “echo $LANG”, but of course you’d need to log in.

For forensics you could clone the rootfs/APP partition and examine the password file. For this to help though you’d have had to have made a clone backup before it changed, otherwise you don’t know what the hashed passwords are. You could repair by putting the clone and a known good set of password files (including group and shadow) back onto the clone, and then flashing with the repaired clone.

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