Ross Boylan wrote: > I can ssh from machine A to B as user ross on both, using key-based > login. ssh-agent is running under KDE on A. A is Debian wheezy, B is > Debian squeeze. > > However, when I do the following sequence on A: > sux # change to root with X credentials > ssh -i /home/ross/.ssh/id_rsa ross@B > > A window pops up with the message "The authenticity of host 'xxx' > can't be established. > RSA key fingerprint is YYY. > Are you sure you want to continue connecting (yes/no)? > The title is "OpenSSH Authentication Passphrase Request" and it has 2 > buttons, "OK" and "Cancel". > When I click OK I get a message, in my original terminal, > Host key verification failed. I think there must be a problem/confusion in there surrounding the $HOME at that time. I suggest double checking $HOME/.ssh/known_hosts for every possible value of $HOME that you can postulate. Maybe that will turn up something. > Clicking cancel doesn't change the result. Operating in a shell from > which I have unset DISPLAY and the SSH_AGENT variables doesn't change > the result (there's no popup, just an immediate verification failure). Try it with the idea that $HOME isn't correctly as expected. Using the command 'printenv HOME' can be useful because it avoids $HOME being expanded by the shell and will expand the actual value of it at that later time just like the real program. > I would be very grateful if anyone could explain what's going and what > I can do to get past this. I have checked permissions of the relevant > files for ross and root on A, and they appear to be in order. On A, > root's .ssh/ has only a known_hosts file. You are using sux which I never use. I am unfamiliar with the details and the details are what is needed to understand what is happening. If you sux a terminal (xterm or other) instead of an ssh what do you get for $HOME? In that terminal if you ssh to the remote host what do you get? (Unset DISPLAY to avoid the dialog and force in terminal errors if you get one.) I would also check and possibly unset SSH_ASKPASS too. I suspect that when you sux a terminal something will be different from what you expect. > I have never encountered this popup before; I have only seen the "Are > you sure you want to continue connecting" in the same terminal from > which I ran ssh, and I can reply on the command line. I don't know > where the popup is coming from. It sounds to me like this popup is part of KDE. I have seen both KDE and GNOME try to encapsulate ssh like this before. > My speculation is that because of the popup all my responses are taken > as "No" for continuing connecting. > > I have to run as root for sshuttle. If you sux a terminal then you will be root. Then use that shell to understand what is happening. Personally I would simply su or sudo in a regular terminal. I don't see a need to use sux for this. But each to their own. However you might try that in this case in order to probe the edges of the box. su - (or sudo -s, or sudo su -, or whatever) ssh ... > By using su instead of sux I eliminated the popup and got past the > host verification. Now that root on A has B in the known_hosts file I > can connect from the sux session as well. Oh! I see you got past this but it took me so long to reply that I decided to leave the above in my mail anyway. > I still do not understand where the popup came from and why it didn't > work. Here's some more info on what ssh was doing during the failed > connection: > > debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY > debug1: Server host key: RSA 14:d2:cd:ea:d3:a0:82:5b:25:b8:8d:00:ad:c5:54:68 > debug1: checking without port identifier > debug1: read_passphrase: can't open /dev/tty: No such device or address > debug1: permanently_drop_suid: 0 > Host key verification failed. > > I think the popup happened after the last debug line above. If the host key verification failed then it is because of one of the host key files /etc/ssh/ssh_known_hosts or $HOME/.ssh/known_hosts doesn't contain the current key or doesn't match the current key. You likely do not have /etc/ssh/ssh_known_hosts therefore I suspect that $HOME isn't what you think it is at that moment due to sux setting it different from what you expect. Bob
Attachment:
signature.asc
Description: Digital signature