Version 0.0.2 brings the implementation to full compliance with the SSH2 protocol, since you can now use ssh-dss key types.
The most significant new feature is a limited implementation of the SFTP protocol. Only a subset of the features of SFTP are implemented, namely directory enumeration, and getting and storing files. More features are coming.
The SSH protocol itself is asynchronous, so the "core" implementation of the SFTP protocol (Net::SSH::SFTP::Session) is also asynchronous. However, a synchronous version (useful when you don't need multiple channels open simultaneously) is also available (Net::SSH::SFTP::Simple).
Until Ruby 1.8.2 is released, you need to also install the patched version of the OpenSSL module for Ruby (also available from the Net::SSH site). Ruby 1.8.2 will include the patched version of OpenSSL, though, so once you have installed you'll need nothing else to run Net::SSH.
If you have specific features you would like Net::SSH to have, be sure to submit a feature request!
If you have specific features you would like Net::SSH to have, be sure to submit a feature request!
It would be nice if key authentication using Putty Agent (on Windows) would be supported. On Unix you can specify your keys in ~/.ssh so maybe that already works, I don't know how Putty Agent does it's job...
Version 0.0.2 brings the implementation to full compliance with the SSH2 protocol, since you can now use ssh-dss key types.
The most significant new feature is a limited implementation of the SFTP protocol. Only a subset of the features of SFTP are implemented, namely directory enumeration, and getting and storing files. More features are coming.
The SSH protocol itself is asynchronous, so the "core" implementation of the SFTP protocol (Net::SSH::SFTP::Session) is also asynchronous. However, a synchronous version (useful when you don't need multiple channels open simultaneously) is also available (Net::SSH::SFTP::Simple).
Until Ruby 1.8.2 is released, you need to also install the patched version of the OpenSSL module for Ruby (also available from the Net::SSH site). Ruby 1.8.2 will include the patched version of OpenSSL, though, so once you have installed you'll need nothing else to run Net::SSH.
If you have specific features you would like Net::SSH to have, be sure to submit a feature request!
Thanks for working on this!!!
IMHO, Ruby's built-in support for OpenSSL and secure protocols is one of the most important features (security has become a high-priority in most places now).
Can we start doing SSH tunneling with Ruby 1.8.2 or do we have to wait for that feature to be implemented?
Version 0.0.2 brings the implementation to full compliance with the SSH2 protocol, since you can now use ssh-dss key types.
The most significant new feature is a limited implementation of the SFTP protocol. Only a subset of the features of SFTP are implemented, namely directory enumeration, and getting and storing files. More features are coming.
The SSH protocol itself is asynchronous, so the "core" implementation of the SFTP protocol (Net::SSH::SFTP::Session) is also asynchronous. However, a synchronous version (useful when you don't need multiple channels open simultaneously) is also available (Net::SSH::SFTP::Simple).
Until Ruby 1.8.2 is released, you need to also install the patched version of the OpenSSL module for Ruby (also available from the Net::SSH site). Ruby 1.8.2 will include the patched version of OpenSSL, though, so once you have installed you'll need nothing else to run Net::SSH.
If you have specific features you would like Net::SSH to have, be sure to submit a feature request!
It would be nice if key authentication using Putty Agent (on Windows) would be supported. On Unix you can specify your keys in ~/.ssh so maybe that already works, I don't know how Putty Agent does it's job...
Good point. However, I believe the putty utilities all know to look at the putty agent for the keys... If it's not too much effort, I could try to make Net::SSH do the same, on windows. I'll look into it.
Can we start doing SSH tunneling with Ruby 1.8.2 or do we have to wait for that feature to be implemented?
Tunneling is not yet implemented, and I've been debating its usefulness in the Net::SSH module. Since it sounds like you would like this feature, how would *you* use it, if it were available? Can you provide a few use cases?
Do I need to use your patched version of OpenSSL module with the latest snapshot of Ruby 1.9?
Cheers,
Kent.
Good question. I'm not familiar with the work being done on 1.9, so I have no idea if the patch I submitted made it to 1.9. It may have. I know it made it into 1.8.2.
It would be nice if key authentication using Putty Agent (on Windows) would be supported. On Unix you can specify your keys in ~/.ssh so maybe that already works, I don't know how Putty Agent does it's job...
Good point. However, I believe the putty utilities all know to look at the putty agent for the keys... If it's not too much effort, I could try to make Net::SSH do the same, on windows. I'll look into it.
K. I looked at it, and it's going to require a lot of work to support. However, it's work that ought to be done anyway. For the public/private key stuff, I'm currently grabbing the keys myself. I ought to be looking for an active SSH agent and, if one exists, using the keys it provides.
Thanks again for bringing this to my attention. One more thing to throw on my todo list.
Can we start doing SSH tunneling with Ruby 1.8.2 or do we have to wait for that feature to be implemented?
Tunneling is not yet implemented, and I've been debating its usefulness in the Net::SSH module. Since it sounds like you would like this feature, how would *you* use it, if it were available? Can you provide a few use cases?
Thanks!
- Jamis
The most common use for ssh tunneling for me at the moment:
1. accessing hosted mysql/postgresql server (ssl protocol feature not always available on hosted servers and secure protocol not always available on mysql client programs)
2. accessing webmin on hosted server (http://localhost:10000/\) - one of my hosting companies blocks ports > 1024
3. accessing email on a remote server - I block pop3 to every ip except localhost - no need for ssl/tls etc. when I ssh tunnel pop3.
4. and finally, accessing custom ports on remote server. many hosting companies block all ports except http so this allows me to use any custom port without depending on them to open it up for me (i just localhost:4567 instead of waiting hours/days to have mydomain.com:4567 opened up for me)
Basically, my iptables firewall blocks all ports except ssh, http(s) and smtp. I then use ssh tunneling for everything else and it works like a charm.
In terms of using ssh tunneling with ruby scripts, the most common use for me would be accessing remote database servers or distributed ruby objects securely without messing with firewall rules (because ssh port is already open).
Your one-liner gives me the 'true' which makes me think that I have the correct environment for experimentations with your library. The reason why I asked my first question was that when I run one of scripts in the examples directory, I get this stack trace:
$ ruby channel-demo.rb
../lib/net/ssh/transport/cipher.rb:57:in `padding=': cannot convert false into Integer (TypeError)
from ../lib/net/ssh/transport/cipher.rb:57:in `get'
from ../lib/net/ssh/transport/session.rb:282:in `exchange_keys'
from ../lib/net/ssh/transport/session.rb:109:in `initialize'
from ../lib/net/ssh.rb:118:in `new'
from ../lib/net/ssh.rb:118:in `open'
from ../lib/net/ssh.rb:80:in `start'
from channel-demo_1.rb:33
Cheers,
Kent.
Kent Sibilev wrote:
Jemis,
Do I need to use your patched version of OpenSSL module with the latest snapshot of Ruby 1.9?
Cheers,
Kent.
···
On Jul 5, 2004, at 9:53 PM, Jamis Buck wrote:
Good question. I'm not familiar with the work being done on 1.9, so I have no idea if the patch I submitted made it to 1.9. It may have. I know it made it into 1.8.2.
Tunneling is not yet implemented, and I've been debating its usefulness in the Net::SSH module. Since it sounds like you would like this feature, how would *you* use it, if it were available? Can you provide a few use cases?
...
In terms of using ssh tunneling with ruby scripts, the most common use for me would be accessing remote database servers or distributed ruby objects securely without messing with firewall rules (because ssh port is already open).
In message <662D98C2-CF0D-11D8-8F8A-000A95C700E8@bellsouth.net>,
Your one-liner gives me the 'true' which makes me think that I have the
correct environment for experimentations with your library. The reason
why I asked my first question was that when I run one of scripts in the
examples directory, I get this stack trace:
$ ruby channel-demo.rb
../lib/net/ssh/transport/cipher.rb:57:in `padding=': cannot convert
false into Integer (TypeError)
from ../lib/net/ssh/transport/cipher.rb:57:in `get'
Sorry. I didn't apply the patch attached to [ruby-talk:103503].
Someone suggested me that patch may break future compatibility.
OpenSSL currently implements one padding mode. But a future
implementation may use numeric constants as an argument to
EVP_CIPHER_CTX_set_padding() to specify the different padding
modes.
Jamis, please do cipher.padding=0 to disable padding mode.
In terms of using ssh tunneling with ruby scripts, the most common use for me would be accessing remote database servers or distributed ruby objects securely without messing with firewall rules (because ssh port is already open).
I'd be interested in using this (for DRb) too.
So, if I understand it correctly, what you (all) would expect to be able to do is something like the following:
Thread.new do
Net::SSH.forward_local( proxy_host,
local_port,
remote_host,
remote_port )
end
Sorry. I didn't apply the patch attached to [ruby-talk:103503].
Someone suggested me that patch may break future compatibility.
OpenSSL currently implements one padding mode. But a future
implementation may use numeric constants as an argument to
EVP_CIPHER_CTX_set_padding() to specify the different padding
modes.
Jamis, please do cipher.padding=0 to disable padding mode.
Will do. Thanks for the clarification.
Until I release 0.0.3, those that are suffering from this bug can just change line 57 of net/ssh/transport/ciper.rb from "cipher.padding = false" to "cipher.padding = 0".
(Just curious, though: the patch WAS applied at one time, right? Either that, or I'm going crazy...)
So, if I understand it correctly, what you (all) would expect to be able to do is something like the following:
Thread.new do
Net::SSH.forward_local( proxy_host,
local_port,
remote_host,
remote_port )
end
do_something_on( 'localhost', local_port )
Is that correct?
Why not just call the method #tunnel?
Of course, whatever looks right from your house is fine by me. Thanks for Net::SSH!
Cheers,
Patrick
Well, the term the SSH docs use is "port forwarding", so if you're familiar with SSH but not Net::SSH, it might be easier to find the functionality if it is called "forward".
Secondly, SSH supports two types of port forwarding: forwarding a local connection to a remote machine, and vice versa (remote connection to local machine). Thus, I see having a "forward_local" method, and a "forward_remote" method. These would correspond (respectively) to the -L and -R options of the OpenSSH "ssh" executable.
However, if anyone has a compelling reason why the naming should be otherwise, please let me know. I'm definately not religious about this.
···
On Monday, July 5, 2004, at 09:32 PM, Jamis Buck wrote:
On Tuesday, July 6, 2004, at 09:30 AM, Jamis Buck wrote:
Why not just call the method #tunnel?
Of course, whatever looks right from your house is fine by me. Thanks for Net::SSH!
Well, the term the SSH docs use is "port forwarding", so if you're familiar with SSH but not Net::SSH, it might be easier to find the functionality if it is called "forward".
Secondly, SSH supports two types of port forwarding: forwarding a local connection to a remote machine, and vice versa (remote connection to local machine). Thus, I see having a "forward_local" method, and a "forward_remote" method. These would correspond (respectively) to the -L and -R options of the OpenSSH "ssh" executable.
Makes sense to me. I mixed up my google search term for the command line options to ssh with the actual ssh options. You're right, #forward_local is better. Thanks for clarifying
On Unix you can specify your keys in ~/.ssh so maybe that already works, I don't know how Putty Agent does it's job...
Let me know what you find out.