Every attempt to connect to anything from a new FreeBSD system results in a "host key verification failed." ssh 127.0.0.1 even fails this way. I started with a new FreeBSD4.7 installation and un-tarred the contents of another 4.7 system to essentially clone this one. My tar ball purposefully did not have the /etc/ssh directory in it so as to not overwrite any of the files in the new installation so I ended up with all the proper key files like I should. I can successfully connect to the system from remote hosts so sshd is working. I even regenerated my own host key with ssh-keygen -tdsa and that worked. Is there anywhere else besides my directory and /etc/ssh I should look to see what got clobbered? It worked fine before I unpacked the tar ball. I even deliberately deleted all the host keys in /etc/ssh and made it regenerate new ones. Other than the expected effect of causing the remote systems to complain about the host identity changing, nothing else happened. Martin McCormick WB5AGZ Stillwater, OK OSU Center for Computing and Information Services Network Operations Group
* De: Martin McCormick <martin@dc.cis.okstate.edu> [ Data: 2003-03-27 ] [ Subjecte: How did I Break ssh? ]> Every attempt to connect to anything from a new FreeBSD > system results in a "host key verification failed." > > ssh 127.0.0.1 even fails this way.Update your .ssh/ directories in their knowledge of this host, to not assume the old key. -- juli mallett. email: jmallett@freebsd.org; aim: bsdflata; efnet: juli;
My thanks to all who have offered suggestions as to what to try. Here is what I have learned today. I can completely remove .ssh from my home directory as in rm -r ~/.ssh and I get the "host key verification failed." message rather than an attempt to add a new key to whatever system I am trying to access. ssh does recreate .ssh, but it is empty. This is definitely related to my overlaying of the tar archive as I can demonstrate it on two different systems. I simply had not noticed it on the first one I built until now. I can use ssh-keygen to generate all my local keys with no effect except that the keys are good. If I copy the public key in to the authorized_keys file on a remote system, it gets me in to the sick system without a password. All in-bound connections work exactly as they should. No outbound connections using ssh work at all. The system I built that became the source of the tar balls which almost have built the other two systems couldn't be better. Its ssh outbound connections work perfectly. This has got to be something that either does not survive the tar extraction or it is something that only fits the system it was generated on. The only files I know about that are unique are all the keys in /etc/ssh and all the keys in each user home directory. The problem is system-wide on all the effected systems. I did notice on the other system I cloned that the presence of a known_hosts file caused any ssh attempt to return the same error that one gets when there have been too many retries at logging in to a remote host. The verification failure always occurs after the communication starts and keys are exchanged. If I try ssh -v 127.0.0.1 or ssh -v someremotehost.org, the debug output is almost identical between a working system and these sick ones except that I am offered a chance to add 127.0.0.1 to the list on the good system while the bad one just fails. If I answer no to the good system, I get the "host key verification failed" message, also. Any other ideas are appreciated. The idea of building new systems partly from tar balls appears to mostly work well if the systems are the same architecture which these are so it is important to know what is happening here because I suspect it isn't too hard to fix. Martin McCormick
On Friday 28 March 2003 04:48, Martin McCormick wrote:> Every attempt to connect to anything from a new FreeBSD > system results in a "host key verification failed." > > ssh 127.0.0.1 even fails this way. > > I started with a new FreeBSD4.7 installation and > un-tarred the contents of another 4.7 system to essentially clone > this one. >What does the /var/log/messages say just before or after you tried to logon to that machine? -- Alex
This is Martin McCormick again. I haven't yet fixed my problem with ssh not being able to write in my home directory, but I am hot on the trail. I have another question, but first I will tell all of you what I found out so anybody else who wants to try the same thing will know what to expect. As I originally said, I started out with a minimal installation of FreeBSD and then extracted a tar ball made from the root drive of another system to fill out the installation. My problem of not being able to get ssh to write new host keys in to ~/.ssh/known_hosts was obviously a permission problem, but what could it be? I finally found that the symbolic link between /home and /usr/home on the two cloned systems had the mode of 755 or rwxr-xr-x. Any link one normally makes has these permissions with the default umask controlling exactly what one gets. The man page for chmod says that the -H option lets you change the link's permissions, but I could never get it to work. The bits seem to stay the same no matter what. I discovered that I could delete the link, set my umask to 0 and remake it and I did get the right permissions which for the /home link are 777. This did not fix the problem, but I think there is probably another link I haven't noticed yet that is set wrong. What I found out is that the extraction process did not restore any of the links whose bits were all 1's. On one FreeBSD system, I have over 700 rwxrwxrwx links. On the cloned system I am trying to fix, I found only 5 and those were ones I had manually reset. My question is whether there is an easier way to set the bits on a link than deleting it, setting the umask to 0 and remaking it, of course, hoping that I don't botch the new link.:-) chmod -H 777 existing_link has no effect. Is there a proper way to do the tar extraction that faithfully preserves all the permissions? This is a mess, but at least I know what is most likely wrong now.
On Sun, 30 Mar 2003, Martin McCormick wrote:> Is there a proper way to do the tar extraction that > faithfully preserves all the permissions? This is a mess, but at > least I know what is most likely wrong now.For doing OS type stuff, you should probably use dump(8). It handles things like hard-linked files and such better. -- Matt Piechota