Administrators have the ability to get to a command line or "under the hood" of NoTouch using SSH that can be turned on and off as needed
Secure Shell (SSH) is a protocol to remotely connect to another system and get access to and use a shell prompt. You can log in to a NoTouch system via SSH, and this article describes the configuration of the SSH server component that is built into NoTouch. NoTouch uses the well-known embedded/small-footprint dropbear SSH server.
On a single standalone-installed NoTouch system SSH will be "on". However, once it gets configured by NoTouch Center, it will be turned off, as NoTouch Center's default value for the SSH service is "off". We suggest to keep things that way. In normal operation there is no need for SSH. It is there for experienced system administrators to max out their product, only.
Secure Shell service parameters
All the SSH server parameters are part of the "SSH" subsection in "Services".
The parameters are:
- Enable SSH service. The master switch that decides if the SSH server (sshd) is started at all. On a standalone client this is "on", but once it connects to NoTouch Center, it will be switched to "off".
- Allow root login. Usually you should allow root logins unless you define your own user accounts.
- Allow password login. Disabling this would rely totally on the authorized_keys file. In other words, if you deploy an authorized_keys file, you can disable password login.
- Allow password login for root. Even if password login is disabled for all users, it can still be enabled for root only.
- Allow blank password login. Blank password login is usually never a good idea. We strongly recommend to keep this on the default "off" setting.
- Local port forwarding. Allow local port forwarding, if the connecting client requests it.
- Remote port forwarding. Allow remote port forwarding, if the connecting client requests it.
- URL of authorized_keys file. URL pointing to a textual file that will be installed as /root/.ssh/authorized_keys.
- URL of known_hosts file. URL pointing to a textual file that will be installed as /root/.ssh/known_hosts.
- Check certificate on authorized_keys/known_hosts download. When downloading the above files from an HTTPS source, should the certificate be checked, yes or no. In general we highly recommend to say yes here since otherwise somebody else could inject a malicious authorized_keys file through a man-in-the-middle-attack. However, practically speaking, we know many people don't get proper certificates inside their own network and chances somebody would be capable of such an attack inside your corporate network would indicate you have a much bigger problem. Use wisely. The default is "on" (more secure).
Furthermore, you can add SSHd command line options. Please refer to the dropbear software package for available command line parameters and their effects.
Using SSH key-based/passwordless login
Key-based login provides a very secure alternative to regular passwords and allows for excellent scripting capabilites. You could execute Linux commands via script on hundreds or thousands of machines without entering your password every time. SSH is based on public key cryptography, thus any "key" will actually be a key pair consisting of a private key and public key. Sometimes an SSH key is also called an "identity".
First, you need to generate a key pair on any Linux machine:
ssh-keygen
Depending on the actual SSH implementation you will now have two files, one of it named with the extension .pub. The contents of the file ending with .pub are the public portion of the key and you may append this to an authorized_keys file on another system. As long as you are in possession of the non-pub file, you will then be able to passwordless log in to this other system.