I have a number of servers, including a few on the home office network, that accept SSH connections. Even though they are serving on different (non-standard) SSH ports, there are regular attempts made to break it via brute-force – I can see how some random IP addresses start trying to log in using different standard user names. It's therefore never too late to use additional software for protecting SSH service, something like fail2ban.[Read more…] about How To: Use fail2ban to Protect SSH
I'm hoping to reinstall my MacBook Pro 15" 2017 with a fresh macOS Catalina sometime soon, and part of preparations is testing my install methods (hello, brew!) and configuration files migration. Today I decided to setup a new SSH keypair.
What is ed25519?
ed25519 is a relatively new cryptography solution implementing Edwards-curve Digital Signature Algorithm (EdDSA).
I say relatively, because ed25519 is supported by OpenSSH for about 5 years now – so it wouldn't be considered a cutting edge. Still, people are such creatures of habits that many IT professionals daily using SSH/SCP haven't even heard of this key type.
Similarly, not all the software solutions are supporting ed25519 right now – but SSH implementatinos in most modern Operating Systems certainly support it.
Why ed25519 Key is a Good Idea
Compared to the most common type of SSH key – RSA – ed25519 brings a number of cool improvements:
- it's faster: to generate and to verify
- it's more secure
- collision resilience – this means that it's more resilient against hash-function collision attacks (types of attacks where large numbers of keys are generated with the hope of getting two different keys have matching hashes)
- keys are smaller – this, for instance, means that it's easier to transfer and to copy/paste them
Generate ed25519 SSH Key
Here's the command to generate an ed25519 SSH key:
greys@mcfly:~ $ ssh-keygen -t ed25519 -C "firstname.lastname@example.org" Generating public/private ed25519 key pair. Enter file in which to save the key (/Users/greys/.ssh/id_ed25519): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /Users/greys/.ssh/id_ed25519. Your public key has been saved in /Users/greys/.ssh/id_ed25519.pub. The key fingerprint is: SHA256:FHsTyFHNmvNpw4o7+rp+M1yqMyBF8vXSBRkZtkQ0RKY email@example.com The key's randomart image is: +--[ED25519 256]--+ | */Xoo | | . . .===..o | | + .Eo+.oo | | o ..o.+. | | . .S + . | | . . . * | | . . . + o . | | o O . | | .*Xo= | +----[SHA256]-----+
That's it – this keypair is ready to be deployed to SSH servers, GitHub or any other service that can use them.
Check out how short the public key is:
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIK0wmN/Cr3JXqmLW7u+g9pTh+wyqDHpSQEIQczXkVx9q firstname.lastname@example.org
I'm fascinated by the improvements and new features in RHEL 8, plus it's a primary distro used in most corporate environments – so expect to quite a number of posts related to it in the nearest future.
The default interface for managing firewalls in RHEL 8 is firewalld and specifically firewall-cmd command.
Show Active Zones in RHEL 8
There's a concept of zones – security domains – in RHEL 8 firewalls. You assign each of available network interfaces on your Red Hat Enterprise Linux system to one or more of these domains.
That's why the first step is to confirm these zones, to see which ones are actively managing access for each network device:
root@rhel8:~ # firewall-cmd --get-active-zones
List All Rules for Firewall Zone in RHEL 8
I'm interested in the primary physical network interface – enp2s0. It belongs to the home zone as per previous command, so that's the zone we'll list all the rules fore:
root@rhel8:~ # firewall-cmd --list-all --zone=home home (active) target: default icmp-block-inversion: no interfaces: enp2s0 sources: services: cockpit dhcpv6-client mdns samba-client ssh ports: 5901/tcp protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules:
From the output below, I have highlighted additionally enabled ports – 5901 is the one for VNC client that allows me to access graphics desktop session on my RHEL 8 PC remotely.
That's it for today! Thanks for stopping by and talk soon!
What sudo does
Using /etc/sudoers file to confirm what privileges are available to you, sudo command effectively elevates your access rights, thus allowing you to run commands and access files which would otherwise be not available to you. sudo runs these commands as root by default.
The meaning of sudo command is:
- su (switch user)
- do action (run the specified command under specified user)
Default user in sudo
Unless specified, user is assumed to be root. So when you're running some sommand using sudo, your specified command is executed as root.
Using one of the most basics examples: id command shows your current username, its user id (UID), group id (GID) and group membership:
greys@s2:~ $ id uid=1000(greys) gid=1000(greys) groups=1000(greys),989(libvirt)
greys@s2:~ $ sudo id uid=0(root) gid=0(root) groups=0(root)
As you can see from the output, we get all the root information returned: UID =0, GID=0.
Apparently, Debian installer doesn't install or activate sudo by default. This means that sudo command is not found the only privilege escalation method available is becoming root via su command. Since I like and use sudo daily, I decided to install and setup it on Debian VM.
Install sudo package in Debian
That's the very first step you'll need to do: use apt to install sudo. You need to become root before you do it, of course (so you must know root user password for your Debian install):
greys@debian:~$ su - Password: root@debian:~ # apt install sudo Reading package lists… Done Building dependency tree Reading state information… Done The following NEW packages will be installed: sudo 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. Need to get 0 B/1,245 kB of archives. After this operation, 3,886 kB of additional disk space will be used. Selecting previously unselected package sudo. (Reading database … 174742 files and directories currently installed.) Preparing to unpack …/sudo_1.8.27-1_amd64.deb … Unpacking sudo (1.8.27-1) … Setting up sudo (1.8.27-1) … Processing triggers for man-db (2.8.5-2) … Processing triggers for systemd (241-5) … root@debian:~ # sudo usage: sudo -h | -K | -k | -V usage: sudo -v [-AknS] [-g group] [-h host] [-p prompt] [-u user] usage: sudo -l [-AknS] [-g group] [-h host] [-p prompt] [-U user] [-u user] [command] usage: sudo [-AbEHknPS] [-r role] [-t type] [-C num] [-g group] [-h host] [-p prompt] [-T timeout] [-u user] [VAR=value] [-i|-s]  usage: sudo -e [-AknS] [-r role] [-t type] [-C num] [-g group] [-h host] [-p prompt] [-T timeout] [-u user] file …
Configure /etc/sudoers File
/etc/sudoers is the main configuration file for sudo command. It contains list of users and groups that are allowed to become root (or become other users by invoking su command as root).
Here's the default file in Debian 10 Buster:
root@debian:~ # cat /etc/sudoers # # This file MUST be edited with the 'visudo' command as root. # # Please consider adding local content in /etc/sudoers.d/ instead of # directly modifying this file. # # See the man page for details on how to write a sudoers file. # Defaults env_reset Defaults mail_badpass Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" # Host alias specification # User alias specification # Cmnd alias specification # User privilege specification root ALL=(ALL:ALL) ALL # Allow members of group sudo to execute any command %sudo ALL=(ALL:ALL) ALL # See sudoers(5) for more information on "#include" directives: #includedir /etc/sudoers.d
I've highlighted the 3 most important elements of this file at this early stage:
root ALL=(ALL:ALL) ALL
This is the line that allows you to debug sudo commands as root user.
At this means that any user that belongs to group sudo will also be allowed to use sudo commands:
%sudo ALL=(ALL:ALL) ALL
Finally, this part includes additional configuration files from /etc/sudoers.d directory:
… this means you don't have to edit /etc/sudoers file but instead can create a specific file in /etc/sudoers.d and name it self-descriptively, like:
meaning, that this file will contain usernames and privileges required by web-server admins (usually commands like stopping/starting Apache or nginx webserver).
Since this is a very basic tutorial, we don't have to edit the file at all – just need to add our user (mine is greys, as you remember) to the sudo group and check.
Add user to sudo group
Step 1: let's make sure sudo is not accessible before we begin
This needs to be run as your regular user, not as root:
greys@debian:~$ sudo -i [sudo] password for greys: greys is not in the sudoers file. This incident will be reported. greys@debian:~$
Let's check my groups just to be sure there's no sudo among them:
greys@debian:~$ id greys uid=1000(greys) gid=1000(greys) groups=1000(greys),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),108(netdev),112(bluetooth),116(scanner)
Step 2: add user to sudo group
Excellent, now it's time to add user greys to the group sudo (we must become root again to run usermod command)
root@debian:~ # usermod -a -G sudo greys
root@debian:~ # id greys
uid=1000(greys) gid=1000(greys) groups=1000(greys),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),108(netdev),112(bluetooth),116(scanner)
As you can see, I'm now a member of the sudo group!
Step 3: Log out and log back in for group membership to be recognised
greys@debian9:~$ id uid=1000(greys) gid=1000(greys) groups=1000(greys),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),108(netdev),112(bluetooth),116(scanner)
so yes, we're a member of sudo group now… This is the moment of truth! Let's try to become root:
greys@debian:~$ sudo -i root@debian:~ # id uid=0(root) gid=0(root) groups=0(root)
Tha'ts it for today!
What is Kali Linux?
Kali Linux is a Debian-based Linux distro made by security professionals (Offensive Security) for security assessments, penetration testing and digital forensics. It comes with hundreds of open-source tools grouped for effective use and optimized for speedy network discovery and vulnerability assessment.
How To Download Kali Linux
I downloaded a normal ISO image to see how installer works, but it's also possible to just get the VirtualBox VM image with Kali Linux.
Kali Linux Installation Screenshots
Here are the screens of my install process – nothing unusual and a fairly smooth install process.
I think I got them here in the right order, but if something's off and not straightforward – let me know!
As always, I had to do install more than once because disk size is suggested as 8GB in VirtualBox which is not enough for modern Debian derived installs – so installer fails halfway and you need to expand the disk – I've seen the same issues trying to install Debian 10 Buster.
Will try and install it onto Raspberry Pi 4 as one of the upcoming Unix Tutorial projects.
One of the greatest improvements introduced by the SSH protocol is key-based authentication – meaning your client and SSH server establish validity of your SSH keypair and let you gain remote SSH access without asking for your password.[Read more…] about Deploy Your SSH key To Remote Server
AppArmor is a Linux Kernel security module that implements mandatory access control (MAC) security with per-application profiles in Debian based systems. It's possible to confirm if AppArmor is enabled in your Debian or Ubuntu system and to also find out the mode it's running in.
AppArmor Status with aa-status Command
aa-status command will list the currently loaded AppArmor modules.
For instance, here's how it looks on a system where AppArmor is inactive (Debian 9 in my case):
root@debian9:~# aa-status apparmor module is loaded. apparmor filesystem is not mounted.
And here is how AppArmor status is reported on Debian 10 system where it's activated by default:
root@debian10:~# aa-status apparmor module is loaded. 20 profiles are loaded. 18 profiles are in enforce mode. /usr/bin/evince /usr/bin/evince-previewer /usr/bin/evince-previewer//sanitized_helper /usr/bin/evince-thumbnailer /usr/bin/evince//sanitized_helper /usr/bin/man /usr/lib/telepathy/mission-control-5 /usr/lib/telepathy/telepathy-* /usr/lib/telepathy/telepathy-*//pxgsettings /usr/lib/telepathy/telepathy-*//sanitized_helper /usr/lib/telepathy/telepathy-ofono libreoffice-senddoc libreoffice-soffice//gpg libreoffice-xpdfimport man_filter man_groff nvidia_modprobe nvidia_modprobe//kmod 2 profiles are in complain mode. libreoffice-oopslash libreoffice-soffice 0 processes have profiles defined. 0 processes are in enforce mode. 0 processes are in complain mode. 0 processes are unconfined but have a profile defined.
Cloudflare, possibly the best DNS provider (and so much more) available for free, is hosting CryptoWeek 2019 since Monday. I really like this company and host at least 20 DNS zones for my various domains there.
I'm just catching up on reading and thought the Crypto Week 2019 announcement post is a must read for everyone.
While generally the week is spent announcing various improvers around crypto (as in cryptocurrencies), the announcement post talks about broader set of issues with current Internet and about the most recent efforts to vastly improve it.
If TLS, BGP hijacking or DNSSEC mean anything to you (and even more importantly, if they don't yet!) – please read the Crypto Week 2019 post as you will learn a lot and receive a bunch of great pointers for further reading.
Sometimes you need to tweak your SSH daemon on an important system and you just don't know if particular settings will break connectivity to the server or not. In such cases it's best to test new SSHd config using separate SSH daemon instance and separate SSH port – debug it there and only then apply new configs into your primary SSHd configuration.
Creating New SSHd Config
The easiest is to start by copying /etc/ssh/sshd_config file – you will need sudo/root privileges for that:
greys@s2:~ $ sudo cp /etc/ssh/sshd_config /home/greys
I then just remove everything I don't need from it, leaving bare minimum. These are the parameters I kept (I ended up renaming my config to /home/greys/sshd_config.minimal after edits)
greys@s2:~ $ grep -v ^# /home/greys/sshd_config.minimal | uniq -u Port 2222 HostKey /etc/ssh/ssh_host_rsa_key RSAAuthentication yes PubkeyAuthentication yes AuthorizedKeysFile /var/ssh/%u/authorized_keys PasswordAuthentication no UsePAM yes
I only updated the SSH Port parameter – you can pick any other number instead of 2222.
Starting SSH daemon with custom config file
There's a few rules for testing SSH configuration using separate file:
- you need to have sudo/root privilege (mostly to avoid mess with host SSH keys)
- it's better to increase verbosity level to see what's going on
- it's best to run SSHd in foreground (non-daemon) mode
With these principles in mind, here's the command line to test the config shown above:
greys@s2:~ $ sudo /usr/sbin/sshd -f /home/greys/sshd_config.minimal -ddd -D
debug2: load_server_config: filename /home/greys/sshd_config.minimal
debug2: load_server_config: done config len = 194
debug2: parse_server_config: config /home/greys/sshd_config.minimal len 194
debug3: /home/greys/sshd_config.minimal:1 setting Port 2222
debug3: /home/greys/sshd_config.minimal:10 setting HostKey /home/greys/ssh_host_rsa_key
debug3: /home/greys/sshd_config.minimal:12 setting RSAAuthentication yes
/home/greys/sshd_config.minimal line 12: Deprecated option RSAAuthentication
debug3: /home/greys/sshd_config.minimal:13 setting PubkeyAuthentication yes
debug3: /home/greys/sshd_config.minimal:18 setting AuthorizedKeysFile /var/ssh/%u/authorized_keys
debug3: /home/greys/sshd_config.minimal:20 setting PasswordAuthentication no
debug3: /home/greys/sshd_config.minimal:22 setting UsePAM yes
debug1: sshd version OpenSSH_7.4, OpenSSL 1.0.2k-fips 26 Jan 2017
debug1: private host key #0: ssh-rsa SHA256:g7xhev6zJefXRFc0ClAG4rzpFI1Ts8H7PhQ/h3PTmLM
debug1: Set /proc/self/oom_score_adj from 0 to -1000
debug2: fd 3 setting O_NONBLOCK
debug1: Bind to port 2222 on 0.0.0.0.
Server listening on 0.0.0.0 port 2222.
debug2: fd 4 setting O_NONBLOCK
debug3: sock_set_v6only: set socket 4 IPV6_V6ONLY
debug1: Bind to port 2222 on ::.
Server listening on :: port 2222.
That's it, the configuration is ready to be tested (assuming your firewall on server doesn't block port 2222).
Testing SSH connectivity using Different SSH Port
Here's my login session in a separate window, connecting from my MacBook Pro to the s2 server on SSH port 2222 (I have masked my static IP with aaa.bbb.ccc.ddd and my s2 server's IP with eee.fff.ggg.hhh):
greys@MacBook-Pro:~ $ ssh s2 -p 2222 Warning: untrusted X11 forwarding setup failed: xauth key data not generated Last login: Fri May 24 15:53:59 2019 from aaa.bbb.ccc.ddd debug3: Copy environment: XDG_SESSION_ID=14813 debug3: Copy environment: XDG_RUNTIME_DIR=/run/user/1000 Environment: USER=greys LOGNAME=greys HOME=/home/greys PATH=/usr/local/bin:/usr/bin MAIL=/var/mail/greys SHELL=/bin/bash SSH_CLIENT=aaa.bbb.ccc.ddd 64168 2222 SSH_CONNECTION=aaa.bbb.ccc.ddd 64168 eee.fff.ggg.hhh 2222 SSH_TTY=/dev/pts/14 TERM=xterm-256color XDG_SESSION_ID=14813 XDG_RUNTIME_DIR=/run/user/1000 SSH_AUTH_SOCK=/tmp/ssh-ajOUyvbR6i/agent.20996 greys@s2:~ $ uptime 16:18:08 up 86 days, 17:32, 2 users, load average: 1.00, 1.02, 1.05
Pretty cool, huh?