I like to use Krusader to SFTP into my other Machines on my Local Network to Transfer Files. And sometimes I use "root" mode to fix little problems like... A Broken X11 Server (No GUI working due to a Kernel Update). To go back to using the Standard X11 Driver instead of my Ati Radeon or nVidia Drivers, which often get Broken By Fedora Kernel Updates... Usually I can just rename or delete the /etc/X11/xorg.conf file. I rename mine, in case I need them later, to something without the ".conf" file extension. Like "xorg-conf-bk-04-28-11" (notice, no file extension, so that I can still open it in a Text Editor, but it will be ignored by the System). I have learned over the years, that Fedora and Debian Linux, will read any file in the "/etc/X11/" folder with the ".conf" extension on it. So, you're backup file will still be read, if it has the ".conf" extension and will still cause you're system to look for the Broken Video Driver which is called for in it and you still wont have any GUI... But After renaming it without a file extension, it will be ignored and a new one will be written Upon Reboot and my X11 GUI is back! And I can Reinstall my Ati or nVidia Driver in the comfort of my GUI Interface. No, muss, no fuss, and no Mucking around in the Command Line!;)
But, what do you do if you get an error like this in your SFTP Client (Krusader)??? 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 is 3f:1b:f4:bd:c5:aa:c1:1f:bf:4e:2e:cf:53:fa:d8:59. Please contact your system administrator. Add correct host key in /home/peter/.ssh/known_hosts to get rid of this message. Offending key in /home/peter/.ssh/known_hosts:3 RSA host key for 192.168.0.100 has changed and you have requested strict checking. Host key verification failed.$
But, you know darn well nothing is wrong with your own Server (other Computer) on you own Local Network! Here's what I found and it is actually easy to do in the GUI....
Read on to see how to do it in the GUI with your favorite Text Editing App. I just used the default Editor in Krusader...
Don
Home » Resources » How-to guides:
Deleting an RSA host key
When logging into another computer using SSH, an RSA host key is stored on the terminal computer and then checked for parity at future logins.
If the operating system of the host computer changes (e.g. re-install with the same hostname), an error message will occur notifying the user that the remote host ID has changed and access will be denied:
If you are sure that the changes made to the host computer were legitimate, you can edit the known_hosts file and delete the original key. At the next login you will be prompted to verify the host machine again. This will add the correct key to the known_hosts file and allow access.
To delete the key use either of the following:
Using the GUI:
Browse to the home directory of the user that requires login access.
Browse to the ./ssh directory, and open the file named known_hosts.
Tip: Show hidden directories, if required.
Find the offending key, delete, save and exit.
Tip: If you are unsure of the correct key, simply delete them all and save the empty file. You will then be prompted again to verify any machine that had previously been given access.
Note from me, Don:
If you use Krusader to do this, like I do. Really, what ever GUI File Manager you use to find and edit your ".ssh/known_hosts" file. Thunar will run in "root" mode. Pay attention to whither you are trying to log in to your remote system as a regular user (ie, "don" or as "root"). For instance, if you are using Krusader in regular user mode (that's don for me). Then you would need to edit your /home/don/.ssh/known_hosts file. But if you are using Krusader in "root" mode. Say, to copy files to your "/var/ftp/pub" directory (which needs "root" privileges). Then the "known_hosts" file that you need to edit, is in your "/root/.ssh/known_hosts" directory. I wasn't paying attention to this today (a month or so after I posted this) and it took me 15 minutes to figure out why my edits of my "known_hosts" file did no good!:O
Don
Via the terminal:
Read More...
http://www.forwestmedia.com/resources/how-to-guides/deleting-an-rsa-host-key/
Or it's not too bad in the Terminal either. Say, if you need to do this on a Remote Server, via Putty or something like that... You can just open up the "known_hosts" file in your favorite Command Line Text Editor, like this... Just substitute your Text Editors run command, which is installed on the remote or local machine that you are editing the "known_hosts" file on. And substitute your user name for "user" here...
vi /home/user/.ssh/known_hosts
or
gedit /home/user/.ssh/known_hosts
Saturday, October 18, 2008
How to disable SSH host key checking
Remote login using the SSHinternet world. With the SSH protocol, the onus is on the SSH client to verify the identity of the host to which it is connecting. The host identify is established by its SSH host key. Typically, the host key is auto-created during initial SSH installation setup.
By default, the SSH client verifies the host key against a local file containing known, rustworthy machines. This provides protection against possible Man-In-The-Middle attacks. However, there are situations in which you want to bypass this verification step. This article explains how to disable host key checking using OpenSSH, a popular Free and Open-Source implementation of SSH.
When you login to a remote host for the first time, the remote host's host key is most likely unknown to the SSH client. The default behavior is to ask the user to confirm the fingerprint of the host key.
$ ssh peter@192.168.0.100 The authenticity of host '192.168.0.100 (192.168.0.100)' can't be established. RSA key fingerprint is 3f:1b:f4:bd:c5:aa:c1:1f:bf:4e:2e:cf:53:fa:d8:59. Are you sure you want to continue connecting (yes/no)?
If your answer is yes, the SSH client continues login, and stores the host key locally in the file ~/.ssh/known_hosts. You only need to validate the host key the first time around: in subsequent logins, you will not be prompted to confirm it again.
Yet, from time to time, when you try to remote login to the same host from the same origin, you may be refused with the following warning message:$ ssh peter@192.168.0.100 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ 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 is 3f:1b:f4:bd:c5:aa:c1:1f:bf:4e:2e:cf:53:fa:d8:59. Please contact your system administrator. Add correct host key in /home/peter/.ssh/known_hosts to get rid of this message. Offending key in /home/peter/.ssh/known_hosts:3 RSA host key for 192.168.0.100 has changed and you have requested strict checking. Host key verification failed.$
There are multiple possible reasons why the remote host key changed. A Man-in-the-Middle attack is only one possible reason. Other possible reasons include:
OpenSSH was re-installed on the remote host but, for whatever reason, the original host key was not restored.
The remote host was replaced legitimately by another machine.
If you are sure that this is harmless, you can use either 1 of 2 methods below to trick openSSH to let you login. But be warned that you have become vulnerable to man-in-the-middle attacks.
The first method is to remove the remote host from the ~/.ssh/known_hosts file. Note that the warning message already tells you the line number in the known_hosts file that corresponds to the target remote host. The offending line in the above example is line 3("Offending key in /home/peter/.ssh/known_hosts:3")
You can use the following one liner to remove that one line (line 3) from the file.$ sed -i 3d ~/.ssh/known_hosts
Note that with the above method, you will be prompted to confirm the host key fingerprint when you run ssh to login.
The second method uses two openSSH parameters:
StrictHostKeyCheckin, and
UserKnownHostsFile.
This method tricks SSH by configuring it to use an empty known_hosts file, and NOT to ask you to confirm the remote host identity key.$ ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no peter@192.168.0.100 Warning: Permanently added '192.168.0.100' (RSA) to the list of known hosts. peter@192.168.0.100's password:
The UserKnownHostsFile parameter specifies the database file to use for storing the user host keys (default is ~/.ssh/known_hosts).
The /dev/null file is a special system device file that discards anything and everything written to it, and when used as the input file, returns End Of File immediately.
By configuring the null device file as the host key database, SSH is fooled into thinking that the SSH client has never connected to any SSH server before, and so will never run into a mismatched host key.
The parameter StrictHostKeyChecking specifies if SSH will automatically add new host keys to the host key database file. By setting it to no, the host key is automatically added, without user confirmation, for all first-time connection. Because of the null key database file, all connection is viewed as the first-time for any SSH server host. Therefore, the host key is automatically added to the host key database with no user confirmation. Writing the key to the /dev/null file discards the key and reports success.
Please refer to this excellent article about host keys and key checking.
By specifying the above 2 SSH options on the command line, you can bypass host key checking for that particular SSH login. If you want to bypass host key checking on a permanent basis, you need to specify those same options in the SSH configuration file.
You can edit the global SSH configuration file (/etc/ssh/ssh_config) if you want to make the changes permanent for all users.
If you want to target a particular user, modify the user-specific SSH configuration file (~/.ssh/config). The instructions below apply to both files.
Read More on his Blog...
http://linuxcommando.blogspot.com/2008/10/how-to-disable-ssh-host-key-checking.htmlIn Comments...
Chetan Chauhan said...
Excellent tutorial . 5 stars. i made a script to do this for "problematic hosts" , just copy and paste into edit /bin/sshu ----START-COPY---- # ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no "$@"' ---SNIP----- Usage - chmod 775 /bin/sshu sshu myhost
February 10, 2009 10:34 PM
Read More... http://linuxcommando.blogspot.com/2008/10/how-to-disable-ssh-host-key-checking.html
SSH Host Key Protection
Updated: 21 Mar 2011
by Brian Hatch
This is the first in a series of articles on SSH in-depth. We start with looking at standard SSH host keys by examining the verification process to ensure you have not been the victim of an attack. Please note that this article applies to the widely used OpenSSH application that is bundled with most Unix based operating systems, and not the commercial version of SSH.
SSH Host Keys as a protection against Man-In-The-Middle Attacks
SSH is a ubiquitous protocol that offers secure, encrypted connections for a variety of purposes, including logging into remote machines, transferring files, setting up encrypted tunnels, running remote commands without manual authentication, and more. It was created to replace many non-encrypted protocols such as Telnet, FTP, RSH, and the like.
One of the problems with these old protocols, aside from the fact that they send everything (your password included) in the clear, is that they are vulnerable to man-in-the-middle attacks. A cracker with access to the intermediate network could intercept your packets, log them, and then send them to the actual destination. Even worse, she could re-write your packets, perhaps replacing ls -l mydir with rm -r mydir, or send you a trojaned file via your intercepted FTP session rather than the original. Since these protocols have no way to know with certainty whom you were talking to, any number of tricks were possible.
SSH offers a crucial feature -- the ability for you to verify the identity of the host to which you're connecting. If you correctly verify the host, then there's no way an intermediate device could be reading or manipulating your packets. [ref 1] Successful host verification indicates that the connection is encrypted end-to-end -- your SSH client has established a secure connection with the SSH server itself, and no intermediate machines have access to that connection.
Host verification is not unique to SSH. Any decent security-aware protocol has some sort of peer verification. For example, let's take a look at HTTPS, the SSL/TLS encrypted version of HTTP. It also offers host verification in much the same way as SSH. HTTPS host verification looks like the following. I've taken the liberty of mapping SSL-speak into SSH-speak to make it clearer to compare later on. [ref 2]
The client (web browser) connects to the server (HTTPS-aware webserver on port 443.)
The server provides its public key (X509 Certificate).
Some mystical, mathematical number crunching proves that the server has access to the private key associated with the public key.
The browser checks to see that the public key was signed by a trusted Certificate Authority (such as Verisign, Thawte, or others).
The browser checks that The CN (X509 Common Name) value in the server's certificate matches the host name you used. IE if connecting to https://www.example.com, then the certificate needs to have www.example.com as the CN value.
All of these step have their analogue in the world of SSH except for one: there is no Certificate Authority at all. [ref 3] Instead, the 'authority' are your personal and global configuration files, which we'll see later.
SSH Host Keys in Action
Let's see how SSH maps these steps by making an SSH connection to a machine we've never contacted before:
Read More...
http://www.symantec.com/connect/articles/ssh-host-key-protection
Clean old host keys
Remote Connections
clean old host key - Google Search
Deleting an RSA host key By Forwest Media
security - How to remove strict RSA key checking in SSH and what's the problem here? - Server Fault
ssh - Remove key from known_hosts - Super User
Linux Commando: How to disable SSH host key checking
Security Articles | Symantec Connect Community Community
SSH host-key changed errors
How-to guides
Setting up a POP3 mail account in Outlook Express
Setting up a POP3 mail account in Mozilla Thunderbird
Creating a custom email footer and other stationery in Outlook
Archiving email in Outlook
Move a Personal Folder (PST file) in Outlook
Web Browsers and Applications
Temporarily disable flash player in browsers
Disable the Adobe flash player auto-update notification
Mozilla Firefox configuration and setup
Mozilla Firefox profiles
Encryption
Encrypting a drive using TrueCrypt
Remote Administration
Remote login options
TightVNC installation and use
Deleting an RSA host key
Windows
Create a text file of the contents of a directory in Windows Explorer
Sharing files and folders in Windows XP
Linux
Basic Linux BASH commands
Directory and file commands (in Linux)
Linux file permissions
Storage device information (partitioning, formatting and mounting in Linux)
Editing from the CLI with Vi (and gedit)
Using rsync to syncronise / backup data
No comments:
Post a Comment