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:
authorized_keys
# This is a private key to never be shared and to never be readable by anyone but this user:
id_rsa
# 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):
id_rsa.pub
# This is just an address-to-account list of what you've said "yes, it is ok to use this" to:
known_hosts
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.