Hello world!

[ISLBA] stands for a young, lateral thinking, solution- and success-oriented company, founded to provide their services to small and medium-sized enterprises as external consultants or for interims management tasks.

If unpopular measures in the company secure its continuity, you can contact us, because sailing at beautiful weather is not our primary mission, some of our focus in skills, methods and skills are optimized for persistent bad weather, black flags and stormy sea.

If you have a problem, if no one else can help, you can hire [ISLBA]


ssh with a yubiKey

simple steps to get an extra layer of security on your ssh connection with a yubiKey and the challenge response and no server side tweaking

This sounds easy but 2 things are needed.

STEP1 check your needs to get this working

need 1 ssh version 8.2 or higher
need 2 firmware on yubikey 5.2.3 or higher

check for need-1 (ssh version / both sides host and target)

ssh -V

check for need-2 (firmware yubikey)

lsusb -v 2>/dev/null | grep -A2 Yubico | grep "bcdDevice" | awk '{print $2}'

STEP-2 install libfido2-dev

apt install libfido2-dev

STEP-3 generate key (part of the new key, derived from a challenge response with the fidou2f will be on the hardware yubikey, so therefore you need to touch the key during this operation as asked)

ssh-keygen -t ed25519-sk -C "yubikey007"

STEP-4 copy the generated public key to the remote host

ssh-copy-id remote_username@remote_server_ip_address

Step-5 ssh in the remote server using the ssh key (and you will get prompted for the challenge response) that means you have to plug in the yubikey and touch it. The magic happens. Have fun!

Be aware ( if you dont’t have the (yubi)key your are not able to log in, also a backup of your SSH key is not working, because of the challenge response its just 1/2 of the ssh-key) If you want to have multi factor auth (not 2FA) on your ssh connection set a password when you generate the ssh-key. Remember if you destroy the hardware key, ore loose it the login is not possible, so be prepared for that scenario. Its a hostile world be prepared to fight.

Maybe these Links will cover some more information:


easier life with custom ssh config file

use this code at your own risk and only if you know what you are doing. no liability from us for the consequences. so leave us alone if things go sideways

I am regularly connecting to multiple remote systems via SSH, and as far as I am concerned I find that remembering all of the remote IPs, the non-standard ssh ports, and various command-line options difficult, annoying, and at some stage or office hour impossible. The option for creating a bash alias file would do the trick, but i guess well not cool, or in other words not the use case I have.

Step 1 located in the /home directory of the user you can find .ssh/config if not, well you have to create the config file. If you want to edit the global config use /etc/ssh/ssh_config (must be readable to all users)

touch /home/user/.ssh/config
sudo chmod 600 home/user/.ssh/config

The config file structure looks something like this, and it is processed from top to bottom. The SSH command from the cli processes its configuration in the following order:

  1. ssh command line-option
  2. /home/user/.ssh/config option
  3. /etc/ssh/ssh_config options

Keep that in mind, if you are using override commands.

Step 2 edit the file for your needs

# comment

Host hostname1
    SSH_OPTION value
    SSH_OPTION value

Host hostname2
    SSH_OPTION value

Use Case to get connected:
ssh -p4422

with config file in /home/userNeeds/.ssh/config that looks something

Host exy
    User userNeeds
    Port 4422

I will just need to type this to get connected:
ssh exy

Pretty fly ha?

These are the Config parameters you can use. (I will not get into Wild Cards and ref exp)
HostName: IP address of the remote server
User: Name of the user, you will log in as 9999
Port: The to connect on the remote server
Protocol: The version of protocol SSH should prefer (multi Values separated by comma)
IdentityFile: Location of file that contains RSA, ECDSA, and DSA authentication Identity
ForwardX11: It allows you to forward the remote server display on your machine
Compression: You want to use compression during the remote server connection or not
ServerAliveinterval: Set a timer in seconds for the server connection and in the given time if no response is received from the server, ssh will send a message to request a response
ServerAliveCountMax: Sets the number of messages that should be sent to request a response from the server
LogLevel: Verbosity level used when logging

So a common use case config looks like something like this

Host grommuo
         HostName grommuo.hatesno.plan
         Port 2222
         Forwardx11 no
         User tec-noP1503
         IdentityFile ~/.ssh/id_rsa
         Protocol 2
         Compression yes
         LogLevel Info

so to get connected tech tech guy only has to type ssh grommuo and is good go, fine thing and makes life easier.

Do not forget to include this config in your backup plan (justsaying)
This article can be interesting in combination with

have Fun !


Disabling SSH password authentication

use this code at your own risk and only if you know what you are doing. no liability from us for the consequences. so leave us alone if things go sideways

Sometimes you feel the need of adding an extra layer of security to your server. You can disable the password authentication for SSH on your server. Feel free to do so if you know what you are up to. I strongly recommend that during this whole operation you have a user logged into the remote machine who has a sudo credentials, just in case something goes sideways 😉

Step 1 log into the server

ssh user@remote-server

Step 2 edit the ssh config file /etc/ssh/sshd_config and change these settings, after the save restart the ssh service

PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no

Step 3 restart the ssh service (depends on your system)

sudo systemctl restart ssh
sudo sudo systemctl restart sshd

Thats all folks !

This blog post can be used with this article 4-step-setup-ssh-login-without-password


4 Step Setup SSH Login without password

A quick and dirty version of how it’s done.

use this code at your own risk and only if you know what you are doing. no liability from us for the consequences. so leave us alone if things go sideways

Step 1 (check if there is any existing key)

ls -al ~/.ssh/id_*.pub

Step 2 (if you find nothing) go and generate a new pair of SSH keys (the keys will be stored in the users /home look for something like .ssh/id_rsa If you found some in Step 1 head up to Step 3

ssh-keygen -t rsa -b 4096 -C ""

Thinking of an extra layer of security enter a password, if no use for that in your use case hit enter (2x) after that, check with ls ~/.ssh/id_* if the key is there, this is gonna look something like .ssh/ and ./ssh/id_rsa in your users home directory

Step 3 Copy the public key (use ssh-copy) to the remote host. While this is gonna happen you will be prompted to enter the password for the remote username (on the remote host) of the ssh key. Once the user is authenticated, the public key will be appended to the remote user authorized_keys file and the connection will be closed. Just a side note you can add the same key to multiple remote serves.

ssh-copy-id remote_username@remote_server_ip_address

Step 4 ssh in the remote server using ssh keys

ssh remote_username@remote_server_ip_address

If that all comes together well, you will be logged in immediately
Enjoy and have Fun !

If for some reason, ssh-copy is not working, you can try this at your own risk, but its is highly recommended to user ssh-copy.

cat ~/.ssh/ | ssh remote_user@remote-server "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Thats all folks !

This article can be also used with disabling-ssh-password-authentication