Possible issue with Cap 1.4.1 and net-ssh 1.1.0?

[wse...@gmail.com]

I'm currently using Capistrano 1.4.1 and I upgraded net-ssh to version
1.1.0 this morning. I'm also using Jim Morris's SCM module for local
SVN access. When I try to deploy, my deployment blows up when trying
to connect to my remote server with the following output (I've replace
my fingerprint and server name to protect the innocent):

* querying latest revision...
* local executing: svn export -q -r15800 svn+ssh://dev/vol2/svn/
fsg/cap-one/branches/PR3 /tmp/CAP_TEMP_1178037278.66282
* local creating tar file: /tmp/CAP_TEMP_1178037278.66282.tar.gz
* sending tar file: /tmp/CAP_TEMP_1178037278.66282.tar.gz to remote /
tmp/CAP_TEMP_1178037278.66282.tar.gz
servers: ["myserver"]
*** [update_code] transaction: rollback
* [update_code] rolling back
* executing "rm -rf /var/www/www.myserver.com/releases/
20070501163438"
servers: ["myserver"]
** [update_code] exception while rolling back:
Net::SSH::HostKeyMismatch, fingerprint my_fingerprint does not match
for myserver
/opt/local/lib/ruby/gems/1.8/gems/net-ssh-1.1.0/lib/net/ssh/host-key-
verifier.rb:47:in `process_cache_miss': fingerprint my_fingerprint
does not match for myserver (Net::SSH::HostKeyMismatch)
from /opt/local/lib/ruby/gems/1.8/gems/net-ssh-1.1.0/lib/net/
ssh/host-key-verifier.rb:38:in `verify'
from /opt/local/lib/ruby/gems/1.8/gems/net-ssh-1.1.0/lib/net/
ssh/lenient-host-key-verifier.rb:9:in `verify'
from /opt/local/lib/ruby/gems/1.8/gems/net-ssh-1.1.0/lib/net/
ssh/transport/kex/dh.rb:165:in `verify_server_key'
from /opt/local/lib/ruby/gems/1.8/gems/net-ssh-1.1.0/lib/net/
ssh/transport/kex/dh.rb:232:in `exchange_keys'
from /opt/local/lib/ruby/gems/1.8/gems/needle-1.3.0/lib/needle/
lifecycle/proxy.rb:60:in `__send__'
from /opt/local/lib/ruby/gems/1.8/gems/needle-1.3.0/lib/needle/
lifecycle/proxy.rb:60:in `method_missing'
from /opt/local/lib/ruby/gems/1.8/gems/net-ssh-1.1.0/lib/net/
ssh/transport/session.rb:182:in `exchange_keys'
from /opt/local/lib/ruby/gems/1.8/gems/net-ssh-1.1.0/lib/net/
ssh/transport/session.rb:143:in `kexinit'
... 57 levels...
from /opt/local/lib/ruby/gems/1.8/gems/capistrano-1.4.1/lib/
capistrano/cli.rb:12:in `execute!'
from /opt/local/lib/ruby/gems/1.8/gems/capistrano-1.4.1/bin/
cap:11
from /opt/local/bin/cap:18:in `load'
from /opt/local/bin/cap:18

I rolled back my net-ssh version installed to 1.0.10 and everything
works fine. There weren't any warnings I noticed about version
incompatibilities on the announcement page. Has anyone else
encountered this?

[Jamis Buck]

Try this:

ssh_options[:paranoid] = false

That'll skip any host key verification.

If you try to use the command-line ssh client to connect to
"myserver", do you get any hostkey mismatch warnings?

- Jamis

[Jonathan del Strother]

I was getting this earlier, and I don't get it through command line
ssh.
In my case, I connect to multiple servers through one ip, with
different ports. ssh by default complains about mismatched host keys
with this configuration, until I persuaded it that they really were
different servers by setting HostKeyAlias on each server in .ssh/
config
I wonder if the same problem is causing problems in net-ssh...

On May 1, 6:17 pm, Jamis Buck <j...@37signals.com> wrote:
> Try this:
>
> ssh_options[:paranoid] = false
>
> That'll skip any host key verification.
>
> If you try to use the command-line ssh client to connect to
> "myserver", do you get any hostkey mismatch warnings?
>
> - Jamis
>

[LarryK]

Yes, I also had a problem with net-ssh 1.1.0

Error received on a winXP box with current capistrano and other gems
(fresh install)

When doing cap setup:

getnameinfo: address family for hostname not supported. (SocketError)
(see longer log below)

Moving to older net-ssh gem ver 1.0.10
solved the problem.

Regards,

LarryK in New York City

~~~~~~~~~

C:\instant_rails_1.7\InstantRails\rails_apps\am2>cap setup
* executing task setup
* executing "umask 02 &&\n mkdir -p /home2/ma1_deploy /home2/
ma1_deploy/releases /home2/ma1_deploy/shared /home2/ma1_deploy/shared/
system &&\n mkdir -p /home2/ma1_deploy/shared/log &&\n mkdir -p /
home2/ma1_deploy/shared/pids"
servers: ["192.168.22.2"]
C:/instant_rails_1.7/InstantRails/ruby/lib/ruby/gems/1.8/gems/net-
ssh-1.1.0/lib/net/ssh/transport/session.rb:108:in `getnameinfo':
getnameinfo: address family for hostname not supported. (SocketError)

[Jamis Buck]

Grrr.

I hate Windows.

Can someone with Windows networking chops take a look at that and see
if they can figure out why Net::SSH is choking? Otherwise, I'm just
going to add a caveat saying Windows users are out of luck and should
not upgrade.

- Jamis

[Ed Wagner]

For what it's worth, I'm seeing the same error on OS X with a pretty
fresh set of gems. The command line ssh works fine, and net-ssh 1.0.10
doesn't complain. The fingerprint that net-ssh 1.1.0 sees is in fact
different than the one that the command line ssh (OpenSSH_4.5p1) sees.

On May 1, 12:17 pm, Jamis Buck <j...@37signals.com> wrote:
> Try this:
>
> ssh_options[:paranoid] = false
>
> That'll skip any host key verification.
>
> If you try to use the command-line ssh client to connect to
> "myserver", do you get any hostkey mismatch warnings?
>
> - Jamis
>

[wse...@gmail.com]

I'm also remote deploying from OS X.

Adding "ssh_options[:paranoid] = false" does solve the problem.
Looking through the 1.0.10 docs, it looks like no hostkey verification
was performed, so this option will set 1.1.0 to behave as it was
before.

Command-line ssh into the server works fine as it always has, so I'm
still not clear on why Net::SSH is throwing Net::SSH::HostKeyMismatch.

[Chris Andrews]

[repost from correct address, i hope]

This is coming from the 'peer' method in lib/net/ssh/transport/
session.rb:

# Returns info about the remote peer
def peer
@peer ||= begin
addr = @socket.getpeername
ip_address = Socket.getnameinfo(addr,
Socket::NI_NUMERICHOST).first
{ :ip => ip_address, :port => @port.to_i, :host => @host }
end
end

I was able to replicate this problem on windows, with this code:

require 'socket'
include Socket::Constants
socket = Socket.new( AF_INET, SOCK_STREAM, 0 )
sockaddr = Socket.pack_sockaddr_in( 80, 'www.google.com' )
socket.connect( sockaddr )
addr = socket.getpeername
ip_address = Socket.getnameinfo(addr, Socket::NI_NUMERICHOST).first

which gives:

test.rb:11:in `getnameinfo': getnameinfo: address family for hostname
not supported. (SocketError)
from test.rb:11

It looks like this solves it:

ip_address = Socket.getnameinfo(addr, Socket::NI_NUMERICHOST |
Socket::NI_NUMERICSERV).first

I've not tested this in capistrano or even Net::SSH (though I will
later, on OSX), but it should help.

I suspect the reason we don't see this everywhere is that it depends
on the combination of IPv6 support in your kernel, in your resolver
and in your ruby build.

Chris.

[Michael Hartl]

I found this thread by dropping the error message into Google. I'm
having the same problem on Linux (CentOS). Setting
ssh_options[:paranoid] = false works for me as well.

My command-line ssh works fine currently, but errors like this do
happen when hosts move; fixing them usually involves editing the
~/.ssh/known_hosts file. Might something like that work here? Where
does the net-ssh host key cache live?

Michael

[Jamis Buck]

It uses the same known_hosts file as the OpenSSH command-line client
(~/.ssh/known_hosts).

- Jamis

[casey helbling]

Agreed. OSX has the same problem and ssh_options[:paranoid] = false
works around it.

Casey

[Michael Hartl]

> It uses the same known_hosts file as the OpenSSH command-line client
> (~/.ssh/known_hosts).

That's good to know. It turns out that the fault was mine: I hadn't
put the right user keys in all the right places. Once I did, it
worked. It took a while to figure out partially because there was no
error message; I would type "yes" to add the host and it would just
hang instead of prompting for a password.

Knowing that net-ssh uses the same ~/.ssh/known_hosts file is a big
help, since it eliminates (or at least identifies) one source of
problems.

Thanks,

Michael

[spyridon.v...@googlemail.com]

on winXP the ssh option (ssh_options[:paranoid] = false ) proposed by
Jamis did not work. Though rolling back to net-ssh-1.0.10 did the
trick.

[Khaled Hassounah]

the common theme in all I have read in this thread is that it is not
just that Capistrano fails, but that command line ssh doesn't warn
about keys. the server I was deploying to was in my ~/.ssh/known_host,
Capistrano was complaining about it. So I set HOME to my rails root
and that solved the problem.

What it did is that it created a .ssh file in my rails root which
contained the keys of all the servers Capistrano talked to. Since I
haven't thought through why this works, it is still officially a work
around. But I believe it is safer than disabling ssh paranoia
(ssh_options[:paranoid] = false).

cheers
Khaled

On May 1, 10:17 am, Jamis Buck <j...@37signals.com> wrote:
> Try this:
>
> ssh_options[:paranoid] = false
>
> That'll skip any host key verification.
>
> If you try to use the command-line ssh client to connect to
> "myserver", do you get any hostkey mismatch warnings?
>
> - Jamis
>

[Chris Andrews]

It works because this creates a separate $HOME/.ssh/known_hosts for Capistrano / Net-SSH to use. The issue people are seeing is when OpenSSH and Net-SSH share a known_hosts file, and there's already a (say DSA) host key in there from OpenSSH, and Net-SSH receives a RSA host key -- it doesn't take into account that different key types for the same host *shouldn't* match, and raises the exception you see.

I've suggested raising a different exception in this case, which by default could cause the key to be added to known_hosts as for a truly unknown host. Genuine same-type mismatches should still raise, of course.

The suggestion to change $HOME is good - thinking about it, instead of that, I'd like to see the location of known_hosts be configurable, and default to (say) $RAILS_ROOT/config/known_hosts. You could then prepopulate that with the keys for your servers, which would be an improvement on just accepting them the first time you deploy.

Thoughts?


Chris.