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.

SSH Authentication with Passwords

By default, SSH server will ask for your password when you’re trying to connect. Unless you specify a username, your SSH client will set it automatically to your username on local (client) system:

In this example above, I’m running command line (iTerm2) session on my Macbook. greys is my local username, maverick is the hostname on my Macbook. I’m typing ssh command and specifying the server to connect to – with hostname becky.

As you can see, next thing that happens is that I get a password prompt.

How Key Based SSH Access Works

Key-based SSH authentication takes an extra step to setup but then saves you tons of time in the future:

• you deploy your public SSH key to remote server (need to type SSH password for possibly the last time)
• you start SSH agent to load your private SSH key and to use it for remote connections
• you connect to the remote SSH server without typing any passwords – still enjoying the same great benefits like encryption and traffic compression that SSH brings

Deploy Your Public SSH Key to Remote Server

You guessed it right! There’s actually a command for that, it’s called ssh-copy-id. What it does is connect to remote SSH server using username and password that you supply and then edit the .ssh/authorized_keys there to include your public key.

When running ssh-copy-id, you need to specify 2 things at a minimum:

1. The SSH identity (name of a key you want to deploy)
2. The SSH server name (where you want to add your key to)

Here’s how it works:

greys@maverick:~ $ ssh-copy-id -i .ssh/id_ed25519 becky
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: ".ssh/id_ed25519.pub" /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
[email protected]'s password:

Number of key(s) added:        1

Now try logging into the machine, with:   "ssh 'becky'"
and check to make sure that only the key(s) you wanted were added.

Next time you attempt to connect, your ssh client will offer remote server a list of SSH identities you have configured on your client. In most recent Unix-like distros you have an SSH agent starting with your graphics login – it’s called GNOME Keyring or or Keychain in MacOS (and there’s plenty of ways to start ssh-agent during startups of sessions like KDE).

The bottom line is that when I try to connect to becky now, my SSH key is offered and, if it’s available (loaded in ssh-agent), I get a passwordless SSH access to remote server:

That’s it for today, have fun!

See Also

• SSH
• SSH port
• SSH port forwarding
• SSH command
• Getting started with Ansible (it uses ssh for access)

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.

See Also

• Debian Linux
• Debian 10 Buster
• SELinux Status
• Disable SELinux
• Enable SELinux

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.

Enjoy!

See Also

• DNSSEC
• Check TLS with openssl command
• Confirm DNS zone TTL with dig
• Switch BIND9 named to IPv4 only

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: rexec_argv[0]=’/usr/sbin/sshd’
debug1: rexec_argv[1]=’-f’
debug1: rexec_argv[2]=’/home/greys/sshd_config.minimal’
debug1: rexec_argv[3]=’-ddd’
debug1: rexec_argv[4]=’-D’
debug3: oom_adjust_setup
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?

See Also

• Basic SSH configuration
• SSH port
• SSH port forwarding
• Getting started with Ansible
• How To Check SSH port status

When running a SELinux based setup, it might be useful to know how to quickly inspect files and directories to confirm their current SELinux context.

What is SELinux Context?

Every process and file in SELinux based environment can be labeled with additional information that helps fulfill RBAC (Role-Based Access Control), TE (Type Enforcement) and MLS (Multi-Level Security).

SELinux context is the combination of such additional information:

• user
• role
• type
• level

In the following example we can see that unconfined_u is the SELinux user, object_r is the role, user_home_dir_t is the object type (home user directory) and the SELinux sensitivity (MCS terminology) level is s0:

drwx------. 17 greys greys unconfined_u:object_r:user_home_dir_t:s0 4096 Feb 19 12:14 .

Use ls -Z to show SELinux Context

Using ls command with -Z option will show the SELinux contexts. This command line option is totally made to be combined with other ls command options:

[greys@rhel8 ~]$ ls -alZ .
total 64
drwx------. 17 greys greys unconfined_u:object_r:user_home_dir_t:s0 4096 Feb 19 12:14 .
drwxr-xr-x. 3 root root system_u:object_r:home_root_t:s0 19 Jan 15 17:34 ..
-rw-------. 1 greys greys unconfined_u:object_r:user_home_t:s0 2035 Feb 19 12:14 .bash_history
-rw-r--r--. 1 greys greys unconfined_u:object_r:user_home_t:s0 18 Oct 12 17:56 .bash_logout
-rw-r--r--. 1 greys greys unconfined_u:object_r:user_home_t:s0 218 Jan 28 17:42 .bash_profile
-rw-r--r--. 1 greys greys unconfined_u:object_r:user_home_t:s0 312 Oct 12 17:56 .bashrc
drwx------. 12 greys greys unconfined_u:object_r:cache_home_t:s0 4096 Jan 21 06:41 .cache
drwx------. 14 greys greys unconfined_u:object_r:config_home_t:s0 278 Jan 21 06:41 .config
drwx------. 3 greys greys unconfined_u:object_r:dbus_home_t:s0 25 Jan 20 18:28 .dbus
drwxr-xr-x. 2 greys greys unconfined_u:object_r:user_home_t:s0 6 Jan 20 18:28 Desktop
drwxr-xr-x. 2 greys greys unconfined_u:object_r:user_home_t:s0 6 Jan 20 18:28 Documents
drwxr-xr-x. 2 greys greys unconfined_u:object_r:user_home_t:s0 6 Jan 20 18:28 Downloads
-rw-------. 1 greys greys unconfined_u:object_r:pulseaudio_home_t:s0 16 Jan 15 19:15 .esd_auth
-rw-------. 1 greys greys unconfined_u:object_r:iceauth_home_t:s0 1244 Jan 20 18:46 .ICEauthority
-rw-------. 1 greys greys unconfined_u:object_r:user_home_t:s0 3434 Jan 22 18:06 id_rsa_4k
-rw-r--r--. 1 greys greys unconfined_u:object_r:user_home_t:s0 737 Jan 22 18:06 id_rsa_4k.pub
-rw-rw-r--. 1 greys greys unconfined_u:object_r:user_home_t:s0 21 Jan 28 17:53 infile2.txt
-rw-------. 1 greys greys unconfined_u:object_r:user_home_t:s0 38 Jan 22 18:05 .lesshst
drwxr-xr-x. 3 greys greys unconfined_u:object_r:gconf_home_t:s0 19 Jan 20 18:28 .local
drwxr-xr-x. 2 greys greys unconfined_u:object_r:audio_home_t:s0 6 Jan 20 18:28 Music
-rw-rw-r--. 1 greys greys unconfined_u:object_r:user_home_t:s0 0 Jan 22 18:01 newkey
drwxr-xr-x. 2 greys greys unconfined_u:object_r:user_home_t:s0 6 Jan 20 18:28 Pictures
drwxrw----. 3 greys greys unconfined_u:object_r:home_cert_t:s0 19 Jan 20 18:28 .pki
drwxr-xr-x. 2 greys greys unconfined_u:object_r:user_home_t:s0 6 Jan 20 18:28 Public
drwxrwxr-x. 4 greys greys unconfined_u:object_r:user_home_t:s0 165 Jan 16 11:00 screenFetch
-rw-------. 1 greys greys unconfined_u:object_r:xauth_home_t:s0 150 Jan 20 18:44 .serverauth.1859
-rw-------. 1 greys greys unconfined_u:object_r:xauth_home_t:s0 50 Jan 20 18:39 .serverauth.1893
drwx------. 2 greys greys unconfined_u:object_r:ssh_home_t:s0 70 Jan 22 18:07 .ssh
-rw-rw-r--. 1 greys greys unconfined_u:object_r:user_home_t:s0 0 Jan 21 07:49 system_u:object_r:shell_exec_t:s0
drwxr-xr-x. 2 greys greys unconfined_u:object_r:user_home_t:s0 6 Jan 20 18:28 Templates
drwxr-xr-x. 2 greys greys unconfined_u:object_r:user_home_t:s0 6 Jan 20 18:28 Videos
-rw-------. 1 greys greys unconfined_u:object_r:user_home_t:s0 2874 Jan 29 04:40 .viminfo
-rw-------. 1 greys greys unconfined_u:object_r:xauth_home_t:s0 260 Feb 19 12:14 .Xauthority

See Also

• Enable SELinux
• Disable SELinux
• Confirm SELinux Status
• Get SELinux mode with getenforce
• Advanced sestatus Usage
• Linux Commands
• SELinux Reference

As you can imagine, SSH keypairs – combinations of private and public keys – are vital elements of your digital identity as a sysadmin or a developer. And since they can be used for accessing source code repositories and for deploying changes to production environments, you usually have more than one SSH key. That’s why it’s important to know how to inspect SSH key fingerprints.

SSH Key Fingerprints

Key fingerprints are special checksums generated based on the public SSH key. Run against the same key, ssh-keygen command will always generate the same fingerprint.

Because of this property, you can use SSH key fingerprints for three things:

1. Identify SSH key – fingerprint will stay the same even if you rename the file
2. Confirm integrity of the SSH key  – if you get the same fingerprint from your private SSH key, you can be sure it’s still valid and intact
3. Validate identity of the SSH key – same fingerprint means you’re dealing with the same key (that you or your solution trusted for specific functionality)

How to Check SSH Fingerprint of a Key

ssh-keygen command takes the identity (SSH key) filename and calculates the fingerprint.

You can start by changing directory into .ssh and checking if you have any SSH keys there already. If not, you should generate a new SSH key.

greys@server:~$ cd .ssh
greys@server:~/.ssh$ ls -la
total 24
drwx------  3 greys greys 4096 Feb 17 21:11 .
drwxr-xr-x 15 greys greys 4096 Feb 17 21:13 ..
-rw-------  1 greys greys 1766 Feb 17 21:11 id_rsa
-rw-r--r--  1 greys greys  394 Feb 17 21:11 id_rsa.pub

Let’s run ssh-keygen to confirm the fingerprint of the id_rsa keypair:

greys@server:~/.ssh$ ssh-keygen -l -f id_rsa
2048 SHA256:z96jtEGIqfLoaq1INIBFI/3K2M+f9xZUyupsm3itgvI no comment (RSA)

Check Fingerprint of the Private SSH Key

By default this command looks for the public key portion (id_rsa.pub file), so it’s not a very good test of integrity or identity of the private key. There is a very real possibility that you have one private key and a separate public key, that are not related to each other.

That’s why for checking the private key you must take it a step further and copy private key (id_rsa) into some other directory where you can use ssh-keygen again:

greys@server:~/.ssh$ cp id_rsa ..
greys@server:~/.ssh$ cd ..

this time, because there’s no public key file found nearby, the ssh-keygen command will have to open private key. And if it’s passphrase protected (as it always should be), you’ll be asked for the SSH key passphrase:

greys@server:~$ ssh-keygen -l -f id_rsa
Enter PEM pass phrase:
2048 SHA256:z96jtEGIqfLoaq1INIBFI/3K2M+f9xZUyupsm3itgvI no comment (RSA)

Old-school SSH fingerprints

If you’ve been using Linux/Unix for more than a couple of years, you probably noticed that ssh-keygen now shows you a different looking fingerprints: they used to be these semicolon-delimited sequences like this:

06:6e:bc:f4:4e:03:90:b7:ba:99:8d:a5:71:1e:dc:22

… instead they now are shown as this:

z96jtEGIqfLoaq1INIBFI/3K2M+f9xZUyupsm3itgvI

The reason for this is that by default fingerprints are shown as SHA256 sequences, while in the past they were MD5.

In order to show the SSH fingerprint in MD5 format, just specify this in the command line:

greys@server:~$ ssh-keygen -l -E md5 -f id_rsa
Enter PEM pass phrase:
2048 MD5:06:6e:bc:f4:4e:03:90:b7:ba:99:8d:a5:71:1e:dc:22 no comment (RSA)

See Also

• How To: Generate SSH key
• How To: Change SSH key passphrase
• SSH port
• SSH port forwarding
• SSH
• Important SSH server configuration options

If you don’t have any other network services running on your Linux system, you probably don’t need portmapper running. Here are the steps to check and to disable portmap.

What portmapper does

Portm apper is a special Unix/Linux service that runs on networked systems that provide RPC (Remote Procedure Call) based services, like NFS.

Port mapper service is called portmapper and always runs on TCP and UDP ports 111.

IMPORTANT: back in 2015 portmapper was confirmed as vulnerable for Distributed Denial of Service attacks (DDoS) – so it’s considered a good practice to disable it or at least protect using firewall.

List RPC services

You can use rpcinfo command to list currently active RPC services on your system.

In my example below there’s nothing else running RPC, just the portmapper itself:

root@s5:~ # rpcinfo -p
program vers proto port service
100000 4 tcp 111 portmapper
100000 3 tcp 111 portmapper
100000 2 tcp 111 portmapper
100000 4 udp 111 portmapper
100000 3 udp 111 portmapper
100000 2 udp 111 portmapper

Stop portmapper in CentOS 7

Somewhat confusing, the service providing portmapper functionality is always called rpcbind.

First, let’s stop the portmapper service:

root@s5:~ # systemctl stop rpcbind
Warning: Stopping rpcbind.service, but it can still be activated by:
rpcbind.socket
root@s5:~ # systemctl stop rpcbind.socket

Prevent portmapper from restarting upon reboot

Now, let’s make sure the service is also disabled:

root@s5:~ # systemctl disable rpcbind
Removed symlink /etc/systemd/system/multi-user.target.wants/rpcbind.service.

And just to confirm it’s all done correctly, let’s run rpcinfo again, it will return an error now:

root@s5:~ # rpcinfo -p
rpcinfo: can't contact portmapper: RPC: Remote system error - Connection refused

See Also

• Unix commands
• Advanced Unix commands
• Unix Tutorial

I learned something new today! Apparently, sestatus command can report security contexts of the key system files – really neat for quickly recognising possible security compromise.

Files and processes in /etc/sestatus.conf

The way this works is you must use the /etc/sestatus.conf file which contains list of files and list of processes that are checked for SElinux contexts. These are the most common security attack vectors, so SElinux notes them and helps you to quickly confirm their contexts using sestatus -v command.

VERY IMPORTANT: at this stage sestatus command does NOT highlight or warn you about any non-standard contextual changes. So the only thing is does is show you all the important files you selected and report their current contexts – if some of these have been changed, the task of recognising or fixing this is still on you.

You can add any files and process you like here, but here’s the default list in RHEL8:

[greys@rhel8 ~]$ cat /etc/sestatus.conf
[files]
/etc/passwd
/etc/shadow
/bin/bash
/bin/login
/bin/sh
/sbin/agetty
/sbin/init
/sbin/mingetty
/usr/sbin/sshd
/lib/libc.so.6
/lib/ld-linux.so.2
/lib/ld.so.1

[process]
/sbin/mingetty
/sbin/agetty
/usr/sbin/sshd

Files and processes contexts with sestatus

[greys@rhel8 ~]$ sestatus -v
SELinux status: enabled
SELinuxfs mount: /sys/fs/selinux.png
SELinux root directory: /etc/selinux.png
Loaded policy name: targeted
Current mode: enforcing
Mode from config file: enforcing
Policy MLS status: enabled
Policy deny_unknown status: allowed
Memory protection checking: actual (secure)
Max kernel policy version: 31

Process contexts:
Current context: unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
Init context: system_u:system_r:init_t:s0

File contexts:
Controlling terminal: unconfined_u:object_r:user_devpts_t:s0
/etc/passwd system_u:object_r:passwd_file_t:s0
/etc/shadow system_u:object_r:shadow_t:s0
/bin/bash system_u:object_r:shell_exec_t:s0
/bin/login system_u:object_r:login_exec_t:s0
/bin/sh system_u:object_r:bin_t:s0 -> system_u:object_r:shell_exec_t:s0
/sbin/agetty system_u:object_r:getty_exec_t:s0
/sbin/init system_u:object_r:bin_t:s0 -> system_u:object_r:init_exec_t:s0
/usr/sbin/sshd system_u:object_r:sshd_exec_t:s0

See Also

• Disable SElinux
• Check SElinux Status
• Security commands in Unix

SSH is such an integral part of everyday Linux/Unix life now, that it makes sense to use it for as many remote access and automation tasks as you can. As you probably know, you shouldn’t be using password SSH authentication unless you have a pretty good reason to do so. By default, always use SSH keys. Today I’ll show you how to generate SSH keys.

Generate SSH key with ssh-keygen

ssh-keygen is a standard utility supplied with SSH package. If you have ssh command on your system, you probably have the ssh-keygen command as well.

Without any command line options, ssh-keygen will ask you a few questions and create the key with default settings:

[greys@rhel8 ~]$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/greys/.ssh/id_rsa):
Created directory '/home/greys/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/greys/.ssh/id_rsa.
Your public key has been saved in /home/greys/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:Seu7UBogeX+g9+iv01CDJqiXAby740JKZGrZtu1T3oQ greys@rhel8
The key's randomart image is:
+---[RSA 2048]----+
|. |
|.. . |
| .+.o ... |
| +oo.+oooo |
|+.+o.o+.S. |
|o*oo ..E . |
|=.o o *o= |
|oo . +.o.o |
|o.. ..+++. |
+----[SHA256]-----+
[greys@rhel8 ~]$

Specify SSH key size for ssh-keygen

Most likely you’ll have your preferences for SSH keys and it is much easier to just specify them when running the ssh-keygen command.

This is how one can generate 4096-bit key, for example:

[greys@rhel8 ~]$ ssh-keygen -b 4096
Generating public/private rsa key pair.
Enter file in which to save the key (/home/greys/.ssh/id_rsa): /home/greys/.ssh/rsa-4k
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/greys/.ssh/rsa-4k.
Your public key has been saved in /home/greys/.ssh/rsa-4k.pub.
The key fingerprint is:
SHA256:4rf1AGIc99L57/xC1PWu7pJpwhkn5YCmZQqua/XdmGA greys@rhel8
The key's randomart image is:
+---[RSA 4096]----+
| |
| .|
| . .. .o|
| .. o=o... . o|
| . .=*S ++ . . |
| ooEo oo.o . .|
| o o.o.=o=.+ . |
| o ..+o=o=oo |
| ... . o.=*o.|
+----[SHA256]-----+

See Also

• SSH
• SSH port
• SSH command
• SSH port forwarding
• Change SSH key passphrase

Shellshock refers to a set of vulnerabilities discovered in late summer 2014 that affects Bash (Bourne again shell), a command line shell program used on all Linux systems and almost all UNIX systems, including Mac OSX. If Bash on your system is still vulnerable it could allow an attacker to take control of parts of your systems and run potentially harmful programs by manipulating the environment variables using this Bash vulnerability.

Fortunately, it is fairly easy to check whether your system is vulnerable, and just as easy to fix it. Just run this one command to test your system:

$ curl https://shellshocker.net/shellshock_test.sh | bash

This is provided by Shellshocker.net, which allows you to easily check your system for the shellshock vulnerability and provides detailed information about it, and how to fix it. The command simply downloads and runs their shellshock_test.sh bash script that probes your installation for all known vulnerabilities and tells you if you’re vulnerable and to which. They list the commands that this script will run on the site, and you can also inspect the script’s code by opening it in a text editor.

If you are vulnerable it just means you need to upgrade Bash on your system to the latest patched version, or apply provided patches. On most Linux distributions just a simple security update should do the trick or you could opt to update only Bash specifically. Here are example update commands for popular distributions:

Fedora

# yum update bash -y

Ubuntu

# apt-get update
# apt-get install --only-upgrade bash

Arch
This is the command to use:

# paceman -Syu

More detailed information including how to build from source if you want to take that route are available at Shellshocker.net.

If you are on Mac OSX you just need to install a patch Apple made available for Mavericks, Mountain Lion, and Lion depending on which of these OSX versions you are on. Installing an update should be as straightforward as launching and running it.

This vulnerability shows just how plausible it is for a massive number of systems to become vulnerable due to a bug in a single ubiquitous piece of software, but more importantly, it underscores the importance of keeping your systems up to date at all times.