- [#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
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 (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).
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
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.
-pspecifies that the next parameter is a TCP port. It is optional. If
-pis 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
-lis 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:
- [#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.
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 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
-Qoption. Sample output:
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
: 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.”
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.
/Onlineswitch 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.)
Capability Identity : OpenSSH.Client~~~~0.0.1.0
So then run this:
DISM/Online /Add-Capability /CapabilityName:OpenSSH.Client~~~~0.0.1.0
- via PowerShell
|? Name -like
Name : OpenSSH.Client~~~~0.0.1.0 State : NotPresent
Add-WindowsCapability-Online -Name OpenSSH.Client~~~~0.0.1.0
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:
- [#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
uses a capital
-Pcommand line parameter to specify that the next command line argument is a TCP port used by the remote host. This is similar to
but not the OpenSSH client which uses a lowercase
PuTTY documentation: Chapter 3: section on using the command line describes other command line arguments. Unlike
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
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 with Cygwin
- 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 “
”. 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
uses. This guide is going to refer to that configuration file by its default location, which is
. (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:
(The above command is meant for use with the Bourne shell,
, 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 “
- [#oshchcfg]: Changing the OpenSSH configuration
- The standard advice
Naturally, a recommended step before altering a configuration file is to backup the file. e.g.: “
” if using OpenSSH and the
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
EDITORvalue is set, one may use
. Otherwise, use whatever other text editor is desired, or simply use the
commands that follow.
Here are some options for OpenSSH. (The examples here use
echocommands. Naturally these shouldn't be run until the current configuration file has been backed up. (These instructions should elaborate on doing that.))
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.
Portline 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
- [#oshalwgp]: Restricting which operating system groups may log into the OpenSSH server
Back up the configuration file, and then after doing so, run:
(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
AllowGroupsline in the
sshd_configfile. The example details just provided show the name of that group to be “
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
First, see if there is a PID file located at
exists and if there is only one copy of the
(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:
sudocommand is not working, perhaps because it is not installed, then either get it working or just leave off the word
sudo. Using the word
sudois generally unnecessary when logged in as root.)
If the file does not exist, or if multiple copies of the
(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
Find any copies of
that are running with:
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
(OpenSSH server) may restarted. This is probably more resource intensive (e.g. slower) than SIGHUP, but it also works. Therefore, if the
(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
(OpenSSH server) will also do the trick to get the configuration file re-loaded (after the
OpenSSH server software is started up again). Naturally, after stopping any existing
processes, start a new copy of
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).
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.)
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.)
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:
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.
SSH1.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:
To disable both SSH and Telnet:
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
maxword 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:
(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...
- Specifying auth
Then, go to the VTY configuration. This is done just like the step where the transport mode was specified:
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:
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:
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.
The device can report some information about active SSH sessions. (Presumably only really useful after the SSH server is started.) To do this:
or, another command that may be useful...
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 “
- 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:
That path (
) 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
vparameter 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
(which is separate from
, 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
~/.ssh/known_hosts and look for the system IP address (or system name?).
HKEY_CURRENT_USER (a.k.a. HKCU),
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\.”
- 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.
(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
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the
RSAhost key has just been changed.
The fingerprint for the
RSAkey sent by the remote host is
Please contact your system administrator.
Add correct host key in
to get rid of this message.
Offending key in
RSAhost key for [
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
12345represents a TCP port number. The
:10refers to a line number of a text file. The references to
likely refer to the home directory of the current user (
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).