SSH/SSL Configuration on Solaris 8
Content
- Overview
- Set environment
- Install gcc
- Install bc
- Download Apache
- Build OpenSSL
- Build OpenSSH
- Start OpenSSH
- Build mod_ssl
- Compile Apache
- httpd.conf
- Test
- Certificate Authorities
- Creating your own client certificates
- Use Secure Shell (ssh)
- Use Secure Copy (scp)
- Use Secure FTP (sftp)
- Self-Signed Certificates
Overview
Here are three ways to configure OpenSSH and OpenSSL on a Sun Solaris 8 system:
- Download source code and compile.
- Download binaries and install using pkgadd
- Install binaries using pkg-get
Although installing binaries using pkgadd and pkg-get are the fastest way, I've encountered problems getting them to configure correctly on Solaris 8. Installing via source code and compiling seems to be the safest way to get a working configuration.
- Install gcc
Solaris 8 does not come with an ANSI-C compiler. Download gcc from sunfreeware.com and install with pkgadd -d, or download and install using pkg-get install gcc.
- Install bc
The default copy of bc does not compile with OpenSSL. Download and and install with pkgadd -d.
- Build OpenSSL
- Log onto your box as root
- Download, unzip, and untar an OpenSSL distribution.
gzip -d -c openssl-0.9.6c.tar.gz | tar xvf -- Though probably not recommended, I like to open up permissions when installing:
umask 000- Configure OpenSSL
cd openssl-distribution ./config -fPIC- Compile OpenSSL
make clean make make test make install
- Download Apache
- Download Apache 1.3.24 source at http://httpd.apache.org/dist/httpd/
- Unpack the distribution into /install
gzip -d -c apache_1.3.24.tar.Z | tar xvf -
- Build PRNGD PRNGD is a random-number generator.
- Build OpenSSH
- Download the portable version of OpenSSH
- All the required and optional components must be built and installed before configuring OpenSSH. Here are various options:
--with-pam Enables use of the Pluggable Authentication Module (PAM) architecture for Solaris OE. --disable-suid-ssh Installs the ssh command without the set-UID bit. This will prevent a root compromise if a vulnerability is found in the ssh command. A side effect is that .rhosts authentication is disabled. --sysconfdir=DIRECTORY Places the OpenSSH configuration files and cryptographic keys in the specified directory. By default on the Solaris OE, these files are stored in the /usr/local/etc directory. --with-prngd-socket=FILE Enables optional PRNGD support. Provide the filename for socket file. Traditionally, the socket file is /var/run/egd-pool --without-rsh Prevents fallback to insecure rsh in case of a failure to connect through SSH1 or SSH2 protocols. --prefix=DIRECTORY Specifies the top-level OpenSSH installation directory. To configure OpenSSH to use the gcc compiler and PRNGD, enter the following command:
$ ./configure --prefix=/opt/OBSDssh \
--with-pam \
--without-rsh \
--disable-suid-ssh \
--sysconfdir=/etc \
--with-prngd-socket=/var/run/egd-poolTo build OpenSSH, enter the following command:
$ make
To install OpenSSH, enter the following command:
$ su
Password/ password
# PATH=$PATH//usr/ccs/bin
# export PATH
# make install
# ls -l /opt/OBSDssh/bin/ssh"
-rwxr-xr-x 1 root other 1451384 May 18 22/14 ssh- Configure /etc/sshd_config to the level of authentication required. Making passphrases required, for example.
- Start OpenSSH
- Start an sshd daemon running
An init script is required for the automatic start of both the sshd and PRNGD daemons. The init script allows for a standard method of starting and stopping a service. There are also some housekeeping issues involved. The sshd daemon requires initial key generations and PRNGD requires initial seed generations. The openssh.server script takes care of these issues. The installation of this script is included with the installation of the OBSDssh package.
To start OpenSSH, enter the following commands:
$ su
Password/ password
# /etc/init.d/openssh.server startTo stop OpenSSH, enter the following commands:
$ su
Password/ password
# /etc/init.d/openssh.server stopIf you run into a situation where only the root user can ssh out to other boxes, run:
# chmod go+rw /devices/pseudo/random* # ls -l /devices/pseudo/random* crw-rw-rw- 1 root sys 195, 0 Aug 19 17:14 /devices/pseudo/random@0:random crw-rw-rw- 1 root sys 195, 1 Aug 19 17:14 /devices/pseudo/random@0:urandom
- Build mod_ssl
- Download the latest mod_ssl distribution at http://www.modssl.org/source/mod_ssl-2.8.8-1.3.24.tar.gz
- Unpack the distribution
gzip -d -c mod_ssl-2.8.8-1.3.24.tar.gz | tar xvf -- Review the INSTALL and the README files
- Configure mod_ssl
cd mod_ssl-2.8.8-1.3.24 ./configure --with-apache=../apache_1.3.24
- Compile Apache on Unix
- Cd into the distribution directory.
- Make sure /usr/ccs/bin and gcc are in your $PATH
- Configure the makefile:
export SSL_BASE=../openssl-0.9.6c ./configure --with-layout=Apache \ --prefix=/usr/local/apache \ --enable-module=ssl \ --enable-shared=ssl \ --enable-module=so \ --enable-module=rewriteIf you have to run this configuration again, note that configure saves the latest configure command in config.status. If you have a different version of OpenSSL make sure you set the SSL_BASE environment variable correctly. Remember that the --prefix option points to where you want Apache installed.
- Build Apache and certificates:
make make certificate or make certificate TYPE=customWhen you build the certificates, you will be asked the following questions/
- Signature algorithm/ RSA or DSA (choose RSA)
- DN (Distinguished Name) fields (country/state/city/company/personal name/emails)
- Certificate version 1 or 3 (choose 3)
- Choice to encrypt the server.key file Y or N (do it but remember it since you will need it each time you start Apache SSL
When the process is done you will have generated the following.
RESULT/ CA and Server Certification Files o conf/ssl.key/ca.key The PEM-encoded RSA private key file of the CA which you can use to sign other servers or clients. KEEP THIS FILE PRIVATE! o conf/ssl.crt/ca.crt The PEM-encoded X.509 certificate file of the CA which you use to sign other servers or clients. When you sign clients with it (for SSL client authentication) you can configure this file with the 'SSLCACertificateFile' directive. o conf/ssl.key/server.key The PEM-encoded RSA private key file of the server which you configure with the 'SSLCertificateKeyFile' directive (automatically done when you install via APACI). KEEP THIS FILE PRIVATE! o conf/ssl.crt/server.crt The PEM-encoded X.509 certificate file of the server which you configure with the 'SSLCertificateFile' directive (automatically done when you install via APACI). o conf/ssl.csr/server.csr The PEM-encoded X.509 certificate signing request of the server file which you can send to an official Certificate Authority (CA) in order to request a real server certificate (signed by this CA instead of our own CA) which later can replace the conf/ssl.crt/server.crt file.- If this is a new install of Apache, run:
make installNote the location of your Apache installation - we will refer to this as $APACHE_HOME. Your output will look something like this:
+--------------------------------------------------------+ | You now have successfully built and installed the | | Apache 1.3 HTTP server. To verify that Apache actually | | works correctly you now should first check the | | (initially created or preserved) configuration files | | | | /usr/local/apache/conf/httpd.conf | | | and then you should be able to immediately fire up | | Apache the first time by running/ | | | | /usr/local/apache/bin/apachectl start | | | Or when you want to run it with SSL enabled use/ | | | | /usr/local/apache/bin/apachectl startssl | | | Thanks for using Apache. The Apache Group | | http://www.apache.org/ | +--------------------------------------------------------+- If you are just regenerating the certs for an existing install of Apache:
- Copy freshly created certs to your Apache server, using the name of the domain to distinguish these certs from other certs.
cp conf/ssl.key/ca.key $APACHE_HOME/conf/ssl.key/domain-ca.key cp conf/ssl.crt/ca.crt $APACHE_HOME/conf/ssl.crt/domain-ca.crt cp conf/ssl.key/server.key $APACHE_HOME/conf/ssl.key/domain.key cp conf/ssl.crt/server.crt $APACHE_HOME/conf/ssl.crt/domain.crt cp conf/ssl.csr/server.csr $APACHE_HOME/conf/ssl.csr/domain.csr- Update httpd.conf to reflect the cert names.
- Editing httpd.conf
When you install mod_ssl, a sample httpd.conf file is placed in $APACHE_HOME/conf. This file should have a section entitled/ "# Dynamic Shared Object (DSO) Support". Here is a sample httpd.conf file.
- Testing
- Stop apache, if it is running:
cd $APACHE_HOME/bin apachectl stop- Restart apache in SSL mode
apachectl startsslIf you choose to encrypt your server key, you will be prompted for the pass phrase
- Point your browser to a file with the http protocol on your server - make sure it works.
- Point your browser to a file with the https protocol and the correct port - after accepting the server certificate you should see the page.
- Obtaining a certificate from a Certificate Authority
These are the instructions for generating a CSR request as defined by GeoTrust
- Log onto your box
- Go to the ssl.key directory for your Apache server:
cd /usr/local/apache/conf/ssl.key- Generate an RSA key. You will be prompted for a passphrase to use when starting your webserver. If you lose or forget the passphrase, purchase another certificate. Here is an example:
openssl genrsa -des3 -rand /var/run/egd-pool -out www.yourdomain.com.key 1024- Create a CSR with the RSA private key (output will be PEM format). You will be prompted for your passphrase.
$openssl req -new -key www.yourdomain.com.key -out www.yourdomain.com.csrWhen creating a CSR follow these conventions. Enter the information to be displayed in the certificate. The following characters can not be accepted/ < > ~ ! @ # $ % ^ * / \ ( ) ?.,&
DN Field Explanation Example Common Name The fully qualified domain name for your web server. This must be an exact match. If you intend to secure the URL https///www.yourdomain.com, then your CSR's common name must be www.yourdomain.com. Organization The exact legal name of your organization. Do not abbreviate your organization name. YourCompany Organization Unit Section of the organization Development City or Locality The city where your organization is legally located. San Mateo State or Province The state or province where your organization is legally located. Can not be abbreviated. California Country The two-letter ISO abbreviation for your country. US Notes/
- If you would like to verify the contents of the CSR, use the following command/
$ openssl req -noout -text -in www.yourdomain.com.csr- Leave the challenge password blank
- At some point it might ask for "YOUR name". This is not your name, this is the common name, i.e., www.yourdomain.com. If you use your name, the CSR will not be accepted.
- Submit your CSR to GeoTrust, you will be asked to complete the agreement and the enrollment form as well.
- Make a copy of the private key file (www.yourdomain.com.key) generated in step 3 and store it in a safe place! If you lose this file, purchase a new certificate. The private key file should begin with/
-----BEGIN RSA PRIVATE KEY-----and end with
-----END RSA PRIVATE KEY-----.- To view the contents of the private key, use the following command/
$ openssl rsa -noout -text -in www.yourdomain.com.key- Submit the CSR request (www.yourdomain.com.csr) to GeoTrust.
- Your QuickSSL certificate will be sent to you by email. The email message includes the web server certificate that you purchased in the body of the email message.
- Copy the certificate from the body of the email and paste it into a text editor (such as notepad) to create text files.
- Using the text, create two certificate files/
- /usr/local/apache/conf/ssl.crt/filename.crt
- /usr/local/apache/conf/ssl.crt/filenameCA.crt
Copy the entire contents of the certificate, including -----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----, into both of these files.
- Edit /etc/httpd.conf.
- Find the VirtualHost directives pertaining to your internet domain and verify that the SSL certificate directives are pointing at your files. Here is an example.
SSLCertificateFile /usr/local/apache/conf/ssl.crt/geotrust.crt
SSLCertificateKeyFile /usr/local/apache/conf/ssl.key/www.yourdomain.com.key
SSLCACertificateFile /usr/local/apache/conf/ssl.crt/geotrustca.crt- Save the changes and exit the editor.
- Start or Restart your apache web server using one of the following commands:
/usr/local/apache/bin/apachectl startsslNote/ You may refer to the original ModSSL instructions at:
http://www.modssl.org/source/exp/mod_ssl/pkg.mod_ssl/INSTALLTest your certificate by using a browser to connect to your server. Use the https protocol directive (e.g. https///your server/) to indicate you wish to use secure HTTP.
Note/ The padlock icon on your browser will be displayed in the locked position if your certificates are installed correctly and the server is properly configured for SSL.
GeoTrust will replace, revoke, and refund certificates that have been issued within seven (7) days of the certificate issue date. If you need a new certificate after seven days, you will be responsible for purchasing a new server certificate.
To use mod_ssl in a production environment, you need at a minimum to be your own Certificate Authority. More likely, a certificate signed by a recognized CA like Verisign will be required.
- Create new directory under $APACHE_HOME/conf:
cd $APACHE_HOME/conf mkdir newCA- Copy openssl.cnf and CA.sh from the OpenSSL apps directory to your new directory:
cp ../../openssl-0.9.6c/apps/openssl.cnf newCA: cp ../../openssl-0.9.6c/apps/CA.sh newCA:- Edit your new copy of openssl.cnf:
- Set the dir variable to the current directory:
dir . # Where everything is kept- Edit your new copy of CA.sh
- Set the CATOP variable to the current directory:
CATOP=.- Optionally, set the length of time the certificate will be valid for to something other than 365 days:
DAYS="-days 3650"- Create the certificates:
cd newCA export PATH=$PATH/../../../openssl-0.9.6c/apps chmod 744 CA.sh CA.sh -newca ls -l total 8 -rw-r--r-- 1 root root 1306 May 21 07/27 cacert.pem -rw-r--r-- 1 root root 3 May 21 08/27 cacert.srl drwxr-sr-x 2 root root 1024 May 21 07/26 certs drwxr-sr-x 2 root root 1024 May 21 07/26 crl -rw-r--r-- 1 root root 0 May 21 07/26 index.txt drwxr-sr-x 2 root root 1024 May 21 07/26 newcerts drwxr-sr-x 2 root root 1024 May 21 07/26 private -rw-r--r-- 1 root root 3 May 21 07/26 serial- Optionally convert the server certificate from PEM encoding to DER:
openssl x509 -inform pem -outform der < cacert.pem > cacert.crt- Edit httpd.conf
- Point Apache SSL to the new certificate:
SSLCertificateFile /usr/local/apache/conf/newCA/cacert.pem- Point Apache SSL to the new certificate key:
SSLCertificateKeyFile /usr/local/apache/conf/newCA/private/cakey.pem- Stop apache, if it is running:
cd $APACHE_HOME/bin apachectl stop- Restart apache in SSL mode
apachectl startsslIf you choose to encrypt your server key, you will be prompted for the pass phrase
- Test Apache with both http and https protocols as above - once you successfully accept the new server certificate, view its details in your browser to ensure that it looks correct.
- Client certificates
To require client-side authorization, build and distribute a client certificate:
- Configure the client certificate:
cd /usr/local/apache/conf/newCA export PATH=$PATH/../../../openssl-0.9.6c/app openssl req -new -out clienta.csr -keyout clientakey.pemYou will be prompted for DN information about the user to whom you will be distributing the certificate.
- Make the certificate
openssl x509 -req \ -in clienta.csr \ -out clienta.pem \ -CA cacert.pem \ -CAkey private/cakey.pem \ -CAcreateserial \ -days 365 \ -outform PEMThe -CA option points to the location of your server certificate and -CAkey points to the location of your server key.
- Convert the certificate to a browser-friendly format:
openssl pkcs12 -export \ -in clienta.pem \ -out clienta.p12 \ -inkey clientakey.pem \ -name "Test User"- Distribute clienta.p12 (rename clienta.p12 to whatever.p12) to your test computer
- Install client certificate in your browser - for Netscape, do the following:
- Select "Security Info" under "Tool" under the "Communicator" menu
- In the "Yours" section in "Certificate", click the "Import a certificate" button
- Find the new certificate and click "Open" - the certificate should now show up in the list with the name you choose above.
- Click "Ok" to exit the Security Info dialog
- Edit httpd.conf
- Enable client certificate requirements:
SSLVerifyClient require SSLVerifyDepth 1 SSLCACertificatePath /usr/local/apache/conf/newCA SSLCACertificateFile /usr/local/apache/conf/newCA/cacert.pemSSLCACertificatePath points to the location of the server certificate you used to sign the client certificate.
- Stop apache, if it is running:
cd $APACHE_HOME/bin apachectl stop- Restart apache in SSL mode
apachectl startsslIf you choose to encrypt your server key, you will be prompted for the pass phrase
- Test Apache with both http and https protocols as above - once you successfully accept the new server certificate, you will be asked to choose the correct client certificate from a list. Make sure you select the one with the name you choose when you created it.
Secure Shell
The ssh command is a replacement for the insecure telnet command. In the following example, user1 on the client system is initiating an SSH connection to the www.yourdomain.com. The login name of user1 on the server is user2.
ssh reads $HOME/.ssh/config and the global configuration file /etc/ssh_config when it starts up. Yet again read the man page for details, most of it is pretty straight forward except for the TCP forwarding options -L and -R. This assumes that you can login to a remote host via ssh. If so then you can use ssh as a secure channel to access unencrypted remote network services such as ftp or pop (it's also a handy way of getting around firewalls). example/
ssh -L 12345/www.yourdomain.com/21 www.yourdomain.com
Will make an ssh connection to host www.yourdomain.com. If www.yourdomain.com has sshd running you will be presented with what appears to be a normal login session. Behind the scenes however ssh is listening to port 12345 on your local machine and any connections to that port will be forwarded over your ssh session, then an unencrypted session is initiated from the remote side of your ssh session to port 21 on www.yourdomain.com so that as far as the remote ftp server is concerned, somebody just ran a normal ftp session from www.yourdomain.com to itself. Ssh -R does the same thing only in reverse.
- Initiate the login/
ssh user2@www.yourdomain.com- The first time you log in you may get a message similar to:
[bea@bil security]$ ssh www.yourdomain.com
The authenticity of host 'www.yourdomain.com (192.168.4.199)' can't be established.
RSA key fingerprint is ab/6a/3d/e1/bf/65/82/35/46/82/cc/e9/10/d0/32/f1.
Are you sure you want to continue connecting (yes/no)? yes
Warning/ Permanently added 'www.yourdomain.com,192.168.4.199' (RSA) to the list of known hosts.
bea@www.yourdomain.com's password:The RSA key fingerprint is the public key found in the host's public key file located under /etc. Either ssh_host_key.pub or /etc/host_key.pub depending on the server configuration. If you continue to connect, this key will be added to your $HOME/.ssh/known_hosts file. The rationale behind this is that if somebody else ever masquerades as this host, the host key would be different to the entry in known_hosts and ssh will instantly notice and tell you so
- If passphrases have been defined as required in /etc/sshd_config, you will be prompted to enter your passphrase.
- With a correctly entered password and passphrase, the user is given a shell prompt. Of course, user2 must already have an account on the www.yourdomain.com machine for password authentication to work.
Last login/ Mon Apr 15 13/27/43 2001 from machine1
[user2@machine2 user2]$At this point, the user can interact with the shell in the same way as they might do with telnet or rsh, except that the communication is encrypted.
Digital Certificates/ Self-Signed
Default key pairs are created during the OpenSSH installation process. To generate key pairs ad hoc use ssl-keygen:
ssh-keygen -t rsa1 -f /etc/ssh/ssh_host_key -N "your passphrase"
>ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key -N "your passphrase"
ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key -N "your passphrase"$ ssh-keygen -t rsa -N "My passphrase" Generating public/private rsa key pair. Enter file in which to save the key (/export/home/map/.ssh/id_rsa): Your identification has been saved in /export/home/map/.ssh/id_rsa. Your public key has been saved in /export/home/map/.ssh/id_rsa.pub. The key fingerprint is: 02/34/22/30/6f/84/79/76/8c/e6/eb/f6/f2/5a/9e/10 map@www.yourdomain.comYour passphrase can be any length you want. It generates two files, $HOME/.ssh/identity and $HOME/.ssh/identity.pub. These are your default RSA identity keys (you can create different identities by running ssh-keygen -f identity_file then use them by running ssh -i identity_file host).
Appending identity.pub to $HOME/.ssh/authorized_keys of any account on any computer allows you the luxury of logging into that account with your RSA passphrase. It also has the added security that somebody must also possess your identity file before the passphrase would work. Another cool thing with authorized_keys is that you can prepend options to the start of a public key so that if somebody logs into an account with the corresponding passphrase and identity file, those options can do things like allow connections only from certain hosts, deny certain types of ssh forwardings, set environment variables or just execute certain commands. example/
from="localhost",command="echo potatoes" 1024 37 1508741801398651929640224012546 535610929088627123641067454302800019367830331042978392793032882068267356835208 5596452813266000213480475567422647179234364246663801261753180562216515773813903 5417432487556956228238884121546196774730626451213382495086778016310334685244396 958654066227875380523910928543591111215801 root@www.yourdomain.comthe above line in my $HOME/.ssh/authorized_keys will allow only people logging in from localhost to use that identity and it'll simply say potatoes and log you off. The root@www.yourdomain.com part is just a comment that ssh-keygen puts in, it doesn't do anything.
ssh-agent
ssh-agent is a daemon that stores a user's authentication keys and passphrase so that when that user runs ssh, ssh-agent automatically does the RSA authentication for that user saving him the bother of entering the password himself. What you do is run ssh-agent with an arbitrary command (usually a shell) as it's argument. Now command and all its' child ssh sessions can be automatically authenticated by ssh-agent, but ssh-agent authenticates nothing by default.
You need to run ssh-add file where file contains a private identity key such as those generated by ssh-keygen. $HOME/.ssh/identity is the default if no files are specified. You'll be asked to enter the passphrase for that private key. From now on, any ssh session that uses that identity will be automatically authenticated. You can add as many identities as you like, ssh-add -l lists the ones currently loaded in ssh-agent.
scp
scp is the ssh version of rcp which lets you copy a file to a remote host example/
scp $HOME/.ssh/identity plop@www.yourdomain.com/.ssh/identitywould copy my identity file to my account on host www.yourdomain.com
Secure FTP
Secure FTP (sftp) provides encrypted ftp connections between a client and a host. Secure ftp is one of the packages in the OpenSSH suite. For sftp connections to work, an An sshd daemon needs to be running on the target host. There are various ways to run the sftp client/
sftp domain_name
sftp username@domain_name
sftp -p port domain_nameOn the server, there is no need to start the sftp-server daemon as it is started when the sshd daemon is started.
To enable sftp connections from remote nodes on the internet, open a conduit in the firewall for ports 22 and 115.