OpenSS# - Secured Communications

Table of Contents


OpenBSD ships with built in support for OpenSSL and OpenSSH for secure encrypted end-to-end communication between a localhost and a remotehost. Following are notes on configuring and using SS# (pronounced S-S-Sharp, that's a pun)

[Last verified with OpenBSD 3.5 June 2004]

Creating Self-Signed Certificates

[ref: OpenBSD FAQ]
[ref: mod_ssl/ssl_faq.html#ToC17 - html documentation of mod_ssl]
[local: openss# - Secured Communications]
[file: /var/www/conf/httpd.conf]

SSL Communications assume the server has an authentication certificate which acts as a verification for whom the server publishes itself to be, and provides an envelope for the server's public key with which clients can encrypt communications bound for the server.

Creating a certificate was initially meant for a third-party authority to assist you in verifying that the server is who they say they are, so the creation of a self signing certificates requires 3 stages (a) creating a private signing key (b) creating a certificate request, and (c) self-authenticating your certificate request.

We are choosing our file names based on the standard OpenBSD/Apache configuration for SSLfiles

from /var/www/conf/httpd.conf

SSLCertificateFile    /etc/ssl/server.crt
SSLCertificateKeyFile /etc/ssl/private/server.key

1. Generate a Signing key (1024 bit size) :

# /usr/sbin/openssl genrsa -out /etc/ssl/private/server.key 1024

The generated key acts as our RSA private key for our 'internal' CA (Certificate Authority.)

We can call the key anything we want, and the general mod_ssl example is ca.key, but in the above scenario we will use server.key. Check the mod_ssl documentation for why we are only using a key size of 1024.

Security Warning: When you gravitate to a production system you should (at minimum) use -des3 Triple DES encryption and use an authentication pass-phrase for this key. Otherwise, someone can simply steal your key file and sign, authorise other servers masquerading as you.

2. Generate a certificate signing request (csr)

We now generate a csr using the server key generated above (output will be PEM formatted.)

# /usr/sbin/openssl req -new \
  -key /etc/ssl/private/server.key \
  -out /etc/ssl/private/server.csr

The above certificate request will prompt you to reply to a number of questions, most of which can be left as the default. You will be asked for the Fully Qualified Domain Name for this host. In my experience this requires the legitimate DNS name that the host will be responding to.

The last part of the above instructions is to ask for 'extra' attributes.

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

For my test configuration (ie. I don't want to enter the password everytime I want to start Apache) I do not enter a 'challange password.' On a security conscious system, you probably want to specify a challenge password here and have someone on 24-hour availability incase the server restarts and someone must enter the 'challenge password' before the server starts.

The concept is that you send the above CSR for a trusted third party to sign, and record in their system, so users who recieve your key can validate from the trusted third party that you are who you are. But we don't want no third party saying who we are (for now anyway.)

3. Create a self-signed certificate (X509 structure.)

the output will be PEM formatted. (The documentation discusses a script to do this task for you, but I can only find and with similar 'purpose.')

# /usr/sbin/openssl x509 -req -days 365 \
  -in      /etc/ssl/private/server.csr \
  -signkey /etc/ssl/private/server.key \
  -out     /etc/ssl/server.crt

-x509 is the certificate structure we are using.
-days 365 is the number of days for which we want the certificate to be valid

Testing your Keys

You can test from a terminal connection the status of your keys by using the following commands

# openssl rsa -noout -text -in /etc/ssl/private/server.key
# openssl req -noout -text -in /etc/ssl/private/server.csr
# openssl x509 -noout -text -in /etc/ssl/server.crt

Virtual Hosts

Server CRTs for Virtual sites can be generated using the same above process, except you choose a different name for the CSR and CRT. One nice convention is to use the domain name of the site, for example:
Certificate Request: /etc/ssl/private/ and
Certificate: /etc/ssl/

Within the Virtual Host configuration you will then need to specify the appropriate SSL Directive.


    DocumentRoot /var/www/twig
    ErrorLog logs/
    CustomLog logs/ common
    SSLEngine on
    SSLCertificateFile /etc/ssl/
    SSLCertificateKeyFile /etc/ssl/private/server.key


Security Warning: Remember I know less than you about this stuff, the above are just notations of something that worked. It doesn't mean it works well.


Remote Access with ssh

[ref: ssh(1)]
[ref: OpenBSD FAQ4]

When the itch arrives and you just have to get a 'console' connection to that server, telnet is asking for someone to sniff your password and OpenBSD's OpenSSH is the preferred, secureable 'terminal' access system. Ssh is the preferred method of remote access with OpenBSD. There are many features of ssh including the ability to provide a tunnel for other services. The clear advantage of ssh is the full encryption of all communications between the localhost and the remote host.

For the MS Windows fans amongst us there are even ssh clients Windows can run as a terminal window or from the command-prompt.

Communicating with a remote host is usually in the form shown below:

$ ssh

If you don't specify the user-id you wish to login as, then ssh will send the current user-id in which you started ssh (ie. if you are currently logged into your host as johndoe, then ssh will attempt to make the connection using your user-id, johndoe)

Configuring ssh

[Ref: ssh(1)]

ssh checks for its configuration from the command-line, then the user's configuration file ($HOME/.ssh/config), then the system-wide configuration file (/etc/ssh/ssh_config) The files are text files.

Below is an excerpt of what I choose to include in the system wide /etc/ssh_config file

File: /etc/ssh/ssh_config

UseRsh no
FallBackToRsh no
ForwardX11 no
KeepAlive no
Protocol 2,1

More documentation can be found in the man pages (ssh(1).) I choose not to UseRsh or FallBackToRsh because I want secure communications or none. I don't want to be forwarding X11 because I don't run X11 on the servers I'm connecting to. I don't want keepalive 'cause if I'm not doing something with the connection I would prefer it to dump me.

sshd - your ssh server daemon

[ref: sshd(8)]

From the man page: sshd is the daemon that listens for connections from clients. It is normally started at boot from /etc/rc. It forks a new daemon for each incoming connection. The forked daemons handle key exchange, encryption, authentication, command execution, and data exchange. This implementation of sshd supports both SSH protocol version 1 and 2 simultaneously.

System configuration is normally controlled by the /etc/ssh/sshd_config. Below is an excerpt of the config file

File: /etc/ssh/sshd_config

Port 22
ListenAddress ::
HostKey /etc/ssh_host_key
ServerKeyBits 1664
PermitRootLogin yes

The Port directive specifies to listen on the ssh port (22,) obviously this line implies that you can specify a different port to listen to (or add additional ports)

ListenAddress is specifying to listen on all active interfaces (both IPv4 and IPv6).

HostKey specifies the location where the hosts key is to be located. /etc/ssh_host_key is the default location.

ServerKeyBits specifies the size of the key to be generated, the number above is larger than the 568 normally used (is this more secure ?)

Disable Root Login

The afterboot(8) man page recommends that you disable direct login to root through the ssh daemon.

For security reasons, it is bad practice to log in as root during regular use and maintenance of the system. Instead, administrators are encouraged to add a "regular" user, add said user to the "wheel" group, then use the su and sudo commands when root privieges are required.

Edit the /etc/sshd_config file:

PermitRootLogin No

Check through the /etc/ssh/sshd_config for what looks interesting, and look through the man page for further information.

Copying a file through SSH

[Ref: scp(1)]

scp is a utility that allows you to copy files between hosts using the ssh transport. With ssh2 there is also support for gzip style compression of files for transmission.

$ scp files

Author and Copyright

Copyright (c) 2000/1/2 Samiuela LV Taufa. All Rights Reserved.

You are permitted and encouraged to use this guide for fun or for profit as you see fit. If you republish this work in what-ever form, it would be nice (though not enforceable) to be credited.

 OpenSS# - Secure Communications

Copyright  © 2000/1/2 NoMoa.COM All rights reserved.