Thank you for posting that.
The thing with security through obscurity is that if you take on base value of “security through obscurity”, everything mentioned in this topic becomes in part or in full “security through obscurity”. Both a password and a public key are obscuring a secret in order to remain secure. Which is generally why those are considered the weakest link in allowing remote access. However, this is not what is being referred to in the referred to article.
The general way of determining how to secure a system starts with a risk assessment. This involves determining what the potential attack vectors are, and type of adversary you’re concerned about, and the likelihood of each. For this exercise I’m going to assume a normal uninteresting person and limit the scope to the ssh daemon.
Attack Vectors:
Secret guessing/theft (password): threat likelihood high
Secret guessing/theft: threat likelihood low
Zero day in vulnerability in sshd: threat likelihood moderate
Only allowing public key auth: Mitigates AVs 1 from all sources. (Provides best protection, as it mitigates the most likely attack vectors)
Locking down to a specific ip via firewall: Mitigates all AVs from only script kiddies (attack requires additional step of stealing an ip address, which is unlikely to be scripted as it would likely be hard to code in a generic way)
Locking down to specific ip via sshd config: Mitigates AVs 1&2 from only script kiddies. (attack requires additional step of stealing an ip address, which is unlikely to be scripted as it would likely be hard to code in a generic way)
NOTE: All mitigations depend on use cases.
Security through obscurity (or security by obscurity ) is the reliance in security engineering on design or implementation secrecy as the main method of providing security to a system or component.
From this one can take the design and determine if the knowledge of said design effects the effectiveness of said method:
Only allowing public key authentication: knowledge of this does not help the attacker other than that they will need to steal or guess (practically impossible) the secret.
Locking down to a specific ip address: Knowledge of this is only helpful when targeting a specific host, as you’ll need to do some monitoring to determine where attacks are allowed, which is hard to script generically. Only beneficial for targeted attacks.
Also note the statement “relies upon”. It’s not a bad thing to hide information about your network, as long as it’s not the only thing that stands in the way of being attacked. In fact, it’s good to hide things as long as the cost is negligible, as the less information out there the more work a targeted attacker needs to do (Targeted attacks are generally based on a cost/benefit, and by increasing the cost of the attack you can reduce it’s likelihood). As an individual, it’s not likely you will have someone outside access your network to help you, so there’s little benefit in sharing information about your network.
The bigger picture is: Out of the box, sshd is not going to be acceptable security for me. I have to do something. The tutorial needs to cover something, or multiple somethings. I’m not going to get all bent out of shape regardless of what the option(s) covered is/are, as long as the tutorial doesn’t encourage customers to set up their sshd with weak security.
Perhaps those advocating key-based auth will write up the needed config file changes and other commands for the benefit of the OP.
I suggest a new section under the Community Wiki for Tutorials and then this can be the first tutorial under that section. I wouldn’t link to this topic as it has already become messy and disjointed. In other words, use a topic in the forum to refine and discuss the content, and when you are happy with it, copy the content into a tutorial in the Wiki.
I use key-based auth both with my Pinephone and with a couple of servers I run. Below are a couple links that explain how to generate the keys, and how to make the config changes on your server (or Librem 5, or Pinephone).
From that page (the example is using an account called vivek). Please note that you are creating your keys on the machine you are using to remote into the server (or phone). So, run these commands on your laptop/desktop.
Copy the contents of the id_rsa.pub key (on your laptop) into the ~/.ssh/known_hosts file on the phone. The permissions on the known_hosts file should be 600. The permissions on the .ssh directory should be 700.
Once the contents of the id_rsa.pub key is copied into the known_hosts file, restart your phone (just to be sure), and then you can authenicate using ssh purism@192.168.1.xxx (whatever your ip address is), and you will not be prompted for a password.
To disable the password-based authentication, taken from this site (when it says login as root, that is just your Librem 5 id, run with sudo):
@leetaur, thanks for that. I think it would be helpful if you or someone could write a simple, concise guide (“1. On your computer…, 2. On your L5…, 3. etc.”) from start to finish, like I did with the original post…something that even a brand new Linux user could follow without confusion. I’d do it myself, but I’m not as competent as others here.
Things can even be simpler. On your Linux-based client, start nautilus (the file manager) hit ctrl-l or chose connect to server and use sftp://purism@182.168.x.x as address. There you can navigate through your phones file system and copy files as if they were local.
P.S. Similar things work on different DEs, file managers, and even in MacOS, I think.
P.P.S. sftp uses ssh, so you still need to enable the ssh server in your phone.
In did that for some time, but I had difficulties opening files remotely by applications. The applications could not write the files, even the user had the permissions and were able to override the file by file manager.
For me the solution was sshfs which is also easy as it can get.
If you prefer to do this from the shell, you can use gio mount ... to get the same result, and it may be easier to (semi-)automate from the shell, as distinct from a GUI.
Please see the Community Wiki for the new “Tutorials” section (https://source.puri.sm/Librem5/community-wiki/-/wikis/Tips-&-Tricks), and add to it if you have some useful tips. Above all, keep the language simple and don’t write elliptically…assume you’re instructing complete newbies. Thanks!
I was suggesting to create a new page i.e. a new Tutorial section within the Wiki, and then a new page within that section, rather than a new document section within the Tips and Tricks page.
Otherwise I think Tips and Tricks will end being thousands and thousands of lines long.
Tips and Tricks could perhaps intro and link to any tutorial that someone writes. So Tips and Tricks could explain what you can use SSH for and then link to the tutorial for how to set it up initially.
A new page with expandable individual tutorials would be better, I agree. If you know how to create that, please go ahead. Something like @amosbatto’s FAQ page would be nice.
Though work is starting, so it will have to wait until this evening.