Net::SSH 1.1.1

Posted by Jamis on May 09, 2007 @ 10:11 PM

Hot on the heels of Net::SSH 1.1.0 comes version 1.1.1. This version fixes the most egregious problems that have been reported, primarily for Windows users. Windows users should no longer get the “address family for hostname not supported” errors, and the broken mkdir call has been fixed.

$ gem install net-ssh

For those of you having problems with the host key verification stuff, my apologies. However, it is all working beautifully for me, both on Windows and on my Mac, so it’s really hard for me to figure out what might be going wrong for others. I’m going to need someone who is having the problem, and who is not afraid of jumping into the Net::SSH source code, to do some investigating for me. That, or you’ll have to send me really, really detailed reports so that you can help me duplicate the issues.

Posted in Announcements

Comments

Have something to add? Click here to leave a comment.

10 May 2007

1. Jeroen said...

Good news! However I get this on Windows

gem install net-ssh Need to update 37 gems from http://gems.rubyforge.org ..................................... complete ERROR: While executing gem … (Zlib::BufError) buffer error

And local install too:

gem install c:\net-ssh-1.1.1.gem ERROR: Error installing gem c:\net-ssh-1.1.1.gem[.gem]: buffer error

HTH

jeroen

2. Chris Andrews said...

I think the host key verification trouble is down to slightly incorrect handling of the different key types—attempting to match (say) a DSA key from the server with the same server’s RSA key in the known_hosts file results in a mismatch, not the adding of the new key.

Patch with a possible fix should be on the capistrano list.

Chris.

3. Jamis said...

There is apparently something broken with Ruby’s zlib bindings on Windows. For now, you can work around it by changing line 856 of c:\ruby\lib\ruby\site_ruby\1.8\rubygems\package.rb so that it compares on version 1.2.3 of Zlib, instead of 1.2.1:

1
if Zlib::ZLIB__VERSION <= '1.2.3'

(If you’re not using the one-click installer, you’ll need to find package.rb wherever it’s installed on your system.)

4. Jamis said...

Oops, that’s line 618, not 856.

5. joe said...

add type check to key matching:

host-key-verifier.rb:

def verify(arguments)
    # first, find any matches on hostname+port
   matches = keys.select do |item|
        host = item[:host] || arguments:peer
        ip   = item[:ip]   || arguments:peer
        port = item[:port] || arguments:peer
        type = item[:type] || arguments:peer
host  arguments:peer &&
  ip    arguments:peer   &&
  port  arguments:peer &&
  type  arguments[:key].ssh_type
end

6. Assaf said...

I ran into the same ZLib problem, and apparently adding empty lines at the end of one of the files cured it. I don’t remember where I read it, and I have no clue why it would work. It just does.

7. Jamis said...

Assaf, yeah, that worked for me before, too, but not this time. I’ve tried everything I can think of to change the size of the files, but the size of the gem keeps changing in multiples of 256 bytes, and the buffer error keeps occurring.

I’ve been in touch with Chad Fowler, and he and Jim Weirich will be releasing a new version of rubygems today sometime that fixes this issue.

8. Glenn Rempe said...

Hi Jamis,

Here is a slightly more obscure one. I am using Dr. Nic’s GemsOnRails gem to freeze gems into my vendor dir. If I freeze net-ssh I am no longer able to run rake tasks, or start the included ./script/server, or run my app via litespeed.

http://drnicwilliams.com/2007/02/09/railsrally-2007-and-gemsonrails/

Here is the error I see. Is this an issue with net-ssh you think? or with the gemsonrails gem? I have about 10 or so other gems frozen with no issues. I’ll report it to Dr. Nic as well.

Here is my output:

FREEZE NET-SSH GEM

macbook-pro:/usr/local/src/svk/APP/trunk/APP glenn$ rake gems:freeze GEM=net-ssh (in /usr/local/src/svk/APP/trunk/APP) Unpacked net-ssh 1.1.1 to ‘net-ssh-1.1.1’

FAILS TO START

macbook-pro:/usr/local/src/svk/APP/trunk/APP glenn$ ./script/server => Booting Mongrel (use ‘script/server webrick’ to force WEBrick) => Rails application starting on http://0.0.0.0:3000 => Call with -d to detach => Ctrl-C to shutdown server
  • Starting Mongrel listening at 0.0.0.0:3000
  • Starting Rails with development environment… Exiting /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.3/lib/commands/servers/mongrel.rb:15: warning: already initialized constant OPTIONS /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.3/lib/commands/servers/mongrel.rb:18: undefined method `options’ for []:Array (NoMethodError) from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:32:in `gem_original_require’ from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:32:in `require’ from ./script/../config/../vendor/rails/activesupport/lib/active_support/dependencies.rb:495:in `require’ from ./script/../config/../vendor/rails/activesupport/lib/active_support/dependencies.rb:342:in `new_constants_in’ from ./script/../config/../vendor/rails/activesupport/lib/active_support/dependencies.rb:495:in `require’ from ./script/../config/../vendor/rails/railties/lib/commands/server.rb:39 from ./script/server:3:in `require’ from ./script/server:3

UNFREEZE

macbook-pro:/usr/local/src/svk/APP/trunk/APP glenn$ rake gems:unfreeze GEM=net-ssh (in /usr/local/src/svk/APP/trunk/APP)

NOW IT WORKS

macbook-pro:/usr/local/src/svk/APP/trunk/APP glenn$ ./script/server => Booting Mongrel (use ‘script/server webrick’ to force WEBrick) => Rails application starting on http://0.0.0.0:3000 => Call with -d to detach => Ctrl-C to shutdown server
  • Starting Mongrel listening at 0.0.0.0:3000
  • Starting Rails with development environment…
  • Rails loaded.
  • Loading any Rails specific GemPlugins
  • Signals ready. TERM => stop. USR2 => restart. INT => stop (no restart).
  • Rails signals registered. HUP => reload (without restart). It might not work well.
  • Mongrel available at 0.0.0.0:3000
  • Use CTRL-C to stop. ^C** INT signal received. Exiting

PS : I also tried freezing net-ssh versions 1.1.0 and 1.0.10 and both behaved the same so this is not a brand new regression.

Thanks,

Glenn

9. Jatinder Singh said...

I spent a few hours trying to find out why I was constantly getting errors “address family for hostname not supported” on my Windows box while trying to use Capistrano. http://www.ruby-forum.com/topic/107020 provides a tip to add systemroot\system32\drivers\etc\services file, ssh 22/tcp #SSH and which works like a charm.

But now I am sure I dont have the remember above step if I use NET-SSH 1.1.1. Thanks Jamis!

11 May 2007

10. Assaf said...

{expletive deleted}

I’m also getting 256 increments on the gem size, before and after the ruby-gem update. Do you know if the problem is packaging or unpackaging Gems—which side deserves corporal punishment?

11. Assaf said...

After updating rubygems, net-ssh now installs correctly on XP.

However, you need to run gem update rubygems-update first. If I just run gem update, it tries to update net-ssh first and fails.

15 May 2007

12. David said...

Strange, net/ssh breaks when used in Rubyscrip2EXE-applications. I have not yet found out why.

13. Remco said...

The host key verification problem, at my macbook, has to do with a “broken” known_hosts file. Some of the lines in my file don’t have the address part, they start with a space. Removing those lines works around the problem. Maybe the load_keys_from method should use an regex on line 90 instead of split?

14. Jamis said...

Remco, could you propose a regex to use? It’s hard, because (as far as I can tell) the known_hosts file format is not formally documented anywhere, so it’s hard to know what all the possible permutations are. A patch would be very welcome :).

18 May 2007

15. Gabe said...

Jamis, I believe all you need to do to reproduce the key problem is have an rsa key in your known_hosts file, but no dss key.

When doing `cap deploy` (with svn) against a blank known_hosts file it will fail because svn writes an rsa key (well at least in my case it does). However if you first do a `cap restart` it will write the DSS key and then you are all good.

Joe’s solution above works, but you can’t read it because of the markup parsing (what is it anyway? Markdown?). Basically I just added type to the host/ip/port list of matching criteria. It works, but is it ideal? I don’t know enough about SSH to understand whether it makes sense to request the public key type you want explicitly.

What’s the official word on this Jamis? You’ve been strangely silent on the substantive comments here. Is a fixed version forthcoming?

In other bugs: a blank line in known_hosts will result in an attempted nil.split.

19 May 2007

16. Remco said...

Regarding the broken known_hosts file, you could replace line 88 in in host-key-verifier.rb:

host, type, key = line.chomp.split

with:

_, host, type, key = line.chomp.match(/([ ]) ([^ ])
([^ ])$/)

This doesn’t fix the RSA/DSA problem Gabe writes about.

17. Remco said...

Grrr blackbox markup..

17 Jun 2007

18. Werner Ramaekers said...

I had the same error and tried to fix it by edting the known_hosts file but that didn’t work. However , the following solution fixes the problem : do a ‘cap setup ssh_keys’ after having set the ssh_options in your deploy.rb to : ‘ssh_options[:keys] = %w(/Users/@yourname/.ssh/id_rsa) #id rsa_pub’