Bug 872 - SSH client fails for non-root users with "Host key verification failed"
Summary: SSH client fails for non-root users with "Host key verification failed"
Status: CLOSED DUPLICATE of bug 471
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: ssh (show other bugs)
Version: 3.8.1p1
Hardware: ix86 Linux
: P2 major
Assignee: OpenSSH Bugzilla mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-05-24 05:19 AEST by Josh
Modified: 2004-09-11 13:18 AEST (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Josh 2004-05-24 05:19:27 AEST
Attempting to open an ssh session to any remote host fails when attempted by a
non-root user.  The error message is 

ssh_askpass: exec(/usr/lib/misc/ssh-askpass): No such file or directory
Host key verification failed.

Yes, ssh-askpass is not installed as the client system is not running X.  When
the root user executes the same command (ssh remoteuser@remotehost) the ssh
client displays the password prompt on stdout, accepts the password on stdin,
and opens the session successfully.  I've seen evidence that others are
encountering this problem: 

http://www.derkeiler.com/Mailing-Lists/securityfocus/Secure_Shell/2003-11/0016.html
 
 and 
http://lists.debian.org/debian-ssh/2004/04/msg00058.html
Comment 1 Ben Lindstrom 2004-05-24 05:26:43 AEST
I would check to see if you have "SSH_ASKPASS" and "DISPLAY" are set.
Comment 2 Josh 2004-05-24 06:16:26 AEST
The "Host key verification failed" message persists even after DISPLAY is unset.
 Here's a transcript of a session showing the error messages with and without
DISPLAY set, and a successful Password: prompt when run as root.  (I can attach
output of ssh -vvv if it would be helpful)

Script started on Sun May 23 13:05:27 2004
[MY_USERNAME@epic] ~ [501]$ echo $DISPLAY

[MY_USERNAME@epic] ~ [502]$ echo $SSH_ASKPASS

[MY_USERNAME@epic] ~ [503]$ ssh grace.speakeasy.net
Host key verification failed.
[MY_USERNAME@epic] ~ [504]$ DISPLAY=:0 ssh grace.speakeasy.net
ssh_askpass: exec(/usr/lib/misc/ssh-askpass): No such file or directory
Host key verification failed.
[MY_USERNAME@epic] ~ [505]$ su
Password: 
[root@epic] /home/MY_USERNAME [500]$ echo $DISPLAY

[root@epic] /home/MY_USERNAME [501]$ echo $ASKPASS

[root@epic] /home/MY_USERNAME [502]$ ssh MY_USERNAME@grace.speakeasy.net
Password: 
[root@epic] /home/MY_USERNAME [503]$ exit
[MY_USERNAME@epic] ~ [506]$ 
Script done on Sun May 23 13:06:24 2004
Comment 3 Ben Lindstrom 2004-05-24 06:43:59 AEST
Sounds like you have a bad .ssh/known_hosts entry.  Compare the entry with that of roots.  I suspect 
you'll find them to be different.
Comment 4 Josh 2004-05-24 08:23:26 AEST
Negative, there is no ~/.ssh/known_hosts file at all.  I confirmed that it
applies to all nonroot accounts by creating a new user and trying to ssh as that
new user -- same thing.
Comment 5 Darren Tucker 2004-05-24 09:10:36 AEST
Does /dev/tty exist and does it have the correct permissions?
$ ls -l /dev/tty
crw-rw-rw-    1 root     root       5,   0 May 12 13:29 /dev/tty
Comment 6 Josh 2004-05-24 13:27:14 AEST
/dev/tty is mode 660 rather than 666 as shown below:

[root@epic] ~ [504]$ ls -l /dev/tty
crw-rw----  1 root root 5, 0 Dec 31  1969 /dev/tty

Could the difference in permissions be a BSD vs. Linux issue?  I've never
changed any permissions in /dev so they were determined by the Gentoo
maintainers.  When I changed the permissions to 666 the problem was resolved,
however I'm curious if they were originally set to 660 for a good reason.

Also, a Google search using some keywords from the previous comment reveals that
this bug appears to be a duplicate of bug 471 for which a patch has been
submitted.  For now I've changed permissions on /dev/tty which has resolved the
issue -- thanks to everyone for your assistance.
Comment 7 Darren Tucker 2004-05-24 13:36:05 AEST
No, a mode 660 /dev/tty is not a BSD/Linux thing, it's just wrong, and if
Gentoo's installer makes it that way then it's buggy.

*** This bug has been marked as a duplicate of 471 ***