Creating a swapfile in LInux

Rationale TL;DR

We ran out of memory or we forgot to provide a swap area and we don’t have a partition available

The solution

Another option we have is to use a regular file in the filesystem. The system would able to swap there. We can have as many files as we need (the same happens with dedicated filesystem partitions).

First, let’s create such a file. Let’s suppose 2G would be enough:

# fallocate -l 2G /swapfile 

Now, this file needs to be set up to be used as a swap area:

# mkswap /swapfile

Finally, the file needs to be root-protected, otherwise it would be a security problem:

# chmod 0600 /swapfile

We can now use the file. If we want to use it inmediately:

# swapon /swapfile

If we want to make it permanent, we would need something like this:

# echo '/swapfile none swap sw 0 0' >> /etc/fstab

Happy swapping!

Creating an using a SSH cert authority

Rationale TL;DR

Let’s suppose you would like to use a better solution to authenticate your ssh users all across your infrastructure.

The solution

Since OpenSSH 5.4 (2010) you can create CA (certificate authorities) and use them to authenticate:

  • Users
  • Hosts

It means, you can instruct your ssh deamon to authenticate specific users or authenticate any user from a host. To achieve that, it is advisable to use two different certificate authorities, that way if one is compromised you can still use the other one.

I’ll concentrate on users, a future post would talk about host authorities.

The first step is to create a certificate authority somewhere. It does not matter where you keep those files but you need to understand that the private key must remain safe. If you lose it your CA is compromised.

Let’s first create the user CA authority:

[root@harkserver ~]# ssh-keygen -t ed25519 -b 4096 -f /etc/ssh/harkserver_ed25519_user_ca -C "Harkserver user authority"
Generating public/private ed25519 key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in harkserver_ed25519_user_ca.
Your public key has been saved in harkserver_ed25519_user_ca.pub.
The key fingerprint is:
SHA256:WNvsYXjKyEsLltfED5EXwRJXAcSqzngwk29o6crk6ho Harkserver user authority
The key's randomart image is:
+--[ED25519 256]--+
|        .=*+o.   |
|        .oo.     |
|        +o.      |
|       +.B       |
|     ...S *      |
|    =o.= B .     |
|E . +@= + o      |
| = .=+*o         |
|=o++.oo          |
+----[SHA256]-----+

Let me explain the flags:

  • The -t flag tells ssh-keygen to use the Edwards-curve Digital Signature Algorithm (EdDSA)
  • The -f tells ssh-keygen to keep the private and public keys in the /etc/ssh directory
  • The -b tells ssh-keygen to generate 4096 bits keys
  • The -C adds a comment in the public key

This will generate two files:

[root@harkserver ~]# ls -la /etc/ssh/*harkser*
-rw-------  1 root  wheel   419 Jun 26 10:53 /etc/ssh/harkserver_ed25519_user_ca
-rw-r--r--  1 root  wheel   107 Jun 26 10:53 /etc/ssh/harkserver_ed25519_user_ca.pub

User certificates

Now it’s time to issue user certificates. To do so we need to:

  • Generate the private key and the public key (the public, if I understand it correctly) works as a sort of CSR (signing request)
  • Sign the keys to generate the public certificate that would be used to log

To generate the cert:

[root@harkserver ~]#  ssh-keygen -f /etc/ssh/gus_harkserver_ed25519 -b 4096 -t ed25519
Generating public/private ed25519 key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /etc/ssh/gus_harkserver_ed25519.
Your public key has been saved in /etc/ssh/gus_harkserver_ed25519.pub.
The key fingerprint is:
SHA256:VnIZf3OgnIRk4rO4LS1uMADMtjD+yZ6TUHQMlQNLt/8 root@harkserver
The key's randomart image is:
+--[ED25519 256]--+
|o  +=o. ..+.. .  |
|++..o=.. o.* o . |
|+oo.... + + = o .|
| o..  .. *   . o |
|  +.. ..S        |
| . +o  =.        |
|  o oo+ oE       |
|   = ..o         |
|    ...          |
+----[SHA256]-----+

This generated a public and private keys:

[root@harkserver ~]# ls -la /etc/ssh/*gus*
-rw-------  1 root  wheel  411 Jun 26 11:19 /etc/ssh/gus_harkserver_ed25519
-rw-r--r--  1 root  wheel   97 Jun 26 11:19 /etc/ssh/gus_harkserver_ed25519.pub

Now, it is time to sign the public key. To do so, we need the private CA key:

[root@harkserver ~]# ssh-keygen -s /etc/ssh/harkserver_ed25519_user_ca -I gus@harkserver -n gus /etc/ssh/gus_harkserver_ed25519.pub
Signed user key /etc/ssh/gus_harkserver_ed25519-cert.pub: id "gus@harkserver" serial 0 for gus valid forever

In this example, the ca private key is /etc/ssh/harkserver_ed25519_user_ca. I’m also telling ssh-keygen to add an identifier -I gus@harkserver so that I can identify a user login. Also, I’m granting that key to log as gus with the flag -n.

The resulting files are:

[root@harkserver ~]# ls -la /etc/ssh/*gus*
-rw-------  1 root  wheel  411 Jun 26 11:19 /etc/ssh/gus_harkserver_ed25519
-rw-r--r--  1 root  wheel  650 Jun 26 11:22 /etc/ssh/gus_harkserver_ed25519-cert.pub
-rw-r--r--  1 root  wheel   97 Jun 26 11:19 /etc/ssh/gus_harkserver_ed25519.pub

A new file appeared: /etc/ssh/gus_harkserver_ed25519-cert.pub. This is the public cert file. We can check its contents:

[root@harkserver ~]# ssh-keygen -L -f /etc/ssh/gus_harkserver_ed25519-cert.pub
/etc/ssh/gus_harkserver_ed25519-cert.pub:
        Type: ssh-ed25519-cert-v01@openssh.com user certificate
        Public key: ED25519-CERT SHA256:VnIZf3OgnIRk4rO4LS1uMADMtjD+yZ6TUHQMlQNLt/8
        Signing CA: ED25519 SHA256:WNvsYXjKyEsLltfED5EXwRJXAcSqzngwk29o6crk6ho
        Key ID: "gus@harkserver"
        Serial: 0
        Valid: forever
        Principals:
                gus
        Critical Options: (none)
        Extensions:
                permit-X11-forwarding
                permit-agent-forwarding
                permit-port-forwarding
                permit-pty
                permit-user-rc

As you can see, it’s valid forever. You can use the -V flag to tune the validity of the certificate.

Like the CA files, there’s one file that must remain private, the /etc/ssh/gus_harkserver_ed25519 must remain secret.

Configuring a ssh daemon to trust the User CA

Finally, we need to set up the ssh server so that it trusts the certificates issued by the user CA. To do so, open the sshd_config file (usually /etc/ssh/sshd_config ) and set the TrustedUserrCAKeys config:

TrustedUserCAKeys /etc/ssh/harkserver_ed25519_user_ca.pub

That way the server would trust user certificates signed by the CA. Remember to restart the service. Also, ensure you have another way to log into the machine (maybe a local ssh user with sudo ability or maybe access to the console), otherwise you may shoot yourself in the foot by kicking you out of the machine.

The last step would be to copy those keys to a remote machine and use them to connect to our server. For example, you can change your ~/.ssh/config with the following config:

Host home
    Hostname        my.server.example.org
    User            gus
    Port            22081
    IdentityFile    ~/.ssh/gus_harkserver_ed25519

In another post I’ll also try to explain how to revoke those certificates.

Running powershell as a different user

Rationale TL;DR

We want to use run powershell as a different user, like we do on Unix with sudo

The solution

Easy, the solution is as simple as:

start powershell -credential ""

This would ask you for the new credentials to use:

powershell_sudo