Skip to content

Latest commit

 

History

History
200 lines (152 loc) · 8.12 KB

server-client.md

File metadata and controls

200 lines (152 loc) · 8.12 KB

Installing ufw and SSH on Debian-based distros

Set up client software (local device)

sudo apt install openssh-client

Set up server software (remote device)

sudo apt install openssh-server
sudo systemctl enable ssh

Set up firewall (ufw) on both client and server

sudo apt install ufw

# allow port 22, otherwise SSH does not work
sudo ufw allow ssh

# check if open port 22 rule was successfully added
sudo ufw show added

# activate firewall, if and only if port 22 rule was allowed in previous command
sudo ufw enable

# check again if port 22 is open AND firewall is enabled
sudo ufw status

# BONUS allow port 80 and 443, needed for http and https
sudo ufw allow http
sudo ufw allow https

Background

When ufw is setup without allowing SSH aka port 22 to be open, the "ssh user@ip-address" command will not work. A message such as "ssh: connect to host 192.123.456.789 port 22: Connection timed out" will be returned after a while.

When a VPN service such as Mullvad VPN is running on the server, SSH connection from a client will fail. A message such as "ssh: connect to host 192.123.456.789 port 22: Connection timed out" will be returned after a while.

More about ssh and port 22 here and here

SSH into a VM with OpenSSH server leads to "This host key is known by the following other names/addresses"

This happens when a VM was copied with openssh server pre-installed. During installation OpenSSH will assign a unique ED25519 key fingerprint. Also keys for RSA and ECDSA will be set upl

Remove and purge the current installation of openssh-server, then reinstall openssh-server:

sudo apt purge openssh-server
sudo apt autoremove --purge
sudo apt install openssh-server

SSH into server still asks for user password despite pubkey already setup

This happens when the ssh-agent is not running

Activate the ssh-agent and then run ssh-add:

eval $(ssh-agent -s)
# see note below, bad style, but also works: eval `ssh-agent -s`
# Add the default SSH keys in ~/.ssh to the ssh-agent
ssh-add
# Add a specific key to the ssh-agent
ssh-add ~/.ssh/the-private-key

NOTE: Do not use `command` backticks for command substitution, the prefered method is $(command). See gnu reference.

Log in to the SSH server and set up pubkey

How to Fix “Too many authentication failures” Error / override pubkey identification / force password usage:

# if following command fails due to "Too many authentication failures"
ssh username@IpAddressOfServer

# force ssh to use password instead (=disable pubkey authentication)
ssh username@IpAdressOfServer -o PubkeyAuthentication=no

Set up pubkey on ssh server despite "Too many authentication failures" error:

# if following command fails
ssh-copy-id -i /client/path/to/keyFile.pub username@IpAddressOfServer

# use the command again with additional parameters to enforce password authentication
ssh-copy-id -i /client/path/to/keyFile.pub -o PubkeyAuthentication=no username@IpAddressOfServer

# keep the syntax, otherwise the pubkey copy process will fail
ssh-copy-id [-f] [-n] [-i identity file] [-p port] [-o ssh_option] [user@]hostname

Background

Ssh client machine will try out all available private keys stored in .ssh folder to get access to ssh server. When all of them fail (for example more than 30 private keys were used) and the server only accepts a given amount of attempts (e.g. max 3 attempts), the server will return "Too many authentication failures" and close the connection immediately. If this happens, the ssh client will also be unable to use password login.

Difference between "ssh user@ip-address" and "ssh ip-address"

Using ssh without username assumes that the user you are about to log in to has the same name as the user of the host machine

ssh <ip-address>

Using username before the ip address explicitly tells ssh to login as this user

ssh <username>@<ip-address>

Set up public key manually on ssh server

cd
mkdir .ssh
cd .ssh
vi authorized_keys
# inside autorized keys place the string from client_device_ssh.pub file

How to disable ssh password login on Linux to increase security

Prerequisites:

  • A user account with sudo rights is available on the ssh server
  • Access to the SSH server is already set up correctly with pubkey authentication enabled

Disable password authentication:

# check if following line is present in sshd_config file
grep "Include /etc/ssh/sshd_config.d/\*.conf" /etc/ssh/sshd_config

# create a new file to disable password login/enforce pubkey authentication
sudo nano /etc/ssh/sshd_config.d/disable_root_login.conf

# copy the following lines into /etc/ssh/sshd_config.d/disable_root_login.conf and save it
## rename disable_root_login.conf to disable pubkey authentication / enable password authentcation
## delete the .conf file extension is sufficient
ChallengeResponseAuthentication no
PasswordAuthentication no
UsePAM no
PermitRootLogin no

# reload the ssh service (or completely reboot the server/computer)
sudo systemctl reload ssh
# Difference reload and restart
## reload: The reload command tells the service to re-read its configuration files without stopping the service
## restart: The restart command stops the service and then starts it again

Verify settings:

# try to log in as root
ssh root@ipAdressOfServer

# try to log in with password only
ssh userNameOnServer@ipAdressOfServer -o PubkeyAuthentication=no

# verify all settings at once on ssh server
sudo sshd -T | grep -E -i 'ChallengeResponseAuthentication|PasswordAuthentication|UsePAM|PermitRootLogin'

Root account on SSH Server

Disable root account:

$ sudo passwd -l root

Verify root account is disabled (forum discussion):

$ sudo passwd -S root
# Expected output: "L" after root, then root is disabled
# Undesired output: if "P" after root, then root is enabled!!!
root L yyyy-mm-dd 99999 7 -1

How to Set or Change Hostname in Linux

# check current hostname
echo $HOSTNAME
hostnamectl
# change hostname
sudo hostnamectl set-hostname newHostname
# also edit the config file, change all occurences of the old hostname to the new hostname
## not doing so might lead to a warning after each command issued on the cli
sudo vi /etc/hosts