From Paul.Thompson at Mullen.com Wed Nov 1 11:29:20 2006 From: Paul.Thompson at Mullen.com (Paul Thompson) Date: Wed, 1 Nov 2006 14:29:20 -0500 Subject: [paramiko] Setup Instructions In-Reply-To: Message-ID: Hello, I am looking for a set of instructions on how to properly configure Paramiko. I have the latest Pycrypto and Paramiko downloads, and I have them moved to where they need to be, but I really don't know what to do in terms of setup. We are running Paramiko on another box - but we are moving that site and I need to configure the cron to use Paramiko and the person who initially did the setup is gone. Thanks, Paul -----Original Message----- From: paramiko-bounces at lag.net [mailto:paramiko-bounces at lag.net] On Behalf Of paramiko-request at lag.net Sent: Wednesday, November 01, 2006 2:25 PM To: Paul Thompson Subject: Welcome to the "paramiko" mailing list Welcome to the paramiko at lag.net mailing list! To post to this list, send your email to: paramiko at lag.net General information about the mailing list is at: http://www.lag.net/mailman/listinfo/paramiko If you ever want to unsubscribe or change your options (eg, switch to or from digest mode, change your password, etc.), visit your subscription page at: http://www.lag.net/mailman/options/paramiko/paul.thompson%40mullen.com You can also make such adjustments via email by sending a message to: paramiko-request at lag.net with the word `help' in the subject or body (don't include the quotes), and you will get back a message with instructions. You must know your password to change your options (including changing the password, itself) or to unsubscribe. It is: median Normally, Mailman will remind you of your lag.net mailing list passwords once every month, although you can disable this if you prefer. This reminder will also include instructions on how to unsubscribe or change your account options. There is also a button on your options page that will email your current password to you. From robey at lag.net Fri Nov 3 11:11:17 2006 From: robey at lag.net (Robey Pointer) Date: Fri, 3 Nov 2006 11:11:17 -0800 Subject: [paramiko] Exception from paramiko. EOFError In-Reply-To: <20061029231505.87707.qmail@web35804.mail.mud.yahoo.com> References: <20061029231505.87707.qmail@web35804.mail.mud.yahoo.com> Message-ID: On 29 Oct 2006, at 15:15, jdsw wrote: > Hi > I was getting None from open_channel at few places... and found > that transport.active was becoming false. (related to gnome-vfs. I > do not know the exact cause.. anyone ?) > > After digging and putting print statements... found the following. > Basically in run() method of paramiko transport.py , there was a > socket exception being thrown with Error 11 Resource Temporarily > unavailable. Looking in to doc.. found that clients need to retry > the operations and handle EAGAIN from socket. > > Added retry block around the recv where the problem was. We > might have to wrap this while sending too. > > Attached is section of patched transport.py file. Could u please > validate and see how this can be encorporated in to mainline. > (currently we have released this modification with our product > XenMan and telling users to patch it.). I checked 1.6.2 also, this > section of the code is not changed. I checked in a slightly different version of the patch to Packetizer in change 409 -- does that solve the problem? (It's catching EAGAIN, just at a lower level.) robey From robey at lag.net Fri Nov 3 11:15:16 2006 From: robey at lag.net (Robey Pointer) Date: Fri, 3 Nov 2006 11:15:16 -0800 Subject: [paramiko] Setup Instructions In-Reply-To: References: Message-ID: <5C9B3BAA-9EC0-4497-AA31-E9AA0AC11884@lag.net> On 1 Nov 2006, at 11:29, Paul Thompson wrote: > Hello, > > I am looking for a set of instructions on how to properly configure > Paramiko. I have the latest Pycrypto and Paramiko downloads, and I > have > them moved to where they need to be, but I really don't know what > to do > in terms of setup. > > We are running Paramiko on another box - but we are moving that > site and > I need to configure the cron to use Paramiko and the person who > initially did the setup is gone. The setup shouldn't be anything more than (as root) 'python ./ setup.py install'. Any other configuration is probably specific to your application. robey From robey at lag.net Sat Nov 4 14:28:24 2006 From: robey at lag.net (Robey Pointer) Date: Sat, 4 Nov 2006 14:28:24 -0800 Subject: [paramiko] SSHClient and timeouts In-Reply-To: <3237e4410610131204g7787b59bi76e4f8159dbc3cfb@mail.gmail.com> References: <3237e4410610090745j39362a1bx4f5dda64ae72c4bb@mail.gmail.com> <09296D74-6C12-442B-B84B-776A7921BF0D@lag.net> <3237e4410610131204g7787b59bi76e4f8159dbc3cfb@mail.gmail.com> Message-ID: <0DBDD282-DEDF-4684-AFBF-476B241B3904@lag.net> On 13 Oct 2006, at 12:04, Mike McGrath wrote: > On 10/13/06, Robey Pointer wrote: >> >> On 9 Oct 2006, at 7:45, Mike McGrath wrote: >> >> > Is there any way to set a timeout while using SSHClient? >> >> If you're using invoke_shell(), the returned object is a Channel, so >> you can call set_timeout() on it. >> >> If you're using exec_command(), it's less obvious: The returned file >> objects have a "channel" attribute that you can use to access the >> underlying channel, and set a timeout that way. > > so we're looking at something similar to: > > stdin, stdout, stderr = session.exec_command('blah") > stdin.timeout(5) > stdout.timeout(5) > stderr.timeout(5) Yes. The exact code would look like this: stdin, stdout, stderr = session.exec_command('blah') stdin.channel.settimeout(5) stdout.channel.settimeout(5) stderr.channel.settimeout(5) robey From robey at lag.net Sat Nov 4 16:10:02 2006 From: robey at lag.net (Robey Pointer) Date: Sat, 4 Nov 2006 16:10:02 -0800 Subject: [paramiko] XenMan provides remote node management using Paramiko In-Reply-To: References: <20061011002156.72245.qmail@web35813.mail.mud.yahoo.com> Message-ID: <1D81F8FA-5D36-4F16-BFB5-A67075257C71@lag.net> On 16 Oct 2006, at 15:09, Dag Wieers wrote: > On Fri, 13 Oct 2006, Robey Pointer wrote: > >> On 10 Oct 2006, at 17:21, jdsw wrote: >> >>> This just to another feather in the paramiko cap. Robey, many >>> thanks for useful library. We just released XenMan 0.5 a Xen >>> Management tool. It uses paramiko to >>> a) tunnel to remote machine >>> b) remote file operations >>> >>> Anyone interested, check out >>> http://xenman.sf.net >>> >>> A suggestion : >>> It is not very easy to get paramiko/pycrypto working on various >>> platforms. Urls to RPMS for different platforms on paramiko site >>> would really help. >> >> Nice! >> >> For RPMs: If I built rpms using the distutils "./setup.py" command, >> would that be sufficient? Do Redhat, Suse, etc use different >> variations of RPM? (I'm a debian/ubuntu user.) :) > > Maybe you can link to: > > http://dag.wieers.com/packages/python-paramiko/ > http://dries.studentenweb.org/rpm/packages/python-paramiko/info.html > > For all that is Fedora and Red Hat Enterprise Linux. Thanks! I added them. robey From manpreetsk at gmail.com Mon Nov 6 03:28:37 2006 From: manpreetsk at gmail.com (Manpreet Singh Khurana) Date: Mon, 6 Nov 2006 16:58:37 +0530 Subject: [paramiko] can we send encrypted password in connect() Message-ID: Hi, i have been using paramiko for a while and just upgraded with latest 1.6.3. I have a installation script which takes username and password from the user and stores in clear text in the .cfg file. Now this username and clear text password in .cfg file is given as input to my python application which establishes connection to the server. Now i want this password to be encrypted in .cfg file. how can we do this thru paramiko. Do we have api which takes clear text password and ssh public key as input and generate a encryted password. from it? Can paramiko then can use this encryted password as one of the parameter in connect() api and do the authentication or is there anyother way to do this. Can somebody suggest exact steps to do this. (I mean steps like if i have username and password then what all steps we need to ssh the server using encrypted pasword) please advice. Regards Manpreet From nlv11281 at natlab.research.philips.com Mon Nov 6 22:38:14 2006 From: nlv11281 at natlab.research.philips.com (Mike Looijmans) Date: Tue, 07 Nov 2006 07:38:14 +0100 Subject: [paramiko] can we send encrypted password in connect() In-Reply-To: References: Message-ID: <455029D6.1070600@natlab.research.philips.com> The nice thing with SSH (and paramiko) is that you don't need the password. Never. The private key file is all you need to communicate with other machines. The public key must be added to the authorized_keys file. Mike Looijmans Philips Natlab / Topic Automation Manpreet Singh Khurana wrote: > Hi, > i have been using paramiko for a while and just upgraded with latest 1.6.3. > I have a installation script which takes username and password from > the user and stores in clear text in the .cfg file. Now this username > and clear text password in .cfg file is given as input to my python > application which establishes connection to the server. > > Now i want this password to be encrypted in .cfg file. > > how can we do this thru paramiko. > > Do we have api which takes clear text password and ssh public key as > input and generate a encryted password. from it? > > Can paramiko then can use this encryted password as one of the > parameter in connect() api and do the authentication or is there > anyother way to do this. > > Can somebody suggest exact steps to do this. > (I mean steps like if i have username and password then what all steps > we need to ssh the server using encrypted pasword) > > please advice. > > Regards > Manpreet > > _______________________________________________ > paramiko mailing list > paramiko at lag.net > http://www.lag.net/mailman/listinfo/paramiko > From manpreetsk at gmail.com Tue Nov 7 02:22:58 2006 From: manpreetsk at gmail.com (Manpreet Singh Khurana) Date: Tue, 7 Nov 2006 15:52:58 +0530 Subject: [paramiko] can we send encrypted password in connect() In-Reply-To: <455029D6.1070600@natlab.research.philips.com> References: <455029D6.1070600@natlab.research.philips.com> Message-ID: Can you please advice me which API in paramiko class should i use to achieve this! Manpreet On 11/7/06, Mike Looijmans wrote: > The nice thing with SSH (and paramiko) is that you don't need the password. Never. The private key > file is all you need to communicate with other machines. The public key must be added to the > authorized_keys file. > > > Mike Looijmans > Philips Natlab / Topic Automation > > > Manpreet Singh Khurana wrote: > > Hi, > > i have been using paramiko for a while and just upgraded with latest 1.6.3. > > I have a installation script which takes username and password from > > the user and stores in clear text in the .cfg file. Now this username > > and clear text password in .cfg file is given as input to my python > > application which establishes connection to the server. > > > > Now i want this password to be encrypted in .cfg file. > > > > how can we do this thru paramiko. > > > > Do we have api which takes clear text password and ssh public key as > > input and generate a encryted password. from it? > > > > Can paramiko then can use this encryted password as one of the > > parameter in connect() api and do the authentication or is there > > anyother way to do this. > > > > Can somebody suggest exact steps to do this. > > (I mean steps like if i have username and password then what all steps > > we need to ssh the server using encrypted pasword) > > > > please advice. > > > > Regards > > Manpreet > > > > _______________________________________________ > > paramiko mailing list > > paramiko at lag.net > > http://www.lag.net/mailman/listinfo/paramiko > > > > From david at guerizec.net Tue Nov 7 03:16:24 2006 From: david at guerizec.net (David Guerizec) Date: Tue, 7 Nov 2006 12:16:24 +0100 Subject: [paramiko] can we send encrypted password in connect() In-Reply-To: References: <455029D6.1070600@natlab.research.philips.com> Message-ID: <200611071216.24406.david@guerizec.net> Le mardi 07 novembre 2006 11:22, Manpreet Singh Khurana a ?crit?: > Can you please advice me which API in paramiko class should i use to > achieve this! Basically, you have to use Transport.connect(), which handles a lot of things for you: http://www.lag.net/paramiko/docs/paramiko.Transport-class.html#connect To get a PKey object, you can instanciate it from a string: pkey = paramiko.DSSKey(data=private_key_string) or from a file: pkey = paramiko.DSSKey(filename=private_key_file) Best regards, David -- http://penguin.fr/sshproxy/ "An ACL-driven proxy on SSH2" From david at guerizec.net Fri Nov 10 19:19:30 2006 From: david at guerizec.net (David Guerizec) Date: Sat, 11 Nov 2006 04:19:30 +0100 Subject: [paramiko] patch for x11, local and remote forwarding Message-ID: <200611110419.30902.david@guerizec.net> Hello, Replacing my previous patch to implement x11 forwarding, here is a new one with a better implementation (hopefully) that handles both x11 forwarding, local port forwarding and remote port forwarding. Since I'm working on a proxy, both client and server side have been tested. Regards, David -- http://penguin.fr/sshproxy/ "An ACL-driven proxy on SSH2" From david at guerizec.net Fri Nov 10 19:21:59 2006 From: david at guerizec.net (David Guerizec) Date: Sat, 11 Nov 2006 04:21:59 +0100 Subject: [paramiko] patch for x11, local and remote forwarding In-Reply-To: <200611110419.30902.david@guerizec.net> References: <200611110419.30902.david@guerizec.net> Message-ID: <200611110421.59179.david@guerizec.net> Oops, sorry, it's better with the attachment... David On Saturday 11 November 2006 04:19, David Guerizec wrote: > Hello, > > Replacing my previous patch to implement x11 forwarding, here is a new one > with a better implementation (hopefully) that handles both x11 forwarding, > local port forwarding and remote port forwarding. > > Since I'm working on a proxy, both client and server side have been tested. > > Regards, > > David -- http://penguin.fr/sshproxy/ "An ACL-driven proxy on SSH2" -------------- next part -------------- A non-text attachment was scrubbed... Name: paramiko-forwarding.patch Type: text/x-diff Size: 16449 bytes Desc: not available Url : http://www.lag.net/pipermail/paramiko/attachments/20061111/28b5312d/attachment.bin From robey at lag.net Tue Nov 14 17:55:55 2006 From: robey at lag.net (Robey Pointer) Date: Tue, 14 Nov 2006 17:55:55 -0800 Subject: [paramiko] patch for x11, local and remote forwarding In-Reply-To: <200611110421.59179.david@guerizec.net> References: <200611110419.30902.david@guerizec.net> <200611110421.59179.david@guerizec.net> Message-ID: <90D7B6A2-A0B1-424E-8CBA-BF4A5AC40425@lag.net> On 10 Nov 2006, at 19:21, David Guerizec wrote: > Oops, sorry, it's better with the attachment... > > David > > On Saturday 11 November 2006 04:19, David Guerizec wrote: >> Hello, >> >> Replacing my previous patch to implement x11 forwarding, here is a >> new one >> with a better implementation (hopefully) that handles both x11 >> forwarding, >> local port forwarding and remote port forwarding. >> >> Since I'm working on a proxy, both client and server side have >> been tested. Sorry for the delay in replying. I like the patch, and will probably use a variant of it. (I think I'd like to allow the x11 handler like you have, but also have the default behavior be to queue up x11 connections in accept() just like it does in server mode.) The main thing I need to do is add unit tests. Since I'm hoping to do a bugfix release tomorrow for 1.6.4, this will probably have to wait for version 1.7. Hopefully not far off. :) Anyway just wanted you to know that I've been working on this in the small bits of free time I have, so it's not being ignored, I just need to figure out a good way to test it. robey From david at guerizec.net Fri Nov 17 02:39:36 2006 From: david at guerizec.net (David Guerizec) Date: Fri, 17 Nov 2006 11:39:36 +0100 Subject: [paramiko] patch for x11, local and remote forwarding In-Reply-To: <90D7B6A2-A0B1-424E-8CBA-BF4A5AC40425@lag.net> References: <200611110419.30902.david@guerizec.net> <200611110421.59179.david@guerizec.net> <90D7B6A2-A0B1-424E-8CBA-BF4A5AC40425@lag.net> Message-ID: <200611171139.36369.david@guerizec.net> > I like the patch, and will probably use a variant of it. (I think > I'd like to allow the x11 handler like you have, but also have the > default behavior be to queue up x11 connections in accept() just like > it does in server mode.) Does this mean the API will stay the same, besides the accept() addition ? This is actually my main concern, since I need to deploy several instances of sshproxy on a customer's servers in a few days and I'd prefer not to do it again a few days later. Best regards, David -- http://penguin.fr/sshproxy/ "An ACL-driven proxy on SSH2" From david at guerizec.net Sun Nov 19 05:47:58 2006 From: david at guerizec.net (David Guerizec) Date: Sun, 19 Nov 2006 14:47:58 +0100 Subject: [paramiko] Paramiko's leaking file descriptors Message-ID: <200611191447.58584.david@guerizec.net> Hello, I've been trying to optimize file descriptors utilisation in sshproxy, and I found that paramiko is leaking file descriptors when using Channel.fileno() method. What is happening is when calling fileno(), a pipe object is created, using 2 file descriptors, but when a channel is closed by the remote side (that is not explicitly by calling Channel.close()), the pipe's FDs are not closed but the paramiko Pipe object is doing like so, by setting self._forever. I've made a patch (attached to this message) to close these file descriptors when the Pipe.set_forever() method is called, and that seems to fix my problem. Regards, David -- http://penguin.fr/sshproxy/ "An ACL-driven proxy on SSH2" -------------- next part -------------- A non-text attachment was scrubbed... Name: paramiko_pipe.patch Type: text/x-diff Size: 716 bytes Desc: not available Url : http://www.lag.net/pipermail/paramiko/attachments/20061119/d85feb4e/attachment.bin From robey at lag.net Sun Nov 19 15:01:48 2006 From: robey at lag.net (Robey Pointer) Date: Sun, 19 Nov 2006 15:01:48 -0800 Subject: [paramiko] release: paramiko 1.6.4 Message-ID: <710DBB57-8EBA-4ABB-87D4-9AA698291473@lag.net> Paramiko 1.6.4 is now released: http://www.lag.net/paramiko/ This is just a bugfix release, with no new features. v1.6.4 YANMA * fix setup.py on osx (oops!) * (bug 69330) check for the existence of RSA/DSA keys before trying to open them in SFTPClient * (bug 69222) catch EAGAIN in socket code to workaround a bug in recent Linux 2.6 kernels * (bug 70398) improve dict emulation in HostKeys objects * try harder to make sure all worker threads are joined on Transport.close() There aren't any pok?mon in the original pantheon that start with "y", just like there weren't any "x"s. The yanma is some kind of odd dragonfly-looking thing. It can see in 360 degrees, so it's nearly impossible to sneak up on, should you stumble across one while biking. robey From robey at lag.net Mon Nov 20 11:21:55 2006 From: robey at lag.net (Robey Pointer) Date: Mon, 20 Nov 2006 11:21:55 -0800 Subject: [paramiko] Paramiko's leaking file descriptors In-Reply-To: <200611191447.58584.david@guerizec.net> References: <200611191447.58584.david@guerizec.net> Message-ID: <04617D8B-9AAF-48E3-BA96-CA1A3B4B757E@lag.net> On 19 Nov 2006, at 5:47, David Guerizec wrote: > Hello, > > I've been trying to optimize file descriptors utilisation in > sshproxy, and I > found that paramiko is leaking file descriptors when using > Channel.fileno() > method. > > What is happening is when calling fileno(), a pipe object is > created, using 2 > file descriptors, but when a channel is closed by the remote side > (that is > not explicitly by calling Channel.close()), the pipe's FDs are not > closed but > the paramiko Pipe object is doing like so, by setting self._forever. > > I've made a patch (attached to this message) to close these file > descriptors > when the Pipe.set_forever() method is called, and that seems to fix my > problem. I think I see the underlying bug: when the remote host closes a channel first, the section of close() that closes the pipe is never reached. (close() is always called eventually, since it's invoked by __del__.) I've re-ordered the close() sequence in change 416 -- does that fix it? robey From david at guerizec.net Mon Nov 20 13:56:52 2006 From: david at guerizec.net (David Guerizec) Date: Mon, 20 Nov 2006 22:56:52 +0100 Subject: [paramiko] Paramiko's leaking file descriptors In-Reply-To: <04617D8B-9AAF-48E3-BA96-CA1A3B4B757E@lag.net> References: <200611191447.58584.david@guerizec.net> <04617D8B-9AAF-48E3-BA96-CA1A3B4B757E@lag.net> Message-ID: <200611202256.53036.david@guerizec.net> On Monday 20 November 2006 20:21, Robey Pointer wrote: > I think I see the underlying bug: when the remote host closes a > channel first, the section of close() that closes the pipe is never > reached. (close() is always called eventually, since it's invoked by > __del__.) I've re-ordered the close() sequence in change 416 -- does > that fix it? Yes, that fixed it, thanks! Regards, David -- http://penguin.fr/sshproxy/ "An ACL-driven proxy on SSH2" From paramiko at gptech.com.au Wed Nov 22 22:36:55 2006 From: paramiko at gptech.com.au (David Mason) Date: Thu, 23 Nov 2006 17:36:55 +1100 Subject: [paramiko] bad file descriptor Message-ID: <45654187.1040203@gptech.com.au> Hi list, I've been getting an error when using SFTPClient from an SSHClient object, and then closing these objects. Here is a sample run through the interactive shell including DEBUG level logging... Python 2.4.3 (#2, Oct 6 2006, 07:52:30) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import logging >>> from paramiko import AutoAddPolicy, SSHClient >>> logging.basicConfig(level=logging.DEBUG) >>> ssh = SSHClient() >>> ssh.set_missing_host_key_policy(AutoAddPolicy()) >>> ssh.connect('192.168.0.1', username='username', key_filename='private.key') DEBUG:paramiko.transport:starting thread (client mode): 0xB7DE76ECL INFO:paramiko.transport:Connected (version 2.0, client OpenSSH_4.2p1) DEBUG:paramiko.transport:kex algos:['diffie-hellman-group-exchange-sha1', 'diffie-hellman-group14-sha1', 'diffie-hellman-group1-sha1'] server key:['ssh-dss'] client encrypt:['aes128-cbc', '3des-cbc', 'blowfish-cbc', 'cast128-cbc', 'arcfour128', 'arcfour256', 'arcfour', 'aes192-cbc', 'aes256-cbc', 'rijndael-cbc at lysator.liu.se', 'aes128-ctr', 'aes192-ctr', 'aes256-ctr'] server encrypt:['aes128-cbc', '3des-cbc', 'blowfish-cbc', 'cast128-cbc', 'arcfour128', 'arcfour256', 'arcfour', 'aes192-cbc', 'aes256-cbc', 'rijndael-cbc at lysator.liu.se', 'aes128-ctr', 'aes192-ctr', 'aes256-ctr'] client mac:['hmac-md5', 'hmac-sha1', 'hmac-ripemd160', 'hmac-ripemd160 at openssh.com', 'hmac-sha1-96', 'hmac-md5-96'] server mac:['hmac-md5', 'hmac-sha1', 'hmac-ripemd160', 'hmac-ripemd160 at openssh.com', 'hmac-sha1-96', 'hmac-md5-96'] client compress:['none', 'zlib at openssh.com'] server compress:['none', 'zlib at openssh.com'] client lang:[''] server lang:[''] kex follows?False DEBUG:paramiko.transport:Ciphers agreed: local=aes128-cbc, remote=aes128-cbc DEBUG:paramiko.transport:using kex diffie-hellman-group1-sha1; server key type ssh-dss; cipher: local aes128-cbc, remote aes128-cbc; mac: local hmac-sha1, remote hmac-sha1; compression: local none, remote none DEBUG:paramiko.transport:Switch to new keys ... DEBUG:paramiko.transport:Adding ssh-dss host key for 192.168.0.1: df5ef7d8e83ca84522f27cb2836f4491 DEBUG:paramiko.transport:Trying key 1d164cbb9627aa786714ab1d003d0bfe from private.key DEBUG:paramiko.transport:userauth is OK INFO:paramiko.transport:Authentication (publickey) successful! >>> sftp = ssh.open_sftp() DEBUG:paramiko.transport.1:Max packet in: 34816 bytes DEBUG:paramiko.transport.1:Max packet out: 32768 bytes INFO:paramiko.transport:Secsh channel 1 opened. DEBUG:paramiko.transport.1:Sesch channel 1 request ok INFO:paramiko.transport.1.sftp:Opened sftp connection (server version 3) >>> sftp.close() INFO:paramiko.transport.1.sftp:sftp session closed. DEBUG:paramiko.transport.1:EOF sent >>> sftp = None >>> ssh.close() ERROR:paramiko.transport:Socket exception: Bad file descriptor (9) >>> ssh = None >>> There is an ERROR on the ssh.close() line "Bad file descriptor (9)". Is this a bug that I've hit, or am I not using the library correctly? I'm using paramiko version 1.6.4, on Ubuntu dapper. Cheers, David Mason From paramiko at gptech.com.au Thu Nov 23 15:42:02 2006 From: paramiko at gptech.com.au (David Mason) Date: Fri, 24 Nov 2006 10:42:02 +1100 Subject: [paramiko] bad file descriptor - patch included Message-ID: <456631CA.3040503@gptech.com.au> Hi again, Yesterday I asked about a "bad file descriptor" error that was coming up as I was closing the SSH connection. After some digging I determined that it was happening due to the thread not picking up that it is inactive until some time after the sockets are closed. I've fixed this by making the close method in Transport wait for the thread to terminate *before* it closes the open connection. I've attached a patch that fixes this behaviour (text of patch is also listed below). Cheers, David Mason --- paramiko/transport.py 2006-11-24 10:32:59.000000000 +1100 +++ paramiko/transport.py 2006-11-24 10:33:33.000000000 +1100 @@ -546,10 +546,10 @@ if not self.active: return self.active = False + self.join() self.packetizer.close() for chan in self.channels.values(): chan._unlink() - self.join() def get_remote_server_key(self): """ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: thread_terminate.diff Url: http://www.lag.net/pipermail/paramiko/attachments/20061124/d8435cc0/attachment.diff From robey at lag.net Mon Nov 27 11:19:56 2006 From: robey at lag.net (Robey Pointer) Date: Mon, 27 Nov 2006 11:19:56 -0800 Subject: [paramiko] bad file descriptor - patch included In-Reply-To: <456631CA.3040503@gptech.com.au> References: <456631CA.3040503@gptech.com.au> Message-ID: On 23 Nov 2006, at 15:42, David Mason wrote: > Hi again, > > Yesterday I asked about a "bad file descriptor" error that was > coming up as I was closing the SSH connection. After some digging > I determined that it was happening due to the thread not picking up > that it is inactive until some time after the sockets are closed. > I've fixed this by making the close method in Transport wait for > the thread to terminate *before* it closes the open connection. > I've attached a patch that fixes this behaviour (text of patch is > also listed below). Joining the thread before the packetizer is closed may cause the packetizer to never realize that it should stop, though. (The unit tests break for this reason -- good demonstration of why they're actually useful!) :) I think a better fix would be to notice when a socket.error happens because of EOF, and translate the exception. Patch below -- does this fix it for you too? robey === modified file 'paramiko/packet.py' --- paramiko/packet.py 2006-11-12 06:30:54 +0000 +++ paramiko/packet.py 2006-11-27 19:13:31 +0000 @@ -218,6 +218,8 @@ # we need to work around it. if (type(e.args) is tuple) and (len(e.args) > 0) and (e.args[0] == errno.EAGAIN): got_timeout = True + elif self.__closed: + raise EOFError() else: raise if got_timeout: From pmezard at gmail.com Mon Nov 27 12:33:50 2006 From: pmezard at gmail.com (=?ISO-8859-1?Q?Patrick_M=E9zard?=) Date: Mon, 27 Nov 2006 21:33:50 +0100 Subject: [paramiko] Paramiko and win-ssh-agent Message-ID: <456B4BAE.1070301@gmail.com> Hello, I had to use paramiko in combination with win-ssh-agent (), which is thin wrapper for cygwin ssh-agent. Patch is attached. Basically, I wrote something compatible with cygwin unix domain sockets and patch it in the existing paramiko.Agent implementation. It works for me so... I think the implementation has the following drawbacks: - completely tied to cygwin unix socket implementation. I think this is OK, the handshake protocol have been stable for at least a year. - cygwin module reads cygwin /etc/passwd at load time to get user id and group id. I assumed people have the permissions to read this, probably OK, at least in a cygwin context. - cygwin root directory is read from PARAMIKO_CYGPATH. It could probably be done in smarter ways, but it works and is simple. Good enough for now, will not be hard to improve if necessary. Hope this helps, Patrick M?zard -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: win-ssh-agent.diff Url: http://www.lag.net/pipermail/paramiko/attachments/20061127/9a763509/attachment.diff From paramiko at gptech.com.au Mon Nov 27 18:07:54 2006 From: paramiko at gptech.com.au (David Mason) Date: Tue, 28 Nov 2006 13:07:54 +1100 Subject: [paramiko] bad file descriptor - patch included In-Reply-To: References: <456631CA.3040503@gptech.com.au> Message-ID: <456B99FA.9060600@gptech.com.au> Hi there, The patch you provided works great, thanks! David Mason Robey Pointer wrote: > On 23 Nov 2006, at 15:42, David Mason wrote: > > >> Hi again, >> >> Yesterday I asked about a "bad file descriptor" error that was >> coming up as I was closing the SSH connection. After some digging >> I determined that it was happening due to the thread not picking up >> that it is inactive until some time after the sockets are closed. >> I've fixed this by making the close method in Transport wait for >> the thread to terminate *before* it closes the open connection. >> I've attached a patch that fixes this behaviour (text of patch is >> also listed below). >> > > Joining the thread before the packetizer is closed may cause the > packetizer to never realize that it should stop, though. (The unit > tests break for this reason -- good demonstration of why they're > actually useful!) :) > > I think a better fix would be to notice when a socket.error happens > because of EOF, and translate the exception. Patch below -- does > this fix it for you too? > > robey > > > === modified file 'paramiko/packet.py' > --- paramiko/packet.py 2006-11-12 06:30:54 +0000 > +++ paramiko/packet.py 2006-11-27 19:13:31 +0000 > @@ -218,6 +218,8 @@ > # we need to work around it. > if (type(e.args) is tuple) and (len(e.args) > 0) > and (e.args[0] == errno.EAGAIN): > got_timeout = True > + elif self.__closed: > + raise EOFError() > else: > raise > if got_timeout: > > > _______________________________________________ > paramiko mailing list > paramiko at lag.net > http://www.lag.net/mailman/listinfo/paramiko > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.lag.net/pipermail/paramiko/attachments/20061128/01aa6d6c/attachment.htm