How-to: Passwordless SSH
While this forum is focused on the Pi-hole software itself and not on the system administration of the host, many people here will be fairly new to the world of Linux and system administration, so things like SSH access may not be fully understood. This post will attempt to answer some of the questions that are likely to come up if you haven't managed a Linux machine before.
For Pi-hole specific questions, see the pinned post in this subreddit
Background on SSH Keys The following section provides some basic background on SSH Keys and public key cryptography. If you already are familiar or are not interested, you may skip this section.
>! SSH is just a protocol for remotely accessing a shell (Secure SHell). Many systems require authentication before accessing the shell, as you can wreak a lot of havoc with shell access. The default method is to use a username and password. This is fine, but passwords are typically either too short to be really secure, or too long to be convenient. Another authentication method uses a technique called public key cryptography to handle the identity verification automatically, without the need for typing a password.
In public key crypto, a user has two keys: a public one and a private one. I won't go into the math, as it's quite complex, but just know that these keys are simply a very large integer encoded as text. The two keys are mathematically entwined, though they have an important property that makes it impossible (within the constraints of modern computers) to derive one key in a pair given the other. Thus, just knowing the public key gives you no information about the private key.
So how is this used for authentication? Well, think of the keys like an identification card, like your passport or drivers license. There is some info on the card that you can give out publicly for other people to verify you (ie the name and photo) and other info that you want to keep “secret” (ie date of birth, card number, etc), lest someone impersonate you. In terms of SSH keys, these correspond to the public and private keys, respectively.
The above analogy isn’t perfect, because you can and do actually share all the info on your license/passport when you give it to someone. However, with SSH keys, the mechanism is a bit different. The private key is used to generate a proof that you are yourself while the public key is used by the other party to verify your proof.
Consider the classical cryptography example of Alice and Bob. Suppose Alice wants to tell a secret to Bob, but needs to be sure it’s really Bob she’s talking to. In person, we might ask for some fact that only Bob would know, like the dish ordered on their first date, but that requires Alice to know the correct answer too. Instead, Alice asks Bob a math problem, which Bob solves using his private key. Alice can then verify the answer using Bobs public key, and if correct then she knows she’s talking to the real Bob. Note that the public key had to be shared with Alice ahead of time.
Back to SSH, we can use the public and private keys in much the same way as Alice and Bob to make sure the person accessing the shell is authorized. By keeping a list of the public keys of the people we want to grant access, we can simply ask a new user this math problem, then try to verify it with each public key we have. If any of them match, we let the user in.
Note that the private key is held by the party trying to prove their identity, while the public key is given to the remote host. The mechanism to share the public key must be trusted (or someone could substitute their own public key instead of yours) and is a fairly complicated part of cryptography. We will ignore that though and assume that you have a trusted way to distribute the key (i.e. by logging in with a password, or physical access to the host). !<
Passwordless SSH Typing a password each time you log into your remote system is tedious. Instead, we can use public/private key pairs to do the authentication automatically, as described in the last section.
This should work for any Unix-like target system, including Raspberry Pi, Linux VM's, etc.
Check for existing SSH Keys You may already have some keys generated on your system. Run the following command on your primary computer to check: bash ls ~/.ssh
If the .ssh directory does not exist, you have no keys, so continue to the next section. If it does, you may see several files, including authorized_keys, known_hosts, id_rsa, id_rsa.pub, etc. If you have two files with names like name and name.pub, those are a key pair. You can either choose to use that or create a new pair by following the steps in the next section.
Create a new key pair See these instructions from Gitlab for a more complete guide.
The basic steps to create a new key pair is to run one of the following two commands on you primary computer: ```bash ssh-keygen -t rsa -b 4096 -C "Comment"
or ssh-keygen -t ed25519 -C "Comment" ```
The -t argument specifies the type of key. RSA and ED25519 are just two different formats for the keys. ED25519 is a more compact representation and the math to verify it is simpler (and thus faster) while potentially being more secure than RSA. That doesn't mean RSA is insecure though, as long as the key size is large enough.
The -b flag sets the key size for the RSA key. The bigger the key, the harder it is to guess the secret ("break the key"). A size of 2048 is the minimum recommended size, with 4096 providing better security without much impact on performance. Larger sizes are possible, but computation becomes more difficult to verify larger keys.
The -C flag allows you to attach a comment to your key. I recommend doing this so you can easily tell what that massive string of letters and numbers corresponds to. I normally use comments like "@", though you may also wish to put the purpose of the key in the comment if you intend to have different keys for different services.
You can usually accept all of the defaults presented by the ssh-keygen command. The exception may be the file name, which you may want to set to something descriptive if you plan on having multiple keys. If you will only use one key, the default of id_rsa or id_ed25519 is fine.
Take note that if you enter a passphrase for the key, it will be required to use the key. This may improve security (if you use a different password than your computer), but kind of defeats the point of passwordless SSH. If you accidentally entered a passphrase, you can reset it with bash ssh-keygen -p -f /path/to/ssh/key
Copying public key Once you've got a key pair that you want to use, we must tell the target system about the public key so it knows how to authenticate you. Note that the private key must be kept a secret on the machine which you will use to log in (the local machine) and should not be copied to the remote machine, posted online, etc.
The easiest way to accomplish this is with the ssh-copy-id: bash ssh-copy-id @
If that fails, you can copy it manually via SSH: bash cat ~/.ssh/.pub | ssh @ 'mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys'
Using SSH key automatically If you chose the default key name, SSH will pick it up automatically and you can skip this section. Otherwise, to ensure that the key is used by the local machine when attempting to authenticate, you must tell the SSH agent about it. First, make sure the agent is running then tall it to add the new key. bash eval "$(ssh-agent -s)" ssh-add /path/to/private/key On macOS, use ssh-add -K /path/to/private/key to store it in the system keychain.
You may also want to update your SSH config, especially if you will be logging in as a user with a different name (ie pi or piuser in the context of Pihole). You may also set a nickname so you can type ssh pi instead of ssh 192.168.0.10 or ssh pi.hole etc. ```bash vim ~/.ssh/config # or nano, atom, gedit, text edit, etc.
Add the following to configure SSH to Host Hostname User PreferredAuthentications publickey, password IdentityFile ~/.ssh/ ```
For more info and tutorials see the following links: * RaspberryPi Docs * Gitlab SSH Key docs * Digital Ocean SSH Key docs
submitted by QWERTYroch
For those struggling with getting used to Openlab...
It was a bit hard for me to adjust to at first, so here's some stuff that might help you:
This allows you to add Openlab as a "drive" in Windows Explorer; you can interact with your Openlab as if it were local. However, it does require the campus Wi-Fi/VPN
(SSH keys, afaik, don't work).
- Install WinFSP, then SSHFS-Win
- In Windows Explorer's sidebar, right-click on This PC → Map Network Drive
- Select a drive letter, and then in folder type [UCI_NET_ID]@openlab.ics.uci.edu
- Enter your credentials, and optionally attempt to re-connect on login.
macOS (and maybe Linux)
, run (you might need your password):
# Installs Homebrew, from https://brew.sh /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/masteinstall.sh)" # Some fixes for issues I ran into with Homebrew compaudit | xargs chmod g-w # Installs SSHFS, which allows you to mount your Openlab as a "local" directory brew update brew install sshfs NOTE
: Assumes macOS with ZSH as default shell (if it was set up on (not
updated to) Catalina, ZSH is already default). This might also work with Bash and/or Linux with adjustments. You can check with echo $0
Setting up an SSH key pair also helps, as it lets you bypass the need for the campus VPN. If you don't have one already, connect to the campus VPN and then run this code (you can hit [ENTER] three times for the default filename + no password, but be mindful of the security implications):
if [[ ! -f $HOME/.ssh/id_rsa && ! -f $HOME/.ssh/id_rsa.pub ]]; then # Creates a SSH key pair in ~/.ssh ssh-keygen fi # Copies the SSH key to Openlab; replace the with yours cat $HOME/.ssh/id_rsa.pub | ssh @openlab.ics.uci.edu "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys"
Then, you should be able to add this function
to your ZSH profile by running (assuming it's saved into ~/Downloads/ssh-mount-fct.txt:
cat $HOME/Downloads/ssh-mount-fct.txt >> $HOME/.zsh_profile source $HOME/.zsh_profile
Now that all the setup is done, you can just run ssh-mount @openlab.ics.uci.edu and your Openlab directory should be in ~/SSHFSemail@example.com (which you should be able to interact with just like a normal folder in Finder). To disconnect from it, just run umount $HOME/SSHFSfirstname.lastname@example.org
I might've messed up the syntax (due to the way my ZSH profile is set up), and there might be other issues with SSHFS so lmk if you run into any issues and I can try and help. Bonus goodies: my ZSH profile and supplementary functions
submitted by Kaipolygon