# SSH bug (or not?) solved " host key verification failed

## hwchen

Deat All:

These days i have installed gentoo for several machines. I always have a problem that user accounts can not ssh outside but root can. The reason is that the priority of /dev/tty is not correct. I have chmod 666 to it. And the question solve. This has once been a bug post on OpenSSH mail-list. The version with the bug is openssh 3.4. I wonder the bug is still exist in openssh 3.7.1 & 3.8. I do not know is this still a bug for other or it was just my method making the system. 

ps: I do not know how to report a bug, would someone like do me a favor to report this question?

                                        Sincerly Hwung-Wen Chen

----------

## kashani

Are these recent installs? Openssh 3.4 is pretty old, I think around June 2002. I'd guess there is a problem with the way you're installing it or that fact that the packages are so old.

kashani

----------

## mphilips

I had the same problem:

For any regular user:

```
user@host1 $ ssh host2

Host key verification failed.
```

Fixed by:

```
chmod 666 /dev/tty
```

Brand new 2004.1 install with udev and openssh-3.8_p1. 

Is the chmod 666 /dev/tty solution a workaround or the 'right answer'? Either way, what needs to be fixed, the openssh ebuild? Or is this an upstream openssh bug?

----------

## sirprize

I had the same problem and used the same fix, but I'd also like to know where the problem came from.

I installed that gentoo copy via a stage1 installation on an Athlon XP.

I basically did nothing important besides scripts/bootstrap.sh and emerge system.

----------

## Da_Big_G

THANK YOU!

I upgraded from a 2.4.x kernel with devfs to 2.6.7 with udev and suddenly couldn't ssh out to another box unless I was root.

This was solved with your 'chmod 666 /dev/tty' fix.

I just did the upgrade on a second box and had the same problem with the same fix, so I believe the problem is in udev. 

The problem manifested itself as a "Host key verification failed" message from ssh.

----------

## gnuageux

BTW editing .ssh/known_hosts will resolve this. You just remove the host key for said ip, then the next time you ssh to it it will accept it. This is not a bug. The admin of the remote server regenerated thier host key Id imagine.

----------

## gnuageux

~/.ssh that is  :Smile: 

----------

## Da_Big_G

 *gnuageux wrote:*   

> BTW editing .ssh/known_hosts will resolve this. You just remove the host key for said ip, then the next time you ssh to it it will accept it. This is not a bug. The admin of the remote server regenerated thier host key Id imagine.

 

That only helps if it's rejecting the host key for a valid reason.

The problem with udev is completely unrelated to the host key verification - it just fails at that point.  You have to make sure the perms on your /dev/tty are correct.

BTW:  I rebooted a few days ago and found that the permissions on /dev/tty are not sticky - that is, they revert to the default values causing the problem again.  I just reapplied the fix, but it would be nice to know how to permanently change the permissions under udev.

----------

## dmmgentoo

 *Da_Big_G wrote:*   

>  *gnuageux wrote:*   BTW editing .ssh/known_hosts will resolve this. You just remove the host key for said ip, then the next time you ssh to it it will accept it. This is not a bug. The admin of the remote server regenerated thier host key Id imagine. 
> 
> That only helps if it's rejecting the host key for a valid reason.
> 
> The problem with udev is completely unrelated to the host key verification - it just fails at that point.  You have to make sure the perms on your /dev/tty are correct.
> ...

 

I had a similar problem with xterm, as xterm refused to start with the default perms on /dev/tty.   You could try changing the perms in /etc/udev/permissions.d/50-udev.permissions.

----------

## firephoto

The latest versions of udev will fix this ssh problem so maybe you don't have the latest udev? udev-030 is the latest greatest but I believe 027 had the fix.

https://bugs.gentoo.org/show_bug.cgi?id=53292

That's the bug about this.

----------

