System-Administration on WormBytes

Yggdrasil VPN

Robert James Kaes — Thu, 04 May 2023 11:40:56 -0400

I’m trying to work outside my home office more, but all my email is hosted on my home server. While disconnecting is nice, not having access when I need it has sucked.

Enter yggdrasil!

After installing on my laptop (MacOS) and my desktop (Ubuntu) I updated .ssh/config with my desktop’s IPv6 address and was able to SSH via IPv6 over my local network. Perfect!

Step two: install on a server with a public IP. One more service running on my Digital Ocean instance.

I’m not interested, at the moment, with joining the full yggdrasil network, so I configured my public instance to only allow peering from my laptop and desktop’s public keys:

 AllowedPublicKeys: [
"desktop-public-key"
"laptop-public-key"
]

On the public server, I listen via TLS rather than plain TCP. It’s slightly slower, but also slightly more secure. Since I’m not moving a lot of traffic over the connection, the extra security is worth it to me:

 Listen: [
tls://PUBLIC-IP-ADDRESS:56603
]

I couldn’t find a recommended port to listen on, so I picked a random number. 🤣

(The only “gotcha” was remembering to open the firewall for yggdrasil.)

Ramces Red’s article about yggdrasil has more information about installing and configuring a basic VPN.

Secure SSH Keys and Client Configurations

Robert James Kaes — Fri, 08 Dec 2017 14:07:20 -0500

SSH is the backbone to how I’m able to work remotely.

Periodically, it’s important to review both my SSH config settings and regenerate my SSH keys.

From my perspective, Mozilla has put together the best recommendations for both server and client configurations. For now, I’m concentrating on the client configuration (within ~/.ssh/config and my SSH keys.)

OpenSSH Client Configuration

Below is Mozilla’s Modern SSH client configuration recommendation:

# Ensure KnownHosts are unreadable if leaked - it is otherwise easier to know which hosts your keys have access to.
HashKnownHosts yes
# Host keys the client accepts - order here is honored by OpenSSH
HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,ssh-rsa,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp521,ecdsa-sha2-nistp384,ecdsa-sha2-nistp256
KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

Note these are the “modern” recommendations which assumes the services you are connecting to have been updated recently. I’ve noticed I’ve had to modify these for services like Github with:

KexAlgorithms diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1

OpenSSH Key Generation

ED25519 is recommended for all new keys, but not all services support it. For those services we need to fall back to RSA. Using Mozilla’s SSH key generation guidelines, I created a keygen script that defaults to ED25519:

#! /bin/bash
#
# Generate a new ED25519 or RSA SSH key using Mozilla's
# (https://wiki.mozilla.org/Security/Guidelines/OpenSSH#Key_generation)
# recommendations.
#
# Usage: keygen {service_name} [ed25519|rsa]
#
# Defaults to the more secure ED25519.
#

set -e
set -u

service=$1
type=${2:-ed}

case $type in
 ed*)
 ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_${service}_$(date +%Y-%m-%d) -C "Key for ${service}"
 ;;

 rsa)
 ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa_${service}_$(date +%Y-%m-%d) -C "Key for ${service}"
 ;;

 *)
 echo "Usage: keygen {service_name} [ed25519|rsa]"
 exit 1
 ;;
esac

Now you’ll need to send your new key to the remote server. For example:

ssh-copy-id -i ~/.ssh/id_ed25519_wormbytes_2017-12-08 robert@server.wormbytes.ca

Finally update your ~/.ssh/config and modify your IdentityFile to reference the key that was generated. Something like:

IdentityFile ~/.ssh/id_ed25519_wormbytes_2017-12-08

Conclusion

My recommendation is to review your SSH keys and configuration once a year. While the above configuration is the recommendation today (December 2017) it might not be the recommendation next year. Be sure to check back with Mozilla to see if anything needs to be updated.

Norfolk Techies! Your Local Slack Group

Robert James Kaes — Fri, 17 Nov 2017 14:04:17 +0000

As a remote worker in a rural community, I’ve found it difficult to find other technology workers in the area. After speaking with Brett, we decided to start the Norfolk Techies Slack group.

If you’re a technology worker in the Norfolk County area please contact Brett or myself for an invitation link.

Listing all the Hardware on a Server

Robert James Kaes — Thu, 11 Mar 2010 02:47:50 +0000

Short post to serve as a reminder to myself!

Something I need to do often in my job is find out what hardware a particular server has installed.

The best tool I found for the job is HardwareLiSter. On a CentOS system simply do:

sudo yum install lswh

to install and then run:

sudo lshw | less

to see what you’re dealing with.