IDEA: Feature automate external SSH access to Blitz with SSH-pubkey

[cryptomulde]

Hey,
the last days I enjoyed playing with my Blitz and I introduced myself into advanced SSH-networking, which is really powerful if done correctly :)

What I did:
-changed ssh port to port XX (to not be a target for SSH port attacks)
-open new ssh port on router + give dyndns to router (only steps that can not be automated)
-allow new port in UFW and delete old ssh port
-copy pubkey from desktop or phone to Blitz
-restrict password access (only pubkey allowed)
-adapt fail2ban to new port
-(possible add could be to implement google authenticator for additional layer of security)

It took me hours over hours to find all this out, but if done correctly it is easy to do.
It's only complicated for SSH-noobs (like me :D), hence I taught about implementing it as service for raspiblitz.

Using "ssh-copy-id" only works on Linux systems. On Mac for example it needs some tweaking with homebrew and installing ssh-copy-id. I used Terminus on Android and iOS to create keys and added them manually to "authorized.keys" file. We could also "automate" these steps and make it nice and easy for the user via GUI interface.
I imagine having a feature called "External SSH-access". We then let the user choose which device he wants to connect. Depending on input we choose which steps user has to take. (either ssh-copy-id, or manual adding; if ssh-copy-id and uses mac, we show him how to install whats needed to make it possible)

I wrote down my toughts and steps here:

Link: https://www.cyberciti.biz/faq/how-to-disable-ssh-password-login-on-linux/

If wished I can provide it in more details so that @rootzoll has easy steps to implement it.

Tell me what you guys think.

Add: I also tried with standard ssh port 22 to not mess up the config, but it really is annoying having all these failed login attempts on your node and doesn't give you a good feeling at all :)

[fluidvoice]

Is SSH password access a big security problem? How easy is it to break in this way if a good password was chosen?
Just thinking... One easy way to make it more secure is to dis-allow SSH from the Internet and allow it only from the local LAN:

only allowing password authentication from within your network. Add the following to the end of your sshd_config:

PasswordAuthentication no
Match Address 10.0.0.0/8,172.16.0.0/12,192.168.0.0/16
PasswordAuthentication yes

[cryptomulde]

I deactivated SSH-restrictions completely, because I want to have access from the internet.
I agree with only allowing LAN making it more secure, but in my case I needed remote-access via DynDns.
The idea is to create a feature that let's user easily SSH into his raspiblitz from outside.

Add:
We could think about asking the user if he only wants LOCAL setup or also be accessible via remote like @rootzoll does with mobile wallets.

[fluidvoice]

I deactivated SSH-restrictions completely, because I want to have access from the internet.
I agree with only allowing LAN making it more secure, but in my case I needed remote-access via DynDns.
The idea is to create a feature that let's user easily SSH into his raspiblitz from outside.

Add:
We could think about asking the user if he only wants LOCAL setup or also be accessible via remote like @rootzoll does with mobile wallets.

My understanding is the objective of this project it to make full-node use super easy for gen-public use. I would think those people will not want, or we should not require them, to use SSH at all (eventually, though we may not be there yet). Management via web page should be the way to go. If this is being setup for dev's/techies OK, but don't push it by default to all users. Make it an option or a separate script that can be run for those who want it. By default, for most users, we should probably shutoff SSH access from the internet as mentioned above for increased security.

[thelwyn]

My understanding is the objective of this project it to make full-node use super easy for gen-public use. I would think those people will not want, or we should not require them, to use SSH at all (eventually, though we may not be there yet). Management via web page should be the way to go.

To follow-up on this idea of making it user-proof/friendly: since there is an LCD, what about letting the possibility to configure the Raspiblitz directly connecting a keyboard to the Raspberry Pi? Is there a technical requirement I am missing that makes it mandatory to log in through SSH for configuration?

At the moment, at first boot, we get a message giving the IP address and asking to connect through ssh.

Wouldn't that be a possible option to let the possiblity to also keep configuring directly from that screen, assuming that a keyboard has been (temporarily) connected to the RPi?

[openoms]

@cryptomulde Did you look at this nice description by Stadicus? https://github.com/Stadicus/guides/blob/master/raspibolt/raspibolt_20_pi.md#login-with-ssh-keys

[rootzoll]

To make it easy in the future to setup there will be a change to browser setup - like you do with your Alexa or like the CasaNode is doing it. So SSH will be there still for the pros and devs, but it will sit there in the background and should not ne public on the internet by default. So I would not spend to much time on optimizing the SSH. People that know what they are doing, can take some manual steps.

But it can make sense to put sich SSH changes like the Stadicus describes or @cryptomulde set to put into a config script (see directory /home/admin/config.scripts) so that they are more easy to activate and parameters will be stored to the raspiblitz.confso they can be automatically recreated on a update with a fresh sd card.

[nyxnor]

https://stadicus.github.io/RaspiBolt/raspibolt_21_security.html#disable-password-login

An whiptail asking to copy the ssh keys to the Pi first, then after confirming it, rung the second script.

Desktop:

ls -la ~/.ssh/*.pub
ssh-keygen -t rsa -b 4096
ssh-copy-id admin@ip

Pi:

sudo sed -i "s/^ChallengeResponseAuthentication.*/ChallengeResponseAuthentication no/g" /etc/ssh/sshd_config
sudo sed -i "s/^#PasswordAuthentication.*/PasswordAuthentication no/g" /etc/ssh/sshd_config
sudo systemctl restart sshd
exit
ssh admin@ip

[nyxnor]

SSH with PubkeyAuthentication

No password needed, only public key, which is more secure.
The client part cannot be automated. but it is only generating the key and passing to the server.
The server part can be automated.

Client

Generate key

ssh-keygen -t ed25519 -C "your_email@domain.com"

Add the public key on the server

1. The easiest way to copy your public key to your server is to use a command called ssh-copy-id. On your local machine terminal type:

ssh-copy-id remote_username@server_ip_address
## remote_username@server_ip_address's password:

2. If by some reason the ssh-copy-id utility is not available on your local computer you can use the following command to copy the public key:

cat ~/.ssh/id_ed25519.pub | ssh remote_username@server_ip_address "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

3. SCP

scp ~/.ssh/id_ed25519.pub server_user@server_ip:/home/admin/.ssh/authorized_keys/

Server

Make sure dirs exists:

install -m 700 -d /home/admin/.ssh
install -m 600 -d /home/admin/.ssh/authorized_keys

SCP

scp client_user@client_ip:/home/user/.ssh/id_ed25519.pub /home/admin/.ssh/authorized_keys/

Configure ssh daemon

sshd_config="/etc/ssh/sshd_config"

sudo sed -i "s/#PubkeyAuthentication .*/PubkeyAuthentication yes/" "${sshd_config}"
sudo sed -i "s/^PubkeyAuthentication .*/PubkeyAuthentication yes/" "${sshd_config}"

sudo sed -i "s/#ChallengeResponseAuthentication.*/ChallengeResponseAuthentication no/" "${sshd_config}"
sudo sed -i "s/^ChallengeResponseAuthentication.*/ChallengeResponseAuthentication no/" "${sshd_config}"

sudo sed -i "s/#PasswordAuthentication.*/PasswordAuthentication no/" "${sshd_config}"
sudo sed -i "s/^PasswordAuthentication.*/PasswordAuthentication no/" "${sshd_config}"

sudo systemctl restart ssh