Tutorial: Enable Key-based Authentication via ssh on Your Librem 5

This post is to be used after @amarok’s post on enabling ssh access

This post shows how to enable key-based authentication into your Librem 5. This allows you to ssh and scp into the Librem 5 using a private/public key-pair, and to disable password-based authentication into your device. Using private/public key-pair is considered much safer than using password-based authentication.

When the instructions say On computer, they mean your laptop/desktop.
When the instructions say On Librem 5, that means either using the Librem 5 via ssh, or using it directly via keyboard (virtual or physical).

These instructions will also work with a Unix/Linux-based server, or the Pinephone.

  1. Enable ssh access to your Librem 5.

Before enabling key-based authentication on your Librem 5, you need to set up ssh access. Follow the instructions @amarok provided here

  1. On computer, generate the public/private RSA keys.
  • Open a Terminal session your computer
  • Type the following command:

ssh-keygen -t rsa

  1. On computer copy the contents of the id_rsa.pub key onto the Librem 5. The following command will log into your Librem 5, and configure the keys to grant access via the authorized_keys file.

ssh-copy-id -i ~/.ssh/id_rsa.pub purism@host

  • You will be asked for your password into the Librem 5 in this step.
  • Only your public key is copied. Always keep your private key private.
  1. Restart your phone.

  2. On computer, login to your phone using key-based authentication

ssh purism@host (ex. ssh purism@192.168.1.xxx)

  1. On Librem 5, disable password-based authentication

ssh purism@host

  • Use an editor like Nano or Vim to edit the following /etc/ssh/sshd_config using admin rights.

sudo nano /etc/ssh/sshd_config

Find the following line:

PasswordAuthentication yes

And change it to:

PasswordAuthentication no

If there is a # (means commented out) at the beginning of that line, remove it.

Save the file after making these changes and restart the SSH service using this command:

systemctl restart ssh
  1. To test that password-based authentication is actually disabled, from computer, try to ssh into the Librem 5 using a different (or non-existent) id:

ssh otherid@host

You should get the following error:
otherid@host: Permission denied (publickey).

  1. That’s it. You have successfully disabled password based authentication in ssh.



This is a bit tangential, but for those who aren’t scared of having their device on a public network (if you locked down ssh to pubkey only, no root login), you can use something like yggdrasil which gives your device a globally unique cryptographically secure generated ipv6 address that you can use to remote into the device from any other device that runs yggdrasil no matter what network either device is on, as long as they can both reach a public peer that you’ve added to the yggdrasil config.

The debian instructions pretty much work out of the box, and the ipv6 address yggdrasil assigns to the device works with any program that supports ipv6, including ssh, webservers, administration interfaces, minecraft, etc.


Once you have configured like @leetaur explained, you will have to put the password of your key every time you use a SSH based command (ssh, scp, rsync, etc…) into your Librem 5

To ease the use of it, you can temporarily add your key in ssh agent

ssh-add .ssh/id_rsa
Enter passphrase for .ssh/id_rsa:
Identity added: .ssh/id_rsa (.ssh/id_rsa)

So you will have to give your password only once, until the next reboot, or end of user session of your computer

If you let the SSH server running in a public network, a recommendation is to change the port of your SSH server in /etc/ssh/sshd_config
It prevent being detected by bots randomly scanning the first 1000 ports of your IP
But if you do you will have to add the port option in every SSH based command you use


@leetaur, I have added our tutorials to the Community Wiki and linked them back to these corresponding forum discussions. Feel free to make any adjustments or corrections in the Wiki that you see fit. (If you don’t have editing privileges yet, you can request them easily from the Wiki page.)

As others are continually offering various suggestions for remote file transfer and/or different ways of enhancing security, I have labeled your Key-based Authentication method as “Option 1” under the Enhancing Security topic. Those other members are invited to add further security options and/or other file transfer methods to the Wiki. (Please keep the instructions simple.) :slightly_smiling_face:

Thanks @amarok. I’m going through the process to get access to edit the wiki.

1 Like

On top of that, by forcing the bot to scan ports, you give yourself a chance to take countermeasures before the bot even finds the port. That’s what will happen for me at home - the internet gateway will see the suspicious activity and may just block that source IP address. (Things might change if and when mobile providers support IPv6.)

i was under the impression that the MAN internet gateway is a Black-Box that only ISPs have manual control of … or were you referring to the LAN internet-gateway such as a personal router or switch or firewall in your residence ?


I was not expecting the ISP to do this for me (and it would be painful and disruptive if ISPs took it into their heads to be “helpful” like this).

However, that paragraph from me is a bit garbled because …

The blocking I am talking about is when the Librem 5 is connected via WiFi to my home internet and is subject to my internet gateway functionality.

Conversely, when connected to a mobile provider for internet, it completely bypasses my internet gateway and whatever happens, if anything, is a result of actions by the mobile provider. However in my case the mobile provider gives a private IP address (10.a.b.c, and beyond that, in their network, carrier grade NAT) and so the general internet script kiddie can’t port scan anyway. I would suppose that my fellow customers might be able to port scan me - unless the mobile provider is also forcing client isolation.

Hence the relevance of the day when my mobile provider starts to support IPv6. They may not be doing this NAT stuff for IPv6 and then the phone is directly exposed to the internet (for port scanning, and everything else).

1 Like

would you want to just use a simple alias that adds the port option then?

Yes and no.

That will certainly solve the problem as given.

But then when you want to e.g. ssh to some other host with the SSH server on a different port, it won’t by default work. So it depends whether all the devices that you administer use the same port and whether you need to ssh to any devices that you don’t administer.

Also, alias may not cleanly work if someone offers you a shell script to perform some function that involves SSH.

All these issues are solvable. You just need to know your requirements and get organised to meet them.

You can use ~/.ssh/config to define host specific aliases like this:

Host mylibrem
     User username
     Hostname ip.address.or.hostname
     Port 1234

Then you can just ssh mylibrem and it will use the right parameters.


this is like a DNS list for LAN purposes no ?

You could use it that way, but I use it to avoid having to remember which user I use on different machines, and it helps with remembering nonstandard ports too. You can make an alias that points to a machine using DNS so it’s not mutually exclusive. Since I run yggdrasil on my devices, I can put the yggdrasil ipv6 address in the alias and it will work even non on the same lan.

You can make a DNS SRV record that points an alias at a set of specific hostnames and port numbers too. Unfortunately SSH clients don’t widely support that (and it wouldn’t provide a username either).