Changing Host Keys

It seems to be true with computers that increased security is bought at the price of increased inconvenience. Almost nothing ever went wrong with telnet and ftp -- except that they gave our passwords to hackers on a silver platter!

The ssh family of programs (including ssh, scp, sftp) get changed periodically as weaknesses are discovered and fixed. Furthermore, a host may generate a new public encryption key (usually when ssh is upgraded, possibly unintentionally) which raises red flags when somebody tries to access the newly-affected host. Ssh is supposed to give a warning when it detects that a hostkey has changed.

If you know that ssh has been recently upgraded on some host, or that its hostkey has been legitimately changed, you can ignore the warning and change to the new hostkey as detailed below.

 

If you encounter a problem with ssh/scp/sftp not mentioned below, contact your local computer systems administrator.

 

 

1. Unix command line warning (``REMOTE HOST IDENTIFICATION HAS CHANGED''

This message usually comes with the additional warning ``It is possible that someone is doing someting nasty!'' Looks alarming.

Normally, however, this is just due to a changed host key on the remote host (i.e., the computer you are trying to ssh/scp to), and not an actual hacker activity. A new host key may be generated on that host when a new version of ssh is installed.

SOLUTION: Use your text editor (vi, emacs, nedit, pico) to open your file ~/.ssh/known_hosts, and edit it by removing each line containing the host's name. (The WARNING message may actually tell you the line of the file, e.g.,
Offending key in /home/student/smithj/.ssh/known_hosts:6
indicates that line #6 is the line to delete.)

 

2. F-Secure SSH or FTP

Running the FSecure SSH/SFTP programs on Windows computers, you will get warnings when the remote host's hostkey changes. (Actually, in the case of FSecureFTP, the connection simply fails without explanation.)

SOLUTION: run FSecure SSH (not FTP), and from the EDIT menu select either Properties or Configuration. Of the options which appear, click on "Host Keys". In a new window will be a list of the hostkeys collected to date from remote hosts. (Some remote hosts will have two entries, e.g., both newton and newton.colorado.edu.) Highlight each line mentioning the troublesome host (e.g., newton) and click on "Delete".

Afterwards, close that window and try a new connection to that host; it will act as though it were the very first time you've tried connecting to that host, and require you to type the word `yes' to accept a new hostkey. Thereafter you should be able to SSH and SFTP to that host without problem. Until the next time something changes!

 

3. Macintosh MacSFTP/MacSSH failure

If you use MacSFTP or MacSSH on a Macintosh, rather than the Unix commands "ssh" or "scp" in the MacOSX terminal window, the obsolete hostkeys are stored in the text file ~/Library/Preferences/OpenSSH/known_hosts, so you must edit out the old hostkeys from that file (instead of ~/.ssh/known_hosts).

Quit MacSFTP entirely, then use vi or emacs or any other text editor to delete the bad entries from ~/Library/Preferences/OpenSSH/known_hosts. Then you can run MacSFTP again and accept host keys afresh.