# ssh_askpass ?

## viperlin

```

[john@Raiden john]$ ssh root@viperlin

ssh_askpass: exec(/usr/lib/misc/ssh-askpass): No such file or directory

Write failed: Broken pipe

[john@Raiden john]$ 

```

erm this started happening, i don't have x11-ssh-askpass installed and i don't want it installed, i like it asking for the password in the commandline, i don't want a silly box popping up.

any takers on how to disable it?

----------

## pjp

Moved from Desktop Environments.

----------

## viperlin

sorry i figured because it was to do with a GUI problem and seemingly not ssh it'self or the connection it belonged in here, it's a GUI problem, after all i can't use ssh in the commandline at all. (must have X running and be inside X and have a graphical password asker installed)

----------

## pjp

Being ssh, I figured more people familiar with it would know why it was requiring the X app.

----------

## ctford0

 *viperlin wrote:*   

> 
> 
> ```
> 
> [john@Raiden john]$ ssh root@viperlin
> ...

 

Is there some particular reason that you dont have an ssh-askpass file?  

Also, x11-ssh-askpass only pops up when executed, I have it installed and do not get popups when loggin into another machine via the command line.  However, there are some gui programs that will not function properly if you dont have x11-ssh-askpass.  It's all a matter of preference...

```

user@desktop user $ ssh xx.xx.xx.xx

user@xx.xx.xx.xx's password:

```

```

Calculating dependencies ...done!

[ebuild   R   ] net-misc/x11-ssh-askpass-1.2.2-r1

```

chris

----------

## viperlin

i just 5 mins ago found out what was causing this and i'm confused

/dev/tty had re-set permissions so that ony root could read and write to it (and just before i had added preliminary usb device filesystem to my kernel)

this caused it to fal back to the requirement of some form of graphical password asker (which i didn't have installed so i had to install one)

luckily this seems to have been fixed by chmoding /dev/tty

i just hope no other permissions have changed  :Neutral: 

----------

## ctford0

Are you running 2.6??

Chris

----------

## viperlin

2.4.22 vanilla

----------

## jesterspet

I know i had to add this to my ~/.bash_profile

```
export SSH_ASKPASS="/usr/bin/x11-ssh-askpass"
```

Try running echo $SSH_ASKPASS to see if that enviroment varable is set.

I also think you may want to look at the man page for ssh and search for SSH_ASKPASS.  It might shed some light on your current situation in regards to terminals, displays, and what not.

----------

## viperlin

i've posted back i've allready solved the problem  :Neutral:  permissions on /dev/tty were set to root only after a kernel recompile, don't know why though

----------

## ben_h

I've been having (almost) exactly the same problem.

```
ben [~] $ ssh <anything>

ssh_askpass: exec(/usr/lib/misc/ssh-askpass): No such file or directory

Host key verification failed.

ben [~] $ 
```

It works fine as root though. Sure enough,

```
crw-rw----  1 root root 5, 0 Jun 11 21:50 /dev/tty
```

Chmodding that back to 666 is no problem, but does anyone know what would have changed that in the first place?

I did some emerging the other day, including baselayout iirc, but then again, I do a lot of emerging  :Wink: 

----------

## Elm0

I'm having the same problem and I reckon it might be the baselayout, as I remember emerging a new version a few days back...

I'm not a heavy user of SSH though so I might be wrong, but if you have the same suspicion I think we might be getting along the right track.

gtk2-ssh-askpass isn't too bad actually, but I still prefer just having it in the terminal.

----------

## morbid

bingo!  udev-026-r1 included a new /etc/udev/udev.conf.  Can't show an exact diff since I've already etc-update'd.  But diff'ing udev.conf and ._cfg0001_udev.conf show'd this as the only difference:

default_mode="0660"

I first experienced the /dev permission issue when I was ripping cd's to flac... and abcde started giving errors.  Sure enough, I (being the user) no longer had permissions to /dev/hdc

Looks like this excerpt from udev.conf may shed some light...

 *Quote:*   

> # udev_permissions - The name and location of the udev permission file
> 
> udev_permissions="/etc/udev/permissions.d/"
> 
> # default_mode - set the default mode for all nodes that have no 
> ...

 

----------

## Elm0

Yep, thats it!

Do you have an idea what it was before the update to udev?

Presumably 666 isn't a very good idea security wise, though I'm no expert on these matters.

----------

## Tormented-Soul

i had the same problem. so i searched the forum and found this bug-report: https://bugs.gentoo.org/show_bug.cgi?id=53292

i read it, but i tried a different way: i put the user into the tty group. i think thats more secure than doing the 666-stuff  :Wink: 

----------

## morbid

I believe it was 0666.  Wish there was a better communication mechanism for major changes like this.

----------

## Elm0

Upgraded to the latest version of udev, 027-r1 I believe and this is fixed. It keeps the default permissions mask the same but adds some entries into udev.permissions in relation to the different tty settings.

----------

