I can’t answer all of your questions, but some information on Ubuntu and the root account and ssh might help. This is a lot, but if you go with keys, then development life will be much easier.
On Ubuntu “root” has no password, nor login ability…at least by default. You are expected to use “sudo”. However, as you probably found out, this can be a real pain. Unless you unlock root you cannot directly login as root. If you can avoid logging in as root you are better off, but if you are on a trusted network (for example my embedded systems all sit on their own private network), then you could unlock root.
The other side of the coin is that by default most Linux distributions (including Ubuntu) don’t allow root to log in via ssh unless you’ve set this up. The changes mentioned for “/etc/ssh/sshd_config” are for that purpose. Combining unlocking of root with allowing root login can do what you want.
Personally, even on a private network (and especially when I want convenience), I find I don’t trust passwords for root login. I instead add ssh keys, and although I allow root login, I only allow via a key, not via password. As a result I can enter commands with an ssh prefix from my host PC to the Jetson more or less as if I am sitting directly at the Jetson terminal.
Unlocking root is fairly easy and painless. Just unlocking root via ssh is also fairly painless, but do realize if you change certain things (such as the IP address or host keys), then you’ll have to fix that when ssh thinks there is a “man in the middle” attack.
So to start with, to unlock root you must log in locally to the Jetson. Set a password for root, and make it a very strong password:
sudo passwd root
# Follow prompts to enter pass twice.
Test the root login. Locally at the Jetson:
su -
Note that “su -” requires root’s password, not the account password you are currently logged in to. Nothing is inherited from the previous login when using this method. If the password works, then you can go to ssh setup. The original URL on ssh setup will do this, but briefly:
- Edit "/etc/ssh/sshd_config"
- Look for "PermitRootLogin", and make sure it is:
# No '#' commenting this out: PermitRootLogin yes - Depending on o/s restarting sshd might differ, but this is probably correct for your version:
sudo systemctl restart sshd.service…or for some flavors or versions of Linux:
sudo service ssh restart - At this point use ssh from your host PC to see if you can login to root at the Jetson's address. You'll need to verify you trust the connection.
- Here it can get a bit more confusing, but I recommend installing keys from host to Jetson for both your regular user and from root on the PC to the root user of the Jetson. This will allow you to disable password logins, and will also enable you to run ssh without being prompted for passwords. Security will improve with key-only access, but this is not required...you could stop here.
- If you already have keys on your host for each user, then you don't have to generate keys. However, most people won't have keys unless they've used key-based logins before, so I'll assume you don't have custom keys for each user you plan to access the Jetson from. Here is a URL on ssh-keygen (part of the "openssh-client" package) which is fairly good: https://www.thegeekdiary.com/using-the-ssh-keygen-command-in-linux/ Note: I like using RSA 2048-bit or better. "man ssh-keygen" and searching for the "-b bits" option will tell you more, but I believe 2048 is still default. You can set higher values in multiples of 2, e.g., you could also use 4096 bit (double 2048). I do not set a password to the key itself. If you do, then you'll be prompted for the key's password, not the remote system's password.
- After you generate a key, then you put this in the right place with the right permissions. There is a ".pub" key which is public and anyone can read this...this is for encrypting, e.g., "id_rsa.pub" is a traditional name. This must be set to be readable by anyone. The private key, "id_rsa" (again, this is a traditional name for RSA keys) must not be readable or in any way touchable by anyone but your account. These keys must go in the "~/.ssh/" directory, which in turn must be readable and executable by anyone, but cannot be writable by anyone but you (ssh will refuse to work if permissions are wrong).
- Next you need to copy your key to the Jetson using the "ssh-copy-id" command. You will log in via the password, and then after the successful login, the Jetson will remember the public key and allow this as a login. You'd use this to copy to both your regular developer account on the Jetson, and again to root on the Jetson. Do not do the reverse...do not give the Jetson permission to access your host. As an example, if your remote developer account name is "ubuntu", with password "ubuntu", and you have unlocked root to have password "maybeImCrazy", and if the remote host has IP address "192.168.1.2", then from your PC:
# Logged in as your regular user who will do the debugging...this is regular user of the host PC, # not the Jetson: # Regular login only just to make sure you have accepted for normal ssh: ssh ubuntu@192.168.1.2 exit ssh root@192.168.1.2 exit ssh-copy-id ubuntu@192.168.1.2 # Enter the "ubuntu" password. exit ssh-copy-id root@192.168.1.2 # Enter the "maybeImCrazy" password. exit # Now disable root login via password, but keep non-password login. Edit "/etc/ssh/sshd_config" again, # and this is what you will have: PermitRootLogin without-password sudo systemctl restart sshd.service # (or perhaps "sudo service ssh restart" on some systems) # Now go back and see if you can log in without entering the password. I'll just send the "whoami" # command instead of actual login (no password should be required): ssh ubuntu@192.168.1.2 exit ssh root@192.168.1.2 exit # You might still have a step with root if this doesn't work,
From then on this PC, if keys do not change, and if you access using the same IP address, should not prompt for a password. The public/private key pair will instead do the job. No system should be able to log in to “root” via any password.
Now to relock root (you can still login via key, but password will be removed…“su -” will not work after that, but “sudo -s” will, and ssh won’t need a password):
sudo passwd -d -l root
If you wish to add other accounts to log in to root via ssh using keys at a later date, then you need to unlock root password again and tell sshd to allow root password login while adding the key. Then lock it back up.
Always always always back up any keys in your host’s “/etc/ssh/” (the naming will make it obvious), and also host keys of the Jetson. Always back up the “~/.ssh/” of your host PC. You didn’t add keys to the individual login accounts of the Jetson, so any “~/.ssh/” doesn’t need backup. If for some reason you lost your Jetson, then there are no keys to worry about. Even if the Jetson were lost, if the IP address changed, then anyone having the lost system would still be unable to get in. Always keep any copy of private keys safe from anyone other than you. Public keys can be handed out any time and will not be a risk. “ssh-copy-id” hands out only public keys.
If for some reason you are debugging with software which mandates using a password, then having keys might not do the job. You can still have the keys, but you’d end up keeping root unlocked and keeping ssh to allow login via password (a bad idea if it can be avoided…also a bad idea if it can’t be avoided). However, there is no technical reason you can’t have keys for most things and still allow a password if you are on a private network or if for some reason you think you can trust this.
Note: There is a case where sometimes you need a second step beyond ssh-copy-id for root logins. If you run into this just post the error message here for more info.
Example of host PC to Jetson things you can do conveniently with keys and no password, while remaining more secure than with passwords (uses example account names and IP addresses…adjust for your case):
ssh ubuntu@192.168.1.2 df -H -T /
ssh root@192.168.1.2 shutdown -r now
ssh root@192.168.1.2 shutdown -h now
ssh ubuntu@192.168.1.2 sha1sum -c /etc/nv_tegra_release
ssh ubuntu@192.168.1.2 head -n 1 /etc/nv_tegra_release
ssh ubuntu@192.168.1.2 cat /etc/issue
ssh root@192.168.1.2
Note: You can copy keys from “/etc/ssh/” to the sample “Linux_for_Tegra/rootfs/etc/ssh/” before a flash, and you can copy individual user keys to the “Linux_for_Tegra/rootfs/home/…some user…/.ssh/” before a flash, and they will “just work” after done. Don’t forget to also copy the sshd_config edits. After flash this will “just work” if IP addresses did not change.