Skip to main content
Welcome guest. | Register | Login | Post

OpenSSH with Public Key Cryptography Tutorial

Introduction

This tutorial is intended for people with at least basic Unix knowledge, such as mounting filesystems and copying files.

OpenSSH, an OpenBSD project, is an incredibly secure implementation of the SSH protocol, a way of logging into a remote machine. For users of outdated protocols such as RSH, rlogin, and Telnet, it's an updated, secure replacement. For those who have never used anything like it, SSH can become a very valuable tool.

SSH is usually used to access a remote machine's shell, although there are other uses, such as:

This is what happens when you use SSH with public key cryptography:

Formatting in this tutorial

Text in this font is a command. Don't copy the trailing period if there is one.

Replace italic text.

Text like this is text in a command to be replaced.


Instructions



  1. On a Unix(-like) OS (which may be different on the client & server), check to see if OpenSSH is already installed by running ssh. (If it spits out the usage it's installed, if it says command not fount it's not installed.) If it's not installed, with your distro's package manager, install OpenSSH. The package names for several distros are shown below. How to use your distro's package manager is beyond the scope of this tutorial.

Distro Client package Server package Fedora

openssh-clients openssh-server Gentoo openssh openssh

Debain stable (Sarge) ssh ssh

Debian unstable (Etch) openssh-client openssh-server Ubuntu stable (Dapper) openssh-client

openssh-server Arch openssh openssh





  • Make sure the following is there and uncommented (there's no # in front of them) in /etc/ssh/sshd_config on the server. This will require that anything trying to connect via SSH will have to use public key cryptography and can't send passwords over a network in cleartext.

    • PubkeyAuthentication yes

    • PasswordAuthentication no




  • On the client, ssh-keygen -t dsa to generate your public and private keys.



  • Change the permissions of ~/.ssh to 700, and its contents to 600 (chmod 700 ~/.ssh and chmod 600 ~/.ssh/*).




    • If you have physical access to the server and portable storage (such as a USB drive or CD):

      1. Copy your public key (where you saved your generated keys/id_dsa.pub) to portable storage.


      2. Bring the portable storage to the server and mount it as the user you will be remotely logging in as. Don't log out yet.

  • To make the server consider your private key acceptable for using SSH to log in as the user you're currently logged in as, cat portable storage mount point/id_dsa.pub>>~/.ssh/authorized_keys.


  • When you've distributed your public key to all the servers you'll be accessing with SSH, get rid of your public key on the portable storage with shred -u portable storage mount point/id_dsa.pub. If shred (part of GNU coreutils) isn't installed, rm will have to do (rm portable storage mount point/id_dsa.pub).




  • Otherwise, when you know no one is spying on your connection:

    1. Copy your public key (where you saved your generated keys/id_dsa.pub) to the server with an insecure method such as rcp.


    2. Login as the user you'll be remotely logging in as via SSH with something insecure like rcp. To make the server consider your private key acceptable for using SSH to log in as the user you're currently logged in as, cat where you copied id_dsa.pub to>>~/.ssh/authorized_keys.

  • When you've distributed your public key to all the servers you'll be accessing with SSH, get rid of copies of your public key where they don't need to be with shred -u where you put id_dsa.pub. If shred (part of GNU coreutils) isn't installed, rm will have to do (rm where you put id_dsa.pub).






  • Repeat 4 on the server.



  • Add either sshd:IP or domain of client (more secure, allows only the domain or IP you specify to log into the sever via SSH) or sshd:ALL (if you want to log into the server via SSH from anywhere (provided you have your private key); allows anyone that can connect to the server to try to log in to it via SSH) to /etc/hosts.allow. Otherwise no one would be able to use the sshd service on the server.


  • Open TCP port 22. How to do this varies depending on your firewall. For Fedora Core, RHEL, and derivatives, this can be done with system-config-securitylevel. For other GNU/Linux systems, echo '-A INPUT -p tcp -m tcp --dport 22 --syn -j ACCEPT'>>/etc/sysconfig/iptables and restart the iptables service. How to manage services varies depending on the distro. On some distros, you can use service service action. Others you have to do /etc/rc.d/service action. Some systems you have to do /etc/init.d/service action. There's also rc-update service action. The action is either start, stop, restart, condrestart, reload, status, fullstatus, graceful, help, or configtest.

  • If the server's behind a router and you want to access it from the Internet:


    1. Stop using DHCP and assign a static IP address to your server. You should probably use the GUI utility that came with your distro, such as system-config-network on Fedora Core, RHEL, and derivatives. See the Gentoo Handbook for instructions on doing this manually without a GUI.


  • Forward TCP port 22 to your server. If you have a typical, small, off-the-shelf router (like a Linksys/Cisco one), first find your router's IP address, which is probably 192.168.1.1 or 192.168.1.0. If neither of these work, run route (on the server) and the router's IP address will be the default gateway's IP address. Enter the IP address of your router into your web browser for a web based configuration.





  • (Re)start the sshd service.



  • Test the setup by running ssh user to login as on the server@IP or domain of the server.




    Note that when it asks for a passphrase, it's not contacting the sever, it's making sure you have permission to the private key stored on the client. This guards you from something like someone using SSH on your machine when you left and the screensaver hasn't turned on yet,



  • Answer "yes" when it asks you if you want to continue connecting. Once the host you're connecting to has been added to ~/.ssh/known_hosts, OpenSSH will warn you if its identity changes. If there is a good reason for it to change (like you generating a new key for a new server), go ahead and add the new key to your known_hosts. Otherwise, the host may have been cracked.




    Tip: If the username that you're logging in as on the server is the same as the one you're currently using on the client, you don't need to specify the user to log in as on the server.





  • If the test failed, ask for help on Nuxified.


  • History: Previous version made on October 12th, 2006.
    Copyright © October 13th, 2006 "a thing" <athing@athingis.boldlygoingnowhere.org>.
    Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation. A copy of the license may be found here.

    Comments

    Port number in step 8 is wrong...

     

    echo '-A INPUT -p tcp -m tcp --dport 80 --syn -j ACCEPT'>>/etc/sysconfig/iptables

    should be

    echo '-A INPUT -p tcp -m tcp --dport 22 --syn -j ACCEPT'>>/etc/sysconfig/iptables

    fixed it

    ^Done.

    Thanks for this a thing,

    Thanks for this a thing, very useful.

    Comment viewing options

    Select your preferred way to display the comments and click "Save settings" to activate your changes.