Asterisk Blacklist Hobby webbhotell


OpenSSL – own certificate authority (CA)

Filed under: Server — Mathz @ 20:50

OpenSSL is a free and open-source cryptographic library that provides several command-line tools for handling digital certificates. Some of these tools can be used to act as a certificate authority.

A certificate authority (CA) is an entity that signs digital certificates. Many websites need to let their customers know that the connection is secure, so they pay an internationally trusted CA (eg, VeriSign, DigiCert) to sign a certificate for their domain.

In some cases it may make more sense to act as your own CA, rather than paying a CA like DigiCert. Common cases include securing an intranet website, or for issuing certificates to clients to allow them to authenticate to a server (eg, Apache, OpenVPN).

Create the root pair

Acting as a certificate authority (CA) means dealing with cryptographic pairs of private keys and public certificates. The very first cryptographic pair we’ll create is the root pair. This consists of the root key (ca.key.pem) and root certificate (ca.cert.pem). This pair forms the identity of your CA.

Typically, the root CA does not sign server or client certificates directly. The root CA is only ever used to create one or more intermediate CAs, which are trusted by the root CA to sign certificates on their behalf. This is best practice. It allows the root key to be kept offline and unused as much as possible, as any compromise of the root key is disastrous.


It’s best practice to create the root pair in a secure environment. Ideally, this should be on a fully encrypted, air gapped computer that is permanently isolated from the Internet. Remove the wireless card and fill the ethernet port with glue.

Prepare the directory

Choose a directory (/root/ca) to store all keys and certificates.

# mkdir /root/ca

Create the directory structure. The index.txt and serial files act as a flat file database to keep track of signed certificates.

# cd /root/ca
# mkdir certs crl newcerts private
# chmod 700 private
# touch index.txt
# echo 1000 > serial

Prepare the configuration file

You must create a configuration file for OpenSSL to use. Copy the root CA configuration file from the Appendix to /root/ca/openssl.cnf.

The [ ca ] section is mandatory. Here we tell OpenSSL to use the options from the [ CA_default ] section.

[ ca ]
# `man ca`
default_ca = CA_default

The [ CA_default ] section contains a range of defaults. Make sure you declare the directory you chose earlier (/root/ca).

[ CA_default ]
# Directory and file locations.
dir               = /root/ca
certs             = $dir/certs
crl_dir           = $dir/crl
new_certs_dir     = $dir/newcerts
database          = $dir/index.txt
serial            = $dir/serial
RANDFILE          = $dir/private/.rand

# The root key and root certificate.
private_key       = $dir/private/ca.key.pem
certificate       = $dir/certs/ca.cert.pem

# For certificate revocation lists.
crlnumber         = $dir/crlnumber
crl               = $dir/crl/ca.crl.pem
crl_extensions    = crl_ext
default_crl_days  = 30

# SHA-1 is deprecated, so use SHA-2 instead.
default_md        = sha256

name_opt          = ca_default
cert_opt          = ca_default
default_days      = 375
preserve          = no
policy            = policy_strict

We’ll apply policy_strict for all root CA signatures, as the root CA is only being used to create intermediate CAs.

[ policy_strict ]
# The root CA should only sign intermediate certificates that match.
# See the POLICY FORMAT section of `man ca`.
countryName             = match
stateOrProvinceName     = match
organizationName        = match
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional

We’ll apply policy_loose for all intermediate CA signatures, as the intermediate CA is signing server and client certificates that may come from a variety of third-parties.

[ policy_loose ]
# Allow the intermediate CA to sign a more diverse range of certificates.
# See the POLICY FORMAT section of the `ca` man page.
countryName             = optional
stateOrProvinceName     = optional
localityName            = optional
organizationName        = optional
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional

Options from the [ req ] section are applied when creating certificates or certificate signing requests.

[ req ]
# Options for the `req` tool (`man req`).
default_bits        = 2048
distinguished_name  = req_distinguished_name
string_mask         = utf8only

# SHA-1 is deprecated, so use SHA-2 instead.
default_md          = sha256

# Extension to add when the -x509 option is used.
x509_extensions     = v3_ca

The [ req_distinguished_name ] section declares the information normally required in a certificate signing request. You can optionally specify some defaults.

[ req_distinguished_name ]
# See <>.
countryName                     = Country Name (2 letter code)
stateOrProvinceName             = State or Province Name
localityName                    = Locality Name
0.organizationName              = Organization Name
organizationalUnitName          = Organizational Unit Name
commonName                      = Common Name
emailAddress                    = Email Address

# Optionally, specify some defaults.
countryName_default             = GB
stateOrProvinceName_default     = England
localityName_default            =
0.organizationName_default      = Alice Ltd
#organizationalUnitName_default =
#emailAddress_default           =

The next few sections are extensions that can be applied when signing certificates. For example, passing the -extensions v3_ca command-line argument will apply the options set in [ v3_ca ].

We’ll apply the v3_ca extension when we create the root certificate.

[ v3_ca ]
# Extensions for a typical CA (`man x509v3_config`).
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

We’ll apply the v3_ca_intermediate extension when we create the intermediate certificatepathlen:0 ensures that there can be no further certificate authorities below the intermediate CA.

[ v3_intermediate_ca ]
# Extensions for a typical intermediate CA (`man x509v3_config`).
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true, pathlen:0
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

We’ll apply the usr_cert extension when signing client certificates, such as those used for remote user authentication.

[ usr_cert ]
# Extensions for client certificates (`man x509v3_config`).
basicConstraints = CA:FALSE
nsCertType = client, email
nsComment = "OpenSSL Generated Client Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
keyUsage = critical, nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage = clientAuth, emailProtection

We’ll apply the server_cert extension when signing server certificates, such as those used for web servers.

[ server_cert ]
# Extensions for server certificates (`man x509v3_config`).
basicConstraints = CA:FALSE
nsCertType = server
nsComment = "OpenSSL Generated Server Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer:always
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth

The crl_ext extension is automatically applied when creating certificate revocation lists.

[ crl_ext ]
# Extension for CRLs (`man x509v3_config`).

We’ll apply the ocsp extension when signing the Online Certificate Status Protocol (OCSP) certificate.

[ ocsp ]
# Extension for OCSP signing certificates (`man ocsp`).
basicConstraints = CA:FALSE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
keyUsage = critical, digitalSignature
extendedKeyUsage = critical, OCSPSigning

Create the root key

Create the root key (ca.key.pem) and keep it absolutely secure. Anyone in possession of the root key can issue trusted certificates. Encrypt the root key with AES 256-bit encryption and a strong password.


Use 4096 bits for all root and intermediate certificate authority keys. You’ll still be able to sign server and client certificates of a shorter length.

# cd /root/ca
# openssl genrsa -aes256 -out private/ca.key.pem 4096

Enter pass phrase for ca.key.pem: secretpassword
Verifying - Enter pass phrase for ca.key.pem: secretpassword

# chmod 400 private/ca.key.pem

Create the root certificate

Use the root key (ca.key.pem) to create a root certificate (ca.cert.pem). Give the root certificate a long expiry date, such as twenty years. Once the root certificate expires, all certificates signed by the CA become invalid.


Whenever you use the req tool, you must specify a configuration file to use with the -config option, otherwise OpenSSL will default to /etc/pki/tls/openssl.cnf.

# cd /root/ca
# openssl req -config openssl.cnf \
      -key private/ca.key.pem \
      -new -x509 -days 7300 -sha256 -extensions v3_ca \
      -out certs/ca.cert.pem

Enter pass phrase for ca.key.pem: secretpassword
You are about to be asked to enter information that will be incorporated
into your certificate request.
Country Name (2 letter code) [XX]:GB
State or Province Name []:England
Locality Name []:
Organization Name []:Alice Ltd
Organizational Unit Name []:Alice Ltd Certificate Authority
Common Name []:Alice Ltd Root CA
Email Address []:

# chmod 444 certs/ca.cert.pem

Verify the root certificate

# openssl x509 -noout -text -in certs/ca.cert.pem

The output shows:

  • the Signature Algorithm used
  • the dates of certificate Validity
  • the Public-Key bit length
  • the Issuer, which is the entity that signed the certificate
  • the Subject, which refers to the certificate itself

The Issuer and Subject are identical as the certificate is self-signed. Note that all root certificates are self-signed.

Signature Algorithm: sha256WithRSAEncryption
    Issuer: C=GB, ST=England,
            O=Alice Ltd, OU=Alice Ltd Certificate Authority,
            CN=Alice Ltd Root CA
        Not Before: Apr 11 12:22:58 2015 GMT
        Not After : Apr  6 12:22:58 2035 GMT
    Subject: C=GB, ST=England,
             O=Alice Ltd, OU=Alice Ltd Certificate Authority,
             CN=Alice Ltd Root CA
    Subject Public Key Info:
        Public Key Algorithm: rsaEncryption
            Public-Key: (4096 bit)

The output also shows the X509v3 extensions. We applied the v3_ca extension, so the options from [ v3_ca ] should be reflected in the output.

X509v3 extensions:
    X509v3 Subject Key Identifier:
    X509v3 Authority Key Identifier:

    X509v3 Basic Constraints: critical
    X509v3 Key Usage: critical
        Digital Signature, Certificate Sign, CRL Sign

Create the intermediate pair

An intermediate certificate authority (CA) is an entity that can sign certificates on behalf of the root CA. The root CA signs the intermediate certificate, forming a chain of trust.

The purpose of using an intermediate CA is primarily for security. The root key can be kept offline and used as infrequently as possible. If the intermediate key is compromised, the root CA can revoke the intermediate certificate and create a new intermediate cryptographic pair.

Prepare the directory

The root CA files are kept in /root/ca. Choose a different directory (/root/ca/intermediate) to store the intermediate CA files.

# mkdir /root/ca/intermediate

Create the same directory structure used for the root CA files. It’s convenient to also create a csr directory to hold certificate signing requests.

# cd /root/ca/intermediate
# mkdir certs crl csr newcerts private
# chmod 700 private
# touch index.txt
# echo 1000 > serial

Add a crlnumber file to the intermediate CA directory tree. crlnumber is used to keep track of certificate revocation lists.

# echo 1000 > /root/ca/intermediate/crlnumber

Copy the intermediate CA configuration file from the Appendix to /root/ca/intermediate/openssl.cnf. Five options have been changed compared to the root CA configuration file:

[ CA_default ]
dir             = /root/ca/intermediate
private_key     = $dir/private/intermediate.key.pem
certificate     = $dir/certs/intermediate.cert.pem
crl             = $dir/crl/intermediate.crl.pem
policy          = policy_loose

Create the intermediate key

Create the intermediate key (intermediate.key.pem). Encrypt the intermediate key with AES 256-bit encryption and a strong password.

# cd /root/ca
# openssl genrsa -aes256 \
      -out intermediate/private/intermediate.key.pem 4096

Enter pass phrase for intermediate.key.pem: secretpassword
Verifying - Enter pass phrase for intermediate.key.pem: secretpassword

# chmod 400 intermediate/private/intermediate.key.pem

Create the intermediate certificate

Use the intermediate key to create a certificate signing request (CSR). The details should generally match the root CA. The Common Name, however, must be different.


Make sure you specify the intermediate CA configuration file (intermediate/openssl.cnf).

# cd /root/ca
# openssl req -config intermediate/openssl.cnf -new -sha256 \
      -key intermediate/private/intermediate.key.pem \
      -out intermediate/csr/intermediate.csr.pem

Enter pass phrase for intermediate.key.pem: secretpassword
You are about to be asked to enter information that will be incorporated
into your certificate request.
Country Name (2 letter code) [XX]:GB
State or Province Name []:England
Locality Name []:
Organization Name []:Alice Ltd
Organizational Unit Name []:Alice Ltd Certificate Authority
Common Name []:Alice Ltd Intermediate CA
Email Address []:

To create an intermediate certificate, use the root CA with the v3_intermediate_ca extension to sign the intermediate CSR. The intermediate certificate should be valid for a shorter period than the root certificate. Ten years would be reasonable.


This time, specify the root CA configuration file (/root/ca/openssl.cnf).

# cd /root/ca
# openssl ca -config openssl.cnf -extensions v3_intermediate_ca \
      -days 3650 -notext -md sha256 \
      -in intermediate/csr/intermediate.csr.pem \
      -out intermediate/certs/intermediate.cert.pem

Enter pass phrase for ca.key.pem: secretpassword
Sign the certificate? [y/n]: y

# chmod 444 intermediate/certs/intermediate.cert.pem

The index.txt file is where the OpenSSL ca tool stores the certificate database. Do not delete or edit this file by hand. It should now contain a line that refers to the intermediate certificate.

V 250408122707Z 1000 unknown ... /CN=Alice Ltd Intermediate CA

Verify the intermediate certificate

As we did for the root certificate, check that the details of the intermediate certificate are correct.

# openssl x509 -noout -text \
      -in intermediate/certs/intermediate.cert.pem

Verify the intermediate certificate against the root certificate. An OK indicates that the chain of trust is intact.

# openssl verify -CAfile certs/ca.cert.pem \

intermediate.cert.pem: OK

Create the certificate chain file

When an application (eg, a web browser) tries to verify a certificate signed by the intermediate CA, it must also verify the intermediate certificate against the root certificate. To complete the chain of trust, create a CA certificate chain to present to the application.

To create the CA certificate chain, concatenate the intermediate and root certificates together. We will use this file later to verify certificates signed by the intermediate CA.

# cat intermediate/certs/intermediate.cert.pem \
      certs/ca.cert.pem > intermediate/certs/ca-chain.cert.pem
# chmod 444 intermediate/certs/ca-chain.cert.pem


Our certificate chain file must include the root certificate because no client application knows about it yet. A better option, particularly if you’re administrating an intranet, is to install your root certificate on every client that needs to connect. In that case, the chain file need only contain your intermediate certificate.

Sign server and client certificates

We will be signing certificates using our intermediate CA. You can use these signed certificates in a variety of situations, such as to secure connections to a web server or to authenticate clients connecting to a service.


The steps below are from your perspective as the certificate authority. A third-party, however, can instead create their own private key and certificate signing request (CSR) without revealing their private key to you. They give you their CSR, and you give back a signed certificate. In that scenario, skip the genrsa and req commands.

Create a key

Our root and intermediate pairs are 4096 bits. Server and client certificates normally expire after one year, so we can safely use 2048 bits instead.


Although 4096 bits is slightly more secure than 2048 bits, it slows down TLS handshakes and significantly increases processor load during handshakes. For this reason, most websites use 2048-bit pairs.

If you’re creating a cryptographic pair for use with a web server (eg, Apache), you’ll need to enter this password every time you restart the web server. You may want to omit the -aes256 option to create a key without a password.

# cd /root/ca
# openssl genrsa -aes256 \
      -out intermediate/private/ 2048
# chmod 400 intermediate/private/

Create a certificate

Use the private key to create a certificate signing request (CSR). The CSR details don’t need to match the intermediate CA. For server certificates, the Common Name must be a fully qualified domain name (eg,, whereas for client certificates it can be any unique identifier (eg, an e-mail address). Note that the Common Name cannot be the same as either your root or intermediate certificate.

# cd /root/ca
# openssl req -config intermediate/openssl.cnf \
      -key intermediate/private/ \
      -new -sha256 -out intermediate/csr/

Enter pass phrase for secretpassword
You are about to be asked to enter information that will be incorporated
into your certificate request.
Country Name (2 letter code) [XX]:US
State or Province Name []:California
Locality Name []:Mountain View
Organization Name []:Alice Ltd
Organizational Unit Name []:Alice Ltd Web Services
Common Name []
Email Address []:

To create a certificate, use the intermediate CA to sign the CSR. If the certificate is going to be used on a server, use the server_cert extension. If the certificate is going to be used for user authentication, use the usr_cert extension. Certificates are usually given a validity of one year, though a CA will typically give a few days extra for convenience.

# cd /root/ca
# openssl ca -config intermediate/openssl.cnf \
      -extensions server_cert -days 375 -notext -md sha256 \
      -in intermediate/csr/ \
      -out intermediate/certs/
# chmod 444 intermediate/certs/

The intermediate/index.txt file should contain a line referring to this new certificate.

V 160420124233Z 1000 unknown ... /

Verify the certificate

# openssl x509 -noout -text \
      -in intermediate/certs/

The Issuer is the intermediate CA. The Subject refers to the certificate itself.

Signature Algorithm: sha256WithRSAEncryption
    Issuer: C=GB, ST=England,
            O=Alice Ltd, OU=Alice Ltd Certificate Authority,
            CN=Alice Ltd Intermediate CA
        Not Before: Apr 11 12:42:33 2015 GMT
        Not After : Apr 20 12:42:33 2016 GMT
    Subject: C=US, ST=California, L=Mountain View,
             O=Alice Ltd, OU=Alice Ltd Web Services,
    Subject Public Key Info:
        Public Key Algorithm: rsaEncryption
            Public-Key: (2048 bit)

The output will also show the X509v3 extensions. When creating the certificate, you used either the server_cert or usr_cert extension. The options from the corresponding configuration section will be reflected in the output.

X509v3 extensions:
    X509v3 Basic Constraints:
    Netscape Cert Type:
        SSL Server
    Netscape Comment:
        OpenSSL Generated Server Certificate
    X509v3 Subject Key Identifier:
    X509v3 Authority Key Identifier:
        DirName:/C=GB/ST=England/O=Alice Ltd/OU=Alice Ltd Certificate Authority/CN=Alice Ltd Root CA

    X509v3 Key Usage: critical
        Digital Signature, Key Encipherment
    X509v3 Extended Key Usage:
        TLS Web Server Authentication

Use the CA certificate chain file we created earlier (ca-chain.cert.pem) to verify that the new certificate has a valid chain of trust.

# openssl verify -CAfile intermediate/certs/ca-chain.cert.pem \
      intermediate/certs/ OK

Deploy the certificate

You can now either deploy your new certificate to a server, or distribute the certificate to a client. When deploying to a server application (eg, Apache), you need to make the following files available:

  • ca-chain.cert.pem

If you’re signing a CSR from a third-party, you don’t have access to their private key so you only need to give them back the chain file (ca-chain.cert.pem) and the certificate (

Certificate revocation lists

A certificate revocation list (CRL) provides a list of certificates that have been revoked. A client application, such as a web browser, can use a CRL to check a server’s authenticity. A server application, such as Apache or OpenVPN, can use a CRL to deny access to clients that are no longer trusted.

Publish the CRL at a publicly accessible location (eg, Third-parties can fetch the CRL from this location to check whether any certificates they rely on have been revoked.


Some applications vendors have deprecated CRLs and are instead using the Online Certificate Status Protocol (OCSP).

Prepare the configuration file

When a certificate authority signs a certificate, it will normally encode the CRL location into the certificate. Add crlDistributionPoints to the appropriate sections. In our case, add it to the [ server_cert ] section.

[ server_cert ]
# ... snipped ...
crlDistributionPoints = URI:

Create the CRL

# cd /root/ca
# openssl ca -config intermediate/openssl.cnf \
      -gencrl -out intermediate/crl/intermediate.crl.pem


The CRL OPTIONS section of the ca man page contains more information on how to create CRLs.

You can check the contents of the CRL with the crl tool.

# openssl crl -in intermediate/crl/intermediate.crl.pem -noout -text

No certificates have been revoked yet, so the output will state No Revoked Certificates.

You should re-create the CRL at regular intervals. By default, the CRL expires after 30 days. This is controlled by the default_crl_days option in the [ CA_default ] section.

Revoke a certificate

Let’s walk through an example. Alice is running the Apache web server and has a private folder of heart-meltingly cute kitten pictures. Alice wants to grant her friend, Bob, access to this collection.

Bob creates a private key and certificate signing request (CSR).

$ cd /home/bob
$ openssl genrsa -out 2048
$ openssl req -new -key \

You are about to be asked to enter information that will be incorporated
into your certificate request.
Country Name [XX]:US
State or Province Name []:California
Locality Name []:San Francisco
Organization Name []:Bob Ltd
Organizational Unit Name []:
Common Name []
Email Address []:

Bob sends his CSR to Alice, who then signs it.

# cd /root/ca
# openssl ca -config intermediate/openssl.cnf \
      -extensions usr_cert -notext -md sha256 \
      -in intermediate/csr/ \
      -out intermediate/certs/

Sign the certificate? [y/n]: y
1 out of 1 certificate requests certified, commit? [y/n]: y

Alice verifies that the certificate is valid:

# openssl verify -CAfile intermediate/certs/ca-chain.cert.pem \
      intermediate/certs/ OK

The index.txt file should contain a new entry.

V 160420124740Z 1001 unknown ... /

Alice sends Bob the signed certificate. Bob installs the certificate in his web browser and is now able to access Alice’s kitten pictures. Hurray!

Sadly, it turns out that Bob is misbehaving. Bob has posted Alice’s kitten pictures to Hacker News, claiming that they’re his own and gaining huge popularity. Alice finds out and needs to revoke his access immediately.

# cd /root/ca
# openssl ca -config intermediate/openssl.cnf \
      -revoke intermediate/certs/

Enter pass phrase for intermediate.key.pem: secretpassword
Revoking Certificate 1001.
Data Base Updated

The line in index.txt that corresponds to Bob’s certificate now begins with the character R. This means the certificate has been revoked.

R 160420124740Z 150411125310Z 1001 unknown ... /

After revoking Bob’s certificate, Alice must re-create the CRL.

Server-side use of the CRL

For client certificates, it’s typically a server-side application (eg, Apache) that is doing the verification. This application needs to have local access to the CRL.

In Alice’s case, she can add the SSLCARevocationPath directive to her Apache configuration and copy the CRL to her web server. The next time that Bob connects to the web server, Apache will check his client certificate against the CRL and deny access.

Similarly, OpenVPN has a crl-verify directive so that it can block clients that have had their certificates revoked.

Client-side use of the CRL

For server certificates, it’s typically a client-side application (eg, a web browser) that performs the verification. This application must have remote access to the CRL.

If a certificate was signed with an extension that includes crlDistributionPoints, a client-side application can read this information and fetch the CRL from the specified location.

The CRL distribution points are visible in the certificate X509v3 details.

# openssl x509 -in -noout -text

    X509v3 CRL Distribution Points:

        Full Name:
openssl rsa -in [file1.key] -out [file2.key]


Check connections to MS SQL

Filed under: Uncategorized — Mathz @ 12:19

SELECT login_name ,COUNT(session_id) AS session_count
FROM sys.dm_exec_sessions
GROUP BY login_name;


Zywall DHCP

Filed under: Uncategorized — Mathz @ 19:19

show ip dhcp binding


Import UTF-8 MySQL dump

Filed under: Uncategorized — Mathz @ 20:55

mysql -uroot -p —default-character-set=utf8 database

mysql> SET names ‘utf8’

mysql> SOURCE utf8.dump


Good commands for MySQL

Filed under: Uncategorized — Mathz @ 19:21
Add user
CREATE USER 'newuser'@'localhost' IDENTIFIED BY 'password';
GRANT ALL PRIVILEGES ON *.* TO 'username'@'localhost' IDENTIFIED BY 'password';
GRANT ALL PRIVILEGES ON database.* TO 'username'@'localhost' IDENTIFIED BY 'password';

Update users password


SFTP Ubuntu 18.04

Filed under: Uncategorized — Mathz @ 20:15


SFTP stands for SSH File Transfer Protocol. As its name suggests, it’s a secure way to transfer files between machines using an encrypted SSH connection. Despite the name, it’s a completely different protocol than FTP (File Transfer Protocol), though it’s widely supported by modern FTP clients.

SFTP is available by default with no additional configuration on all servers that have SSH access enabled. It’s secure and easy to use, but comes with a disadvantage: in a standard configuration, the SSH server grants file transfer access and terminal shell access to all users with an account on the system.

In some cases, you might want only certain users to be allowed file transfers and no SSH access. In this tutorial, we’ll set up the SSH daemon to limit SFTP access to one directory with no SSH access allowed on per-user basis.


To follow this tutorial, you will need access to an Ubuntu 18.04 server. This server should have a non-root user with sudo privileges, as well as a firewall enabled. For help with setting this up, follow our Initial Server Setup Guide for Ubuntu 18.04.

Step 1 — Creating a New User

First, create a new user who will be granted only file transfer access to the server. Here, we’re using the username sammyfiles, but you can use any username you like.

  • sudo adduser sammyfiles

You’ll be prompted to create a password for the account, followed by some information about the user. The user information is optional, so you can press ENTER to leave those fields blank.

You have now created a new user that will be granted access to the restricted directory. In the next step we will create the directory for file transfers and set up the necessary permissions.

Step 2 — Creating a Directory for File Transfers

In order to restrict SFTP access to one directory, we first have to make sure the directory complies with the SSH server’s permissions requirements, which are very particular.

Specifically, the directory itself and all directories above it in the filesystem tree must be owned by root and not writable by anyone else. Consequently, it’s not possible to simply give restricted access to a user’s home directory because home directories are owned by the user, not root.

Note: Some versions of OpenSSH do not have such strict requirements for the directory structure and ownership, but most modern Linux distributions (including Ubuntu 18.04) do.

There are a number of ways to work around this ownership issue. In this tutorial, we’ll create and use /var/sftp/uploads as the target upload directory. /var/sftp will be owned by root and will not be writable by other users; the subdirectory /var/sftp/uploads will be owned by sammyfiles, so that user will be able to upload files to it.

First, create the directories.

  • sudo mkdir -p /var/sftp/uploads

Set the owner of /var/sftp to root.

  • sudo chown root:root /var/sftp

Give root write permissions to the same directory, and give other users only read and execute rights.

  • sudo chmod 755 /var/sftp

Change the ownership on the uploads directory to sammyfiles.

  • sudo chown sammyfiles:sammyfiles /var/sftp/uploads

Now that the directory structure is in place, we can configure the SSH server itself.

Step 3 — Restricting Access to One Directory

In this step, we’ll modify the SSH server configuration to disallow terminal access for sammyfiles but allow file transfer access.

Open the SSH server configuration file using nano or your favorite text editor.

  • sudo nano /etc/ssh/sshd_config

Scroll to the very bottom of the file and append the following configuration snippet:

. . .

Match User sammyfiles
ForceCommand internal-sftp
PasswordAuthentication yes
ChrootDirectory /var/sftp
PermitTunnel no
AllowAgentForwarding no
AllowTcpForwarding no
X11Forwarding no

Then save and close the file.

Here’s what each of those directives do:

  • Match User tells the SSH server to apply the following commands only to the user specified. Here, we specify sammyfiles.
  • ForceCommand internal-sftp forces the SSH server to run the SFTP server upon login, disallowing shell access.
  • PasswordAuthentication yes allows password authentication for this user.
  • ChrootDirectory /var/sftp/ ensures that the user will not be allowed access to anything beyond the /var/sftp directory.
  • AllowAgentForwarding noAllowTcpForwarding no. and X11Forwarding no disables port forwarding, tunneling and X11 forwarding for this user.

This set of commands, starting with Match User, can be copied and repeated for different users too. Make sure to modify the username in the Match User line accordingly.

Note: You can omit the PasswordAuthentication yes line and instead set up SSH key access for increased security. Follow the Copying your Public SSH Key section of the SSH Essentials: Working with SSH Servers, Clients, and Keys tutorial to do so. Make sure to do this before you disable shell access for the user.

In the next step, we’ll test the configuration by SSHing locally with password access, but if you set up SSH keys, you’ll instead need access to a computer with the user’s keypair.

To apply the configuration changes, restart the service.

  • sudo systemctl restart sshd

You have now configured the SSH server to restrict access to file transfer only for sammyfiles. The last step is testing the configuration to make sure it works as intended.

Step 4 — Verifying the Configuration

Let’s ensure that our new sammyfiles user can only transfer files.

Logging in to the server as sammyfiles using normal shell access should no longer be possible. Let’s try it:

  • ssh sammyfiles@localhost

You’ll see the following message before being returned to your original prompt:

Error message
This service allows sftp connections only.
Connection to localhost closed.

This means that sammyfiles can no longer can access the server shell using SSH.

Next, let’s verify if the user can successfully access SFTP for file transfer.

  • sftp sammyfiles@localhost

Instead of an error message, this command will show a successful login message with an interactive prompt.

SFTP prompt
Connected to localhost.

You can list the directory contents using ls in the prompt:

  • ls

This will show the uploads directory that was created in the previous step and return you to the sftp> prompt.

SFTP file list output

To verify that the user is indeed restricted to this directory and cannot access any directory above it, you can try changing the directory to the one above it.

  • cd ..

This command will not give an error, but listing the directory contents as before will show no change, proving that the user was not able to switch to the parent directory.

You have now verified that the restricted configuration works as intended. The newly created sammyfiles user can access the server only using the SFTP protocol for file transfer and has no ability to access the full shell.


You’ve restricted a user to SFTP-only access to a single directory on a server without full shell access. While this tutorial uses only one directory and one user for brevity, you can extend this example to multiple users and multiple directories.

The SSH server allows more complex configuration schemes, including limiting access to groups or multiple users at once, or even limited access to certain IP addresses. You can find examples of additional configuration options and explanation of possible directives in the OpenSSH Cookbook. If you run into any issues with SSH, you can debug and fix them with this troubleshooting SSH series.


Flicd on Raspberry PI 3

Filed under: Uncategorized — Mathz @ 19:34

curl -sSL | sh

sudo usermod -aG docker pi

sudo docker run hello-world

sudo apt-get install libffi-dev libssl-dev python python-pip

sudo pip install docker-compose


Automatically owned by www-data

Filed under: Hemsidor,PHP — Mathz @ 09:50

To make sure any file or folder you create in /var/www/html gets automatically owned by www-data you can use inotify, it’s like cron but monitors folders/files for changes in attribuets, file creations, modifications and much more.

First install it with:

$ sudo apt-get install incron

Allow root to use incron by opening /etc/incron.allow with:

$ sudo vim /etc/incron.allow

and add root to the file, then save and exit.

Edit your incrontab with:

$ sudo incrontab -u root -e

and add the following line to it:

/var/www/html IN_CREATE /bin/chown -R www-data:www-data /var/www/html/

save and exit.

Now as soon as a file is created in the /var/www/html direcotry it will automatically set onwership to www-data:www-data.

Explanation of the line in incrontab:

/var/www/html is the directory that will be monitored.

IN_CREATE will watch for created files. It’s the file change mask.

/bin/chown -R www-data:www-data /var/www/html/ is the command/action to execute.


How do I run graphical programs remotely from a Linux server?

Filed under: Server,Ubuntu — Mathz @ 20:19

It is common for users of the Ubuntu Linux systems to want to run graphical applications (such as matlab, mathematica, eclipse, etc) on these Linux servers and display them on their local computers.  This document details the steps required to do this for Mac

Mac OS X

  1. Install XQuartz on your Mac, which is the official X server software for Mac
  2. Run Applications > Utilities >
  3. Right click on the XQuartz icon in the dock and select Applications > Terminal.  This should bring up a new xterm terminal windows.

  4. In this xterm windows, ssh into the linux system of your choice using the -X argument (secure X11 forwarding).  For example, to log into you would run something like:

         ssh -Y

  5. Once you are logged into the linux system, you can just run the GUI program of your choice (ie. matlab, mathematics, etc) and it will display on your Mac.


Ubuntu 18.04 root DNS update

Filed under: Server,Ubuntu — Mathz @ 00:09
Såg detta i min log fil  
checkhints: ( missing from hints 

Jag åtgärda det genom följande kommando

sudo wget --user=ftp --password=ftp -O /etc/bind/db.root
Older Posts »

Powered by WordPress