Secure Shell

[#sshproto]: Protocol details

SSH provides encryption capabilities. Using the protocol may refer to using a remote access shell prompt, supporting the protocol rather directly (like scp), or using SSH (TCP) port forwarding which allows tunnelled traffic to be encrypted (and authenticated).

SSH uses TCP. IANA's list of TCP and UDP ports identifies TCP port 22 is reserved for SSH. UDP tunneling through SSH (with netcat and mkfifo) provides some information (not yet confirmed by this site) about tunneling traffic to help support UDP-based communication.

Some programs may support using an “encryption key”. One format/style of an “encryption key” is often called an “SSH” encryption key. These keys are typically supported by programs use the SSH protocol. Many programs that use encryption may rely on encryption keys, and may support this SSH-style of encryption keys, even if the program doesn't use the SSH network communications protocol.

[#sshterm]: Implementations of SSH terminal clients

Upon using the remote connection, the SSH client will generally check if the server's key is recognized. If it is not, the SSH client will generally inform the user and have the user verify the key so that the key may be permanently saved. Many users of SSH clients have been known to ignore any importance of verifying a key, and a key reason for some of that apathy is probably that many users don't know how to easily check the key.

For details on how to handle this properly, see verifying an SSH key.

Multi-platform solutions

These include:

OpenSSH

Pleasantly, this is often built into modern distributions of Unix (or Unix-like) code. For Microsoft Windows, there are also some options for using OpenSSH, although, many users of Microsoft Windows do like some of the other options, so do check those out.

PuTTY

PuTTY (PuTTY (in Unix), PuTTY (Microsoft Windows version), and a notable third party release, CogWheel's “Customized PuTTY For Prettier TradeWarring”, which is mentioned in the section about code based on PuTTY).

SyncTERM

See: Syncterm.

FireSSH

FireSSH's main page states, “FireSSH is a free, cross-platform SSH terminal client for Mozilla Firefox and Google Chrome. Written entirely in Javascript!”

The page has a “Download FireSSH” button which refers people to Firefox Addons page for FireSSH, and has been referred to by Mozilla's list of featured add-ons. (See: Mozilla's featured add-ons (English).)

After installing this Add-On, Mozilla Firefox has an icon to start a FireSSH session. (This icon may be in the Add-on bar, which Mozilla has been known to move in different versions of Firefox. Also, the icon has shown up on a new menu option that shwos up on the Tools, “Web Developer” menu.) The program states, “SSH component is ported from Paramiko”, providing a hyperlink to Paramiko which is an SSH2 implementation made in Python. The Paramiko uses LGPL v2.1.

The program uses an “Account Manager” dialog box to make connections with. Once this window closes, there seems to be no way to bring it back up, except to use the FireSSH icon again (to make a new session). The program will try to detect the login prompt from the remote session, and pop up a dialog box. Skipping that dialog box is not an option: doing so will cause a login failure (and likely result in the server asking for a login again, which causes FireSSH to show the dialog box again).

Even if the interface is a bit clumbsy, perhaps this may be a way to make an SSH connection from a computer that doesn't permit stand-alone software to be installed. Then again, if such a computer is so locked down, then installing a Firefox add-on might not be an easy option either. And, if a person has such little control over a computer, perhaps it is not a computer that a person should be using to enter password information into. Despite these thoughts/concerns, the program is being mentioned as an option that might be useful in some way.

Using SSH in Unix
OpenSSH

For Unix, “Portable OpenSSH”, as it is named on its home page, is the most popular implementation. Portable SSH converts OpenSSH (for OpenBSD) to several other platforms by adding specialized code which OpenSSH's web page calls portability “goop”. The end result works well on many other platforms than just OpenBSD. Naturally, OpenBSD uses OpenSSH instead of “Portable OpenSSH”. (This term “Portable OpenSSH” has nothing to do with the concept of OpenSSH on PortableApps.com.)

To make a connection, a syntax like the following may be used.

ssh -p 22 -l username remotesys.example.com

The -p specifies that the next parameter is a TCP port. It is optional. If -p is not specified, then the TCP port might be specified by a configuration file that gets used. Otherwise, if nothing applicable is specified in a configuration file that gets used, the default is 22, so feel free to leave off the entire -p 22 if desired.

Similarly, the -l username is optional. The username specified refers to the username that will be used when the remote system asks for a username. By default, the OpenSSH client will use the current username from the local system, and will not ask what username to use. (If that username is incorrect, it may not be possible to log in.)

If a username will be getting specified on the command line, then the following syntax is also understood:

ssh -p 22 username@remotesys.example.com

Other parameters that may be commonly used include ones related to identity files, and port forwarding.

The webpage on OpenSSH.com related to OpenSSH Manual pages refers people to OpenBSD's man page for the OpenSSH client. That would be the most official end-user documentation available online.

[#puttyunx]: PuTTY (in Unix)

Well known as being an option for Microsoft Windows (32-bit versions, and newer versions), PuTTY is also available for Unix.

See: the Multi-platform PuTTY notes for information that applies to both PuTTY for Unix and PuTTY for Microsoft Windows.

Remmina

For GTK+ users on some platforms, Remmina may be an option. (Since it supports multiple protocols and the web pages for this software mention RDP first in the list of supported protocols, the section on Remmina is in the RDP section.)

Using SSH in Windows
[#mswsshcf]: Microsoft's release of OpenSSH Client (as a “Feature”)
Compatibility

Compatibility with many existing/older SSH systems will be severely limited by these factors:

Key Exchange Algoritms

Note: At the time of this writing, compatability may be fairly limited by the list of supported algorithms. OpenSSH.com: Legacy Options notes some uses of the -Q option. Sample output:

C:\> %windir%\System32\OpenSSH\ssh.exe -q kex
curve25519-sha256
curve25519-sha256@libssh.org

C:\>

Hmm, that isn't a whole lot of variety. Trying to connect with a server supporting some older algorithms might show results that look something like this:

Unable to negotiate with 192.0.2.123 port 22: no matching key exchange method found. Their offer: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
Key type limits

GitHub: Win32-OpenSSH: issue 973 noted on December 4, 2017 that the available “version currently supports one key type (ed25519).” ... “Also,” ... “there is an issue with passphrase protected private keys. As a work around, create passphrase-less private keys” (which may be less of an issue for people using the SSH Agent software).

December 15, 2017's PowerShell Team blog: Using OpenSSH Beta in Windows 10 Fall Creaters Update and Windows Server 1709 also documents this restriction a bit, in a section where the page discusses using the SSH server. The page states, &dlquo;Note: currently only the built-in ED25519 authentication key type is supported. In the future, we plan to add support for LibreSSL which will enable additional authentication key types.”

Installation

Based on PowerShell Team blog: Using OpenSSH Beta in Windows 10 Fall Creaters Update and Windows Server 1709, there are a couple of ways to install this from the command line.

Using DISM

(The /Online switch does not refer to any sort of network communication, but refers to interacting with the “Online” installation of Microsoft Windows, which is the installation of Microsoft Windows that booted up.)

DISM /Online /Get-Capabilities | findstr OpenSSH.Client

Expected result:

Capability Identity : OpenSSH.Client~~~~0.0.1.0

So then run this:

echo %TIME%
DISM /Online /Add-Capability /CapabilityName:OpenSSH.Client~~~~0.0.1.0
via PowerShell
C:\> Get-WindowsCapability -Online | ? Name -like 'OpenSSH.C*'


Name : OpenSSH.Client~~~~0.0.1.0 State : NotPresent


C:\> Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0
Graphically

Can access by: Start button, Settings, Apps. This brings you to a page labelled “Apps & features” page, which has an identically-named sub-section (titled “Apps & features”, on the page with the same name). In that section, click “Manage optional features”. Above a list of some features is an “Add a feature” button. Use that button to have more features show up.

Then, you can finally run the command:

%windir%\System32\OpenSSH\ssh.exe
[#puttywin]: PuTTY (Microsoft Windows version)

For Microsoft Windows, PuTTY had gained early popularity and is likely the most popular client (if considering not only widespread use, but also people enjoying using it instead of alternatives). The PuTTY License is “the MIT license, which is similar in effect to the BSD license.” (This is a great license.)

(The “latest release version” for Microsoft Windows on x86 and compatible platforms is at “latest release version” of PuTTY (as it is referred to on the download page) is one of multiple files available from PuTTY's download page.)

A variation, PuTTY Portable, has been released by PortableApps.com to allow PuTTY to be used “without leaving any personal information behind.” (That means that the PuTTY software doesn't intentionally leave behind any personal information. However, this does not mean that the software guarantees there is no information left behind: a system with a keystroke logger could still be storing personal information which is captured. To work around that, see the section on one-time passwords.)

Using the PuTTY command line

PuTTY uses a capital -P command line parameter to specify that the next command line argument is a TCP port used by the remote host. This is similar to pscp but not the OpenSSH client which uses a lowercase p.

PuTTY documentation: Chapter 3: section on using the command line describes other command line arguments. Unlike pscp, PuTTY does NOT support /?. See the Multi-platform PuTTY notes about other available documentation.

Using the PuTTY GUI

If PuTTY is run without parameters, its default graphical interface will show. If this interface will be used for some time, then the recommended order of operatins is: fill in the host name, make sure the connection type is right (because it will override the port, even if the port was already manually changed), then assign a name for the “Saved Sessions” settings, then click the Save button to save those settings, and then click Open. Also, plan to handle keys. (See manually verifying key fingerprints.)

[#puttyplt]: Multi-platform PuTTY notes

These notes probably apply to PuTTY for Unix as well as PuTTY for Microsoft Windows. Additionally, some notes about PuTTY for Microsoft Windows might actually apply to the version Unix as well.

Documentation is available in other formats, referenced by the online PuTTY Documentation Page.

Christopher J. Madsen's VBinDiff: PuTTY notes mentions some terminal emulation issues/bugs, and a file to help deal with these issues.

[#othrputy]: Variations

PuTTY code is open source, and the source code allows code to be used in other products.

The PuTTY page with the PuTTY Wish List (and Known Bugs) contains a “Non-wish list”, mentioning features that the authors do not intend to put into PuTTY. At least one of those is transparency, and the way that the PuTTY team handled this request is a nice example. This an option that the authors do not intend to place into PuTTY's main code, primarily out of concern of not making the code too cumbersome with features that they feel are generally unnecessary. However, the authors are not opposed to point people to alternative software products that do provide this feature, such as modifications that other people have made to PuTTY's code. Specific options are mentioned on the web page describing wish for PuTTY transparency, but they also refer to PuTTY links page which refers to many other pieces of software that include PuTTY's code.

Customized PuTTY for Prettier TradeWarring

One (piece of software that includes PuTTY's code) that was found by the author of this text was CogWheel's “Customized PuTTY For Prettier TradeWarring”. The author of this release made some small modifications that can cause this customized version of PuTTY to render ANSI escape sequences in a way that works better with some older (closed source) software. The author of this text reviewed some of the source code for CogWheel's “Customized PuTTY For Prettier TradeWarring and it looks like the code changes were pretty small. It would be nice to see these changes merged into the main PuTTY code base, but until that happens, CogWheel's “Customized PuTTY For Prettier TradeWarring” (zipped). Or, as an alternative, there is CogWheel's “Customized PuTTY For Prettier TradeWarring” (larger installation package) which includes a font named “Bitstream Vera Sans Mono”, and some other modifications (like being pre-configured to connect to the author's server which runs a copy of the game called TradeWars 2002).

This particular release of the software is based on an older version of PuTTY which does not provide as nice of support for specifying IPv6 addresses. It would be nice to have a newer version of PuTTY that had these ANSI enhancements. PuTTY wishlist: “Better compatibility with DOS's ANSI.SYS mentions an available patch, but that is from over a decade ago. TOOGAM reached out to the PuTTY team on Sun, March 19, 2017 9:54 am (PST), providing them with details on how to easily implement the changes from “Customized PuTTY for Prettier TradeWarring”, but received no response.

[#syncterm]: SyncTERM

SyncTERM's home page, Wayback Machine @ Archive.org copy of SyncTERM home page

The software uses GPLv2.

This software does provide an experience reminiscent of connecting to old BBS software. The support for ANSI may be superior, with even ANSI music being supported. It also supports full-screen mode, even on the newer versions of Microsoft Windows (Vista and newer). For those looking to re-live the days of connecting to a BBS, this is definitely a contender to consider. (Another option, for those who may simply be looking for correct ANSI visual rendering, could be CogWheel's “Customized PuTTY For Prettier TradeWarring”, mentioned in the PuTTY alternatives section.).

OpenSSH
OpenSSH with Cygwin

There is also sshwindows.sf.net: OpenSSH for Windows which uses Cygwin, and “Portable OpenSSH” which lists Cygwin as a target.

OpenSSH with MSYS

OpenSSH at MSYS requires some libraries which are obtainable from various parts of the MSYS site. Further details should be (and actually are likely to be) provided/referenced soon.

Tera Term
In addition to other clients, OpenSSH.com's page of alternatives for Windows references TTSSH(2) (UTF-8 TeraTerm Pro with TTSSH2 SSH2 client and TTSSH, an SSH 1.5 client implemented as a DLL for Tera Term Pro.

If additional good/popular free alternatives are made available, they will probably become listed on OpenSSH.com's page listing SSH software for Windows. (Not all the software on that page is primarily meant to be terminal software: at least a couple of options are file transfer programs.)

Running an SSH server

Naturally, the software will need to be installed. Some operating systems may come with the software installed. In Unix, try running “ which sshd ”. If the file is found, then it may not require installation. If it does need to be installed, see software installation page.

Naturally, be aware of some of the SSH protocol details before implementing the software.

[#runosshd]: Running an OpenSSH server

(This section is largely about running the OpenSSH server in Unix. Users of Microsoft Windows operating systems may also want to check out SSH server software in Microsoft Windows.)

Identify the location of the configuration file that sshd uses. This guide is going to refer to that configuration file by its default location, which is /etc/ssh/sshd_config. (Some operating system implementations may default to having this configuration file stored in another location. For example, it may be in ??? (Check CentOS maybe?).)

To quickly see what configuration options are already in the text file, use:

grep -v \# /etc/ssh/sshd_config | grep -v \^\$

(The above command is meant for use with the Bourne shell, sh, or compatible shells. Namely all backslashes are simply escape characters. The ^$ sequence refers to the start of a line followed by the end of the line, and removed blank lines.)

Back up the current OpenSSH configuration file before changing it. (This may mean backing up “/etc/ssh/sshd_config”.)

[#oshchcfg]: Changing the OpenSSH configuration
The standard advice

Naturally, a recommended step before altering a configuration file is to backup the file. e.g.: “ cpytobak /etc/ssh/sshd_config ” if using OpenSSH and the cpytobak program. However, if using “Portable OpenSSH” (basically OpenSSH for any operating system other than OpenBSD), the configuration file's location may be a bit different. Customize as needed.

Changing some basic OpenSSH server configuration options

Then, if the EDITOR value is set, one may use $EDITOR /etc/ssh/sshd_config. Otherwise, use whatever other text editor is desired, or simply use the echo commands that follow.

Here are some options for OpenSSH. (The examples here use echo commands. Naturally these shouldn't be run until the current configuration file has been backed up. (These instructions should elaborate on doing that.))

echo PermitRootLogin no | sudo -n tee -a /etc/ssh/sshd_config
echo LoginGraceTime 4m | sudo -n tee -a /etc/ssh/sshd_config
echo Port 22 | sudo -n tee -a /etc/ssh/sshd_config

Note: before having the “PermitRootLogin no” option take effect, it is probably desirable to ensure that another account is able to log in remotely (adding a user as necessary, and making sure that user has any necessary permissions to log in locally), and that such a user (who can log in) can also obtain elevate privileges. If the “root” account is currently being used, it is likely worthwhile to create another remote session to make sure that works.

The Port 22 line sets the port to its default value: there's no harm nor good reason to use this line unless the TCP port number is being customized to a value other than 22.

[#oshalwgp]: Restricting which operating system groups may log into the OpenSSH server

Back up the configuration file, and then after doing so, run:

echo AllowGroups _okssh | sudo -n tee -a /etc/ssh/sshd_config

(A previous version of these instructions used a sample group name of “sshok”. These revised instructions show a new example name of “_okssh”. One of the ideas behind this change is for groups (and usernames) to start with an underscore when they are custom groups made by administrators. The idea is mainly meant for usernames, and the goal is to help keep the special user accounts, used by administrators, easily recognized and separated from the standard user accounts that are actively used by standard users. The same concept is being applied to group names. Also, starting the account with “_ok” is meant to indicate this is a group related to providing permissions. (The group's name may look fairly similar to the names of other groups that that both have a similar purpose, and which are also given similar names, such as a group named “_okvpn” which lists users authorized to use a VPN.)

[#ptnsshgp]: Putting end users into a group allowed by the SSH server

Now that this configuration file has been altered to ensure that only authorized users can use SSH to get into the machine, be sure to authorize some end users! Add the relevant user(s) to the group named “sshok” (which is a group that may or may not yet exist). The group must be the group mentioned in the AllowGroups line in the sshd_config file. The example details just provided show the name of that group to be “sshok”.

Like any other changes to the OpenSSH configuration file, be sure to reload the OpenSSH configuration file so that the changes to OpenSSH take effect. (Then it might be a good idea to check whether existing connections are authorized. If not, intervene before considering this task finished.)

Then, be sure that to re-load the OpenSSH configuration file.

[#oshcfgld]: Reloading the OpenSSH configuration file

Once the configuration file is updated, make sure that the changes take effect. Perform this in one of two ways: sending a SIGHUP signal, or restarting the sshd OpenSSH server.

First, see if there is a PID file located at /var/run/sshd.pid. If /var/run/sshd.pid exists and if there is only one copy of the sshd (OpenSSH server) software running, then the fastest way (which likely uses the least system resources, and so may be the quickest way) is to run:

sudo kill -HUP $( cat /var/run/sshd.pid )

(If the sudo command is not working, perhaps because it is not installed, then either get it working or just leave off the word sudo. Using the word sudo is generally unnecessary when logged in as root.)

If the file does not exist, or if multiple copies of the sshd (OpenSSH server) software may be running, then a different step needs to be taken. Each copy of the server needs to re-load the configuraiton file by either having a SIGHUP sent to the copy of the server, or by restarting the server.

If using an operating system that implements a framework/interface for “services”, perhaps the software may be restarted by using that framework. (This method may be simpler than finding a PID manually, although may also be more dependent on a specific operating system implementation. If there is just one copy of the sshd (OpenSSH server) software may be then this method is probably not substantially easier than referencing the PID by filename.) (Whether or not this method handles multiple PIDs might depend on the specific implementation, so perform whatever research is needed before proceeding with the method of using a ervices framework/interface that is provided by the operating environment/system.)

If none of the above options were taken, then find the PIDs for every running copy of sshd.

  1. Find any copies of sshd that are running with:

    ps -auxww | grep sshd
  2. Then use sudo kill -HUP pidNumber for each PID listed (which is the fast way) or restart all copies of sshd (which is slower, and perhaps runs some risk of breaking connections).

Instead of sending a SIGHUP, the sshd (OpenSSH server) may restarted. This is probably more resource intensive (e.g. slower) than SIGHUP, but it also works. Therefore, if the sshd (OpenSSH server) software is restarted anyway for some reason, there is no need to SIGHUP it.) As a more extreme example, rebooting the entire computer that is running the sshd (OpenSSH server) will also do the trick to get the configuration file re-loaded (after the sshd OpenSSH server software is started up again). Naturally, after stopping any existing sshd processes, start a new copy of sshd if that is desired.

SSH server options in Unix
The most popular solution is likely running an OpenSSH server. OpenSSH.org's Unix Alternatives (to OpenSSH) provide other options.
[#sshsvmsw]: Running an SSH server in Windows

For now, this section is simply a brief blurb of some software options, and doesn't go into a full installation guide (handling considerations such as Windows Firewall).

Microsoft's endorses release

Microsoft has released some code. GitHub: Win32-OpenSSH has linked to what the page called the “First release announcement”, which was MSDN Blog: OpenSSH for Windows. That blog entry credits NoMachine's work (see: NoMachine OSS Ports). WinSCP.net documentation: guide for OpenSSH in Microsoft Windows

MLS-Software's OpenSSH server looks rather promising.

Chuan Ji's report: MSYS and SSH server under Windows 7 (from March 14, 2011) reports some dismal findings of many software packages simply not working well. He ultimately seemed most satisfied with bitvise's WinSSHD, a commercial package (which, at the time of this writing, was $99.95 for commercial usage).

His arguement against MobaSSH was involvement of CygWin, which he was looking to avoid. People who don't mind CygWin involvement might find that workable. (MobaSSH license indicates it is freeware with some minimal restrictions, but also has references to GPL. There is also a professional version.) MobaSSH is free for home use.

Running an OpenSSH server may be an option, possibly by using OpenSSH for Windows which uses “the Cygwin package without needing the full Cygwin installation”. However, as of October 2016, it seems the latest release was from 2004. Since then, Windows Vista was released in 2007. Chuan Ji's report: MSYS and SSH server under Windows 7 (from March 14, 2011) seems to indicate that this doesn't work in Windows 7.

ITeF!x's copSSH is another distribution. CopSSH Free Edition “is limited to one local user and one concurrent connection.” For people seeking more, Itefix's announcement of paid solutions says, “Itefix has decided to deliver installers” for CopSSH and some other software “as paid solutions”.

Kpym Telnet/SSH Server is BSD licensed. The Kpym Telnet/SSH Server: Registration page notes the software is free, though encourages paid registration and notes “The registered version does not display the connection nag screen.” The project's main web page does mention support for full color console applications. (Speculation: This feature might require some specific support for such a feature, and so may be a feature that isn't found in many alternatives. This feature also may be limited to operating systems which are older than Vista, since Windows Vista and newer systems may not support full screen text mode consoles even locally.)

There is a piece of software called FreeSSHD, although a discussion of FreeSSHD's license shows the obtainable source code is not freely available. (Therefore, this program is not exactly “open source” even if it does fit the general description of freeware.) How to install an SSH Server in Windows Server 2008 says “installation for Free SSHd is so simple as compared to others”. It does use a graphical interface for configuring the server.

Some other choices (which might be freeor not: this hasn't yet been fully researched for this documentation) may include: Sysax Multi-Server (SSH Server) for Windows has multiple editions, including one which is free (but not licensed for commercial use).

Glasgow Haskell Compiler Wiki: “Setting up the SSH” server.

Gist: samhocevar claims to be “a cleaned up and improved version of” the process shown on the Glaskell Compiler Wiki (which was just mentioned with a hyperlink).

Perhaps see also: Wikipedia's Comparison of SSH servers.

[#ciossshd]: Running an SSH server for Cisco IOS

First, since these directions are rather specific to Cisco IOS, there is the standard warning about directions related to Cisco IOS. (Don't waste your time trying to apply these directions if professional-grade Cisco equipment is not being involved.)

Keygen

First, generate the key. This is documented elsewhere, see: guide to making keys in IOS. (That information is being documented in a section that is not specific to starting the SSH server, because the key can also be used for an entirely unrelated purpose: starting an HTTPS server.)

Create user to authenticate with

The SSH will want to authenticate a username. Enable that. To use the user(s) defined in the running configuration (local user database), which is probably the easy way, start by making a user in Cisco IOS.

Optional step: using AAA

If you wish to use the new AAA model, then enable that and create a method list. (That is really not necessary, but it is an approach that may be used with some advanced techniques.)

config terminal
aaa new model
aaa authentication login customMethodListName local

Why you would want to do this is largely off the topic of simply starting the SSH server, but will, someday (probably soon, since documentation has been mostly written/prepared-- maybe even already, if this documentation didn't get subsequently updated), probably be discussed at: Cisco “CCNA Security” information. For those who are not familiar with AAA, here's a quick summary. There's no substantial harm in using the AAA approach described here, as long as the equipment supports it. The most noteworthy drawback is just that it may be slightly more typing to set up, compared to the simpler approach of following the steps that this section describes about how to enable SSH without using AAA. The big advantage to AAA is largely an easier way to provide more flexibility, using methods like remote authentication servers. If those aren't being used, or AAA seems unattractive for whatever reason, then simply don't use it. Switching to AAA later is not terribly difficult (for people who understand Cisco's AAA implementation; especially if there is readily available good documentation showing the commands).

Enabling SSH

Then, with the key generated, presumably one wishes to have this apply to the virtual terminal lines. An example of this:

enable
conf terminal
ip ssh version 2
line vty 0 4
transport input ssh

There is one other key component to really allow SSH to work. First, let's dig into some details of what's already been shown. The example above can be used. However, there are several items to note.

ip ssh version 2
%SSH 5 ENABLED: SSH 1.99 has been enabled

If you see a reference to SSH version 1.99, that is actually a reference to supporting both version 2 and version 1. This follows the guidelines of RFC 4253 (SSH) section 5.1 (“Compatibility With Old SSH Versions” sub-section involving newer servers and older clients)

Specifying protocol on a line

The example above enables SSH and disables telnet. If telnet is also desirable, then, instead, use:

transport input ssh telnet

To disable both SSH and Telnet:

transport input none

The other possibility also disables SSH, but permits Telnet.

Specifying which lines

Note: that the above example only affects VTY lines 0 through 4. Some devices may support more VTY lines, and so those lines should presumably also have telnet disabled.

Different devices support different levels of lines. Unfortunately, there doesn't seem to be a max word that IOS recognizes so that one configuration could support different types of devices that may have different lines.

To see how many VTY lines a device supports, use:

enable
conf terminal
line vty 0 ?

(or, instead of pressing the ? key there, press the tab key a time or two?)

Note that the number of VTY lines may not match the maximum number of simultaneous SSH sessions. Cisco documentation: Accessing the CLI through a Console Connection or through Telnet mentions SSH as well as the console and Telnet. It states that a device (which seems to be referring specifically to a switch) “supports up to five simultaneous secure SSH sessions.” The same web page, presumably about the same device, states, “supports up to 16 simultaneous Telnet sessions.” This seems to indicate that a device may be limited to supporting fewer SSH sessions than VTY lines. Presumably, these limits were probably placed due to concerns from when old devices had CPUs which were not powerful enough to support lots of SSH sessions.

More SSH-related options

Here are a couple of additional options that may exist...

ip ssh time-out 60
ip ssh authentication-retries 2
Specifying auth

Then, go to the VTY configuration. This is done just like the step where the transport mode was specified:

config terminal
interface vty 0 4

Like what is discussed in step 2, this probably should be customized based on how many VTY lines is supported. Also, the most convenient time to do this step is probably at the same time as when defining what transport mode is being used.

Finally, specify how incoming connections will be authenticated. The easy way, which is what should probably be done if AAA is not being used, is to use:

login authentication local

Alternatively, if an AAA method list was created, that can be specified instead. That approach can provide the additional flexibility of authentication options that are supported by AAA. To do that:

login authentication customMethodListName

After each of those steps is performed, then SSH oughtta be working. Try it out! The router may be able to simply connect to its own IP address.

ssh l loginName 192.0.2.100

The device can report some information about active SSH sessions. (Presumably only really useful after the SSH server is started.) To do this:

show ssh
! or, another command that may be useful...
who

There may be some differences between using SSH and using the console cable. For example, a device may usually send log messages to the console cable, but not VTY lines. If there will be a lot of messages, the ideal way to handle this may be a fairly detailed process described by preparing for Cisco IOS debugging. Another, simpler option may be to simply run “terminal monitor”.

Handling keys

Key should be verified in order to prevent undetected “man in the middle”-style attacks. (More information may be available at: authorization key files.)

[#sshkysig]: Manually verifying/validating key signature fingerprints

Be warned that there was an old vulnerability due to a bad implementation: authorization key files: problems with SSL keys using an old Debian library. (This is not a problem with newly-created keys that don't use that old software. It could be an issue with even recently-created keys if they were made with the old software.)

[#sshsvfng]: Determining the key/fingerprint
Determining the key with OpenSSH

On the server that is has OpenSSH installed, use:

ssh-keygen -lvf /etc/ssh/ssh_host_rsa_key.pub

That path (/etc/ssh/ssh_host_rsa_key.pub) is for OpenBSD, which is made by the creators of OpenSSH. Other operating systems that use “OpenSSH Portable” may store the file in a different path. The v parameter causes the “hash visualization”/“SSH Fingerprint ASCII Visualisation”/“VisualHostKey”. This drawing is meant to aid security by allowing software to display something that will be more memorable for some people than hexadecimal numbers. (The art function was introduced as one of the new features of OpenSSH version 5.1, though that version said, “Fingerprint visualisation in is currently disabled by default, as the algorithm used to generate the random art is still subject to change.” For more details about the art: change in art.)

Using PuTTY software
The PuTTYGen.exe (which is separate from PuTTY.exe, but is by the same author) can show the fingerprint of a private key file.
Seeing keys/fingerprints in SSH client software
[#nossshky]: When there's no saved SSH key

If an SSH client does not have a saved key for a server's IP address and port number, most/all responsible popular SSH clients (including OpenSSH and PuTTY) will point this out when an initial connection is made to that server. The software will then show the a signature based on the public key that has been received by the server. This signature is a set of sixteen pairs of hexadecimal digits (representing 128 bits). Then, with that signature displayed, the common response of such an SSH client is to proceed to ask the user to verify if the that signature matches a known accurate, good signature that is based on on a key that is known to be good and valid. This behavior has become common enough that now a wide-spread standard expectation is that SSH client software will protect users by performing this sort of check and response.

The person using the SSH client should determine the SSH key/fingerprint of the SSH server and verify that the server's SSH key is matching what the client is showing.

If a key mismatches, the client may point this out as described in the section about dealing with a(n unauthorized) key change.

Following sections show where keys are commonly stored so that the keys may be accessed (both by the SSH client software, and for any other purpose).

Keys stored by SSH/SCP terminal clients
OpenSSH client
For each user, see ~username/.ssh/known_hosts and look for the system IP address (or system name?).
PuTTY
Inside HKEY_CURRENT_USER (a.k.a. HKCU), PuTTY will store keys in “\Software\SimonTatham\PuTTY\SshHostKeys”. See viewing the Windows registry.
Tera Term Pro
A web page, Free SSH for Win9x/NT/+, indicates this may be in a folder called “C:\Program Files\ttermpro\ssh_known_hosts\.”
WinSCP
Inside HKEY_CURRENT_USER (a.k.a. HKCU), WinSCP will store keys in “\Software\Martin Prikryl\WinSCP 2\SshHostKeys”. (This hasn't been tested/verified, but rather is currently based on a web page, Free SSH for Win9x/NT/+.) See viewing the Windows registry.
Agents

(Information on viewing keys stored in agents should go in this section. Using agents would more appropriately go in the user authentication: key files section.)

Specifying what key type to use

There is likely little need to do this, but if there is a desire to have a client use a specific type of key to verify, then that may be requested.

For the OpenSSH client, this involves using -o HostKeyAlgorithms ssh-rsa,ssh-dss (to use the old default, from before the default started including ECDSA and certs @openssh.com).

When SSH software is asking for verification of a fingerprint signature, the software will also be showing the fingerprint signature which is the set of sixteen pairs of hexadecimal digits (that represents 128 bits). An end user should then compare that the displayed signature shown by the SSH client matches a known, accurate, good, valid, authentic signature/fingerprint that was properly created using the proper key that is on the server. The key should only be accepted (by an end user) in SSH client software after the key has been fully verified. (Generally the SSH software will save a key if it is accepted, so this doesn't need to be done frequently when the end user is frequently connecting to the same system from the same client.)

[#chdsshky]: Dealing with a(n unauthorized) key change

An OpenSSH client may show something like this:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!Someone could be eavesdropping on you right now (man-in-the-middle attack)!It is also possible that the RSA host key has just been changed.The fingerprint for the RSA key sent by the remote host is01:23:45:67:89:ab:cd:ef:fe:dc:ba:98:76:54:01:23.Please contact your system administrator.Add correct host key in /root/.ssh/known_hosts to get rid of this message.Offending key in /root/.ssh/known_hosts:10RSA host key for [127.0.0.1]:12345 has changed and you have requested strict checking.Host key verification failed.

(In the above example, the long string of 16 hexadecimal numbers represents is an SSH key signature representing 128 bits. The 12345 represents a TCP port number. The :10 refers to a line number of a text file. The references to /root likely refer to the home directory of the current user ( $HOME a.k.a. ~)

PuTTY may show a similar message. (A screenshot here would be nice.)

If this is seen, be careful. There are some legitimate reasons for this. However, there is also the clear possibility that this reflects an attack where a key was changed. There is only one proper response: An attempt should definitely be made to determine why the keys do not match. This may be the result of a compromised key file (such as a hacked server where a replacement, less trustworthy key is now being used) or a man-in-the-middle attack (where a malicious server may be pretending to be another server which is authentic). If a key has been altered, seek to determine when, by whom, and how that was done. As this could be the results of an attack, this should not be casually ignored before steps are taken to be properly dealing with the situation.

If it is known there was an authorized key change...

If a trusted system administrator can recall replacing the key (or deleting the old key), any previous saved key that the client has is probably useless and will be likely to cause additional troubles (like generating error messages and/or possibly refusing a connection). In that case, the client needs to remove the information which is causing troubles. Have the client lose information about the old key that is no longer being used. The locations are documented in the section called when there's no saved SSH key.

Generally, a system administrator should probably not be replacing an SSH server's private key until there is a plan on how to replace the public keys used by clients. (It is assumed that the key replacement is not generally being done to replace compromised keys, because keys should not generally be getting compromised.) Hopefully the key replacement plan will result in the key being replaced on a client before the client finds cause to be displaying this sort of error message.

If the cause of the key change is not known and authorized

Use the safest of all possible methods to log into the system, which may be to access the machine locally. As the system may be compromised, perhaps by having a keystroke logger installed, consider all information typed into the system to be compromised. That includes credentials. That said, logging in will probably be needed, so simply anticipate that all credentials used before the time of fixing the problem are possibly compromised, and plan to change all such credentials as needed.

Once logged in, check the key. Find the key file, and see when it was last modified and what the ownership and permissions are. See what the local system reports as the key.

Since file timestamps may have been tampered with, don't necessarily trust the information if the file appears to have not been modified for months or years. However, if the key file does say that it was changed several hours or days ago, that might indicate the time that the attack occurred.

Replacing the server's key is not always the right move. There is also the possibility that the server's key never was changed. Perhaps the client had an incorrect key installed, possibly because the client had incorrectly communicated with a rogue and malicious server before. If that malicious server is no longer around, the client will get a different key when communicating with the proper server, and will report the key problem. In this case, the server does not need any sort of repair, and altering the key may serve no purpose other than causing inconvenience for other clients.

If any key, whether on the server or on a client, is found to not be a trusted, useful key, then it may be useful to save a copy of that key before summarily overwriting it. However, the key is probably not going to be useful long term, so after backing up the data, the key will need to be replaced with something useful. However, resolving the issue satisfactorily involves more than just getting the right keys in place. Ideally all vulnerabilities will be identified and sealed to make sure this doesn't happen again.

If a key was tampered with, after things are cleaned up, it may be worth the effort to start using a new key. This will also require replacing all of the public keys. In the case of this being a private key on an SSH client, fully replacing the public key means replacing each copy of the public key on any server that was using the corresponding public key. Otherwise, whoever has access to the old private key may have access to those servers. In the case of replacing a private key used by a server, such an action will require that all clients remove the old key (because otherwise the clients will typically get warning messages and may refuse to connect).

In theory one way around the inconveniences related to a tampered key is to get the old key file, perhaps by restoring the file from backup, and putting that back into place. However, the problem with that theory, if an attacker got into the system, is that whoever changed the key probably had an ability to obtain the old key file. Once data has been shared with an unknown source, it may be impossible to determine how many copies of that key have been made and distributed to potential (or, even worse, actual) attackers. If a copy of the key was transmitted to another computer off the network, there may be no indicator on the network that really shows what might be happening with the copy of the key which is no longer on the network.

Creating and using key files
See user authentication: key files for some information (which does refer back to this page).