From dwayne at oscl.ca Wed Apr 2 10:48:05 2008 From: dwayne at oscl.ca (Dwayne Litzenberger) Date: Wed, 2 Apr 2008 11:48:05 -0600 Subject: [paramiko] [MERGE] non-interoperable NULL cipher support Message-ID: <200804021148.05901.dwayne@oscl.ca> The attached bundle adds the cipher and MAC algorithms "none at lag.net". It is commented out in the code by default, and it does not interoperate with other SSH implementations. I'm using it to try to reproduce the deadlock I'm seeing. -- Dwayne Litzenberger, B.A.Sc. Information Technology Analyst Open Systems Canada Limited #210 - 2332 11th Ave Regina, SK S4P0K1 Office: (306) 359-OSCL (6725) http://www.oscl.ca/ -------------- next part -------------- A non-text attachment was scrubbed... Name: paramiko-nullcipher.bundle Type: text/x-diff Size: 6225 bytes Desc: not available Url : http://www.lag.net/pipermail/paramiko/attachments/20080402/af54e483/attachment.diff From dwayne at oscl.ca Thu Apr 3 15:12:23 2008 From: dwayne at oscl.ca (Dwayne Litzenberger) Date: Thu, 3 Apr 2008 16:12:23 -0600 Subject: [paramiko] paramiko random number regression: Stop using RandomPool! Message-ID: <200804031612.28314.dwayne@oscl.ca> Robey, I have always been impressed by the good judgement expressed in Paramiko's design. Among other things, you have taken a secure-by-default approach, and you have not resorted to bug-prone string manipulations in C in the name of "performance". That being said... Revision #486 [1] (and therefore Paramiko 1.7.3) re-introduces the problems associated with PyCrypto's RandomPool class that I described in my post back in January. RandomPool is not a simple "get random bits" primitive, but paramiko is again using it as one. Please take some time to re-read my post: http://www.lag.net/pipermail/paramiko/2008-January/000599.html Please also read at least the "Introduction and Overview" section of BCP 106 ("Randomness Requirements for Security", currently RFC 4086), if you haven't already done so: http://tools.ietf.org/html/bcp106.html RandomPool is a deterministic PRNG. It is based on the PGP random number generator, which was designed in an era when commonly-used operating systems (e.g. MS DOS) didn't necessarily provide good sources of entropy. RandomPool assumes that its caller/subclass will seed it regularly with entropy collected elsewhere (e.g. from keyboard timings, like KeyboardRandomPool does). It also _tries_ to seed itself from the operating system, just to make things a bit better, if possible, but if it fails to get much entropy on its own, it silently continues as if everything is OK. Paramiko just instantiates RandomPool and continues as if RandomPool were a maintenance-free "get entropy" primitive. To make matters worse, it does not even do so in a thread-safe way. Today, OS-provided entropy sources are common. The operating system is in a better position to prevent disclosure of the RNG state, and it can guarantee that the RNG state won't be duplicated when you create new threads/processes. For this and other reasons, I deliberately removed RandomPool (which runs in user-space) in my patches to fix CVE-2008-0299. Paramiko should refuse to run if it cannot find an entropy source provided by the operating system. I understand that this means that some existing paramiko deployments will break, but that is only because they were insecure in the first place. It is always better for a cryptographic module to return an error than for it to silently run insecurely. This is a very serious bug for Windows users of Paramiko. As I mentioned in my January post, there is a longstanding bug in PyCrypto that causes the native "winrandom" module to not be built. As a result, the only way to get entropy from Windows is to use the os.urandom module (provided in Python 2.4 and later). Unfortunately, when you merged my changes, you removed the call to os.urandom. This error would normally have been detected on systems lacking a winrandom module (i.e. all of them), but since you replaced the call to os.urandom with the instantiation of RandomPool, Paramiko's random number generator simply fails silently. The result is that Paramiko 1.7.3 is totally insecure on Windows, no matter what version of Python is being used. On other operating systems, there is still the RandomPool threading issue. I will be posting a patch shortly. Regards - Dwayne [1] bzr revision-id:robey at lag.net-20080324065139-nmvo5goh1izbd3gr -- Dwayne Litzenberger, B.A.Sc. Information Technology Analyst Open Systems Canada Limited #210 - 2332 11th Ave Regina, SK S4P0K1 Office: (306) 359-OSCL (6725) http://www.oscl.ca/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://www.lag.net/pipermail/paramiko/attachments/20080403/c09daa67/attachment.pgp From dwayne at oscl.ca Fri Apr 4 14:36:47 2008 From: dwayne at oscl.ca (Dwayne Litzenberger) Date: Fri, 4 Apr 2008 15:36:47 -0600 Subject: [paramiko] [MERGE] paramiko random number regression: Stop using RandomPool! In-Reply-To: <200804031612.28314.dwayne@oscl.ca> References: <200804031612.28314.dwayne@oscl.ca> Message-ID: <200804041536.52556.dwayne@oscl.ca> On April 3, 2008 04:12:23 pm Dwayne Litzenberger wrote: [snip] > Revision #486 [1] (and therefore Paramiko 1.7.3) re-introduces the problems > associated with PyCrypto's RandomPool class that I described in my post > back in January. RandomPool is not a simple "get random bits" primitive, > but paramiko is again using it as one. [snip] > The result is that Paramiko 1.7.3 is totally insecure on Windows, no matter > what version of Python is being used. On other operating systems, there is > still the RandomPool threading issue. > > I will be posting a patch shortly. The patch is attached. -- Dwayne Litzenberger, B.A.Sc. Information Technology Analyst Open Systems Canada Limited #210 - 2332 11th Ave Regina, SK S4P0K1 Office: (306) 359-OSCL (6725) http://www.oscl.ca/ -------------- next part -------------- A non-text attachment was scrubbed... Name: paramiko-fix-rng-again.bundle Type: text/x-diff Size: 21618 bytes Desc: not available Url : http://www.lag.net/pipermail/paramiko/attachments/20080404/c1f12e92/attachment.diff -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://www.lag.net/pipermail/paramiko/attachments/20080404/c1f12e92/attachment.pgp From robey at lag.net Sat Apr 12 15:06:27 2008 From: robey at lag.net (Robey Pointer) Date: Sat, 12 Apr 2008 15:06:27 -0700 Subject: [paramiko] paramiko random number regression: Stop using RandomPool! In-Reply-To: <200804031612.28314.dwayne@oscl.ca> References: <200804031612.28314.dwayne@oscl.ca> Message-ID: <9AD99338-0C7B-4208-82F5-ACBC7F58D40A@lag.net> On 3 Apr 2008, at 15:12, Dwayne Litzenberger wrote: > > Revision #486 [1] (and therefore Paramiko 1.7.3) re-introduces the > problems > associated with PyCrypto's RandomPool class that I described in my > post back > in January. RandomPool is not a simple "get random bits" primitive, > but > paramiko is again using it as one. Is there nothing Windows users can do? I added RandomPool as a fallback because on my Windows XP box did not have the winrandom module. Since I think XP will be the most widely used Windows release for the forseeable future, this is really bad. :( > This is a very serious bug for Windows users of Paramiko. As I > mentioned in > my January post, there is a longstanding bug in PyCrypto that causes > the > native "winrandom" module to not be built. As a result, the only > way to get > entropy from Windows is to use the os.urandom module (provided in > Python 2.4 > and later). Unfortunately, when you merged my changes, you removed > the call > to os.urandom. This error would normally have been detected on > systems > lacking a winrandom module (i.e. all of them), but since you > replaced the call > to os.urandom with the instantiation of RandomPool, Paramiko's > random number > generator simply fails silently. Actually I just moved the os.urandom code into our osrandom.py file, so it should still use /dev/urandom in preference to anything else, and will use winrandom if it can find that. Is there anything at all we can do to keep things running on XP but (relatively) secure? robey From dwayne at oscl.ca Mon Apr 14 09:16:49 2008 From: dwayne at oscl.ca (Dwayne Litzenberger) Date: Mon, 14 Apr 2008 10:16:49 -0600 Subject: [paramiko] [MERGE] non-interoperable NULL cipher support In-Reply-To: <200804021148.05901.dwayne@oscl.ca> References: <200804021148.05901.dwayne@oscl.ca> Message-ID: <200804141016.54055.dwayne@oscl.ca> On April 2, 2008 11:48:05 am Dwayne Litzenberger wrote: > The attached bundle adds the cipher and MAC algorithms "none at lag.net". It > is commented out in the code by default, and it does not interoperate with > other SSH implementations. > > I'm using it to try to reproduce the deadlock I'm seeing. Robey, don't bother merging this. It hasn't helped me find the deadlock so far anyway. -- Dwayne Litzenberger, B.A.Sc. Information Technology Analyst Open Systems Canada Limited #210 - 2332 11th Ave Regina, SK S4P0K1 Office: (306) 359-OSCL (6725) http://www.oscl.ca/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://www.lag.net/pipermail/paramiko/attachments/20080414/c4feb796/attachment.pgp From dwayne at oscl.ca Mon Apr 14 10:13:08 2008 From: dwayne at oscl.ca (Dwayne Litzenberger) Date: Mon, 14 Apr 2008 11:13:08 -0600 Subject: [paramiko] paramiko random number regression: Stop using RandomPool! In-Reply-To: <9AD99338-0C7B-4208-82F5-ACBC7F58D40A@lag.net> References: <200804031612.28314.dwayne@oscl.ca> <9AD99338-0C7B-4208-82F5-ACBC7F58D40A@lag.net> Message-ID: <200804141113.12530.dwayne@oscl.ca> On April 12, 2008 04:06:27 pm Robey Pointer wrote: > Is there nothing Windows users can do? I added RandomPool as a > fallback because on my Windows XP box did not have the winrandom > module. Since I think XP will be the most widely used Windows release > for the forseeable future, this is really bad. :( It has nothing to do with Windows XP. The winrandom module is part of *PyCrypto*, but there is a bug in PyCrypto 2.0.1 where the winrandom module is omitted from setup.py. On Windows systems, the os.urandom function in Python >= 2.4 is equivalent to the winrandom.new().get_bytes function. That's why my previous patch kept both os.urandom and /dev/urandom. In addition to fixing this RNG regression, my latest patch also does several other sanity checks to avoid running insecurely, and it combines RandomPool with the OS RNG in a thread-safe manner, so that certain types of potential weaknesses in the OS RNG don't become immediately exploitable in paramiko. Since Microsoft is changing how the Windows RNG works, I think this is a good idea. For the long term, I plan to take over the maintainership of PyCrypto, and move this functionality into PyCrypto itself. (When I contacted A. M. Kuchling about the winrandom problem, he said that he's not doing much with PyCrypto anymore. Nobody else seems to be maintaining PyCrypto either, so I might as well do it.) It'll be a month or two before I start making releases of PyCrypto; I'm moving across the country at the end of the month, and there is a pile of bug reports and suggested changes to PyCrypto that I want to sort through before I release anything. I don't want to risk making things worse by rushing a PyCrypto release, but in the meantime, you can improve paramiko's security by applying "paramiko-fix-rng-again.bundle". -- Dwayne Litzenberger, B.A.Sc. Information Technology Analyst Open Systems Canada Limited #210 - 2332 11th Ave Regina, SK S4P0K1 Office: (306) 359-OSCL (6725) http://www.oscl.ca/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://www.lag.net/pipermail/paramiko/attachments/20080414/0669aee3/attachment.pgp From dwayne at oscl.ca Mon Apr 14 17:02:25 2008 From: dwayne at oscl.ca (Dwayne Litzenberger) Date: Mon, 14 Apr 2008 18:02:25 -0600 Subject: [paramiko] paramiko stops responding after huge data is transferred ! In-Reply-To: <200803311401.18875.dwayne@oscl.ca> References: <48224a820803150626k10c6054eld26ba1390b451d61@mail.gmail.com> <200803281418.43586.dwayne@oscl.ca> <200803311401.18875.dwayne@oscl.ca> Message-ID: <200804141802.26573.dwayne@oscl.ca> It's a threading issue. I managed to catch two threads trying to acquire a Channel.lock at the same time. It looks like Channel._window_adjust (or other like functions) are sometimes being called by threads that do not hold the Channel.lock. Here are the tracebacks of the two threads on the server (ignore the lockwrapper.py stuff): ================================== id=-1214578356,thread=MySenderThread,name=channel.py:687: ACQUIRED File "/usr/lib/python2.4/threading.py", line 442, in __bootstrap self.run() File "/usr/lib/python2.4/threading.py", line 422, in run self.__target(*self.__args, **self.__kwargs) File "./test-server.py", line 39, in _run wfile.write(a.encrypt("X" * 1024)) File "/home/dwon/rsync-link-backup/paramiko-deadlock-bug/paramiko/file.py", line 330, in write self.flush() File "/home/dwon/rsync-link-backup/paramiko-deadlock-bug/paramiko/file.py", line 91, in flush self._write_all(self._wbuffer.getvalue()) File "/home/dwon/rsync-link-backup/paramiko-deadlock-bug/paramiko/file.py", line 435, in _write_all count = self._write(data) File "/home/dwon/rsync-link-backup/paramiko-deadlock-bug/paramiko/channel.py", line 1211, in _write self.channel.sendall(data) File "/home/dwon/rsync-link-backup/paramiko-deadlock-bug/paramiko/channel.py", line 760, in sendall sent = self.send(s) File "/home/dwon/rsync-link-backup/paramiko-deadlock-bug/paramiko/channel.py", line 687, in send self.lock.acquire() File "/home/dwon/rsync-link-backup/paramiko-deadlock-bug/paramiko/lockwrapper.py", line 43, in acquire self._log("ACQUIRED") File "/home/dwon/rsync-link-backup/paramiko-deadlock-bug/paramiko/lockwrapper.py", line 23, in _log rawdata += "".join(traceback.format_stack()) ================================== id=-1214578356,thread=Transport,name=channel.py:955: ACQUIRING File "/usr/lib/python2.4/threading.py", line 442, in __bootstrap self.run() File "/home/dwon/rsync-link-backup/paramiko-deadlock-bug/paramiko/transport.py", line 1528, in run self._channel_handler_table[ptype](chan, m) File "/home/dwon/rsync-link-backup/paramiko-deadlock-bug/paramiko/channel.py", line 955, in _window_adjust self.lock.acquire() File "/home/dwon/rsync-link-backup/paramiko-deadlock-bug/paramiko/lockwrapper.py", line 41, in acquire self._log("ACQUIRING") File "/home/dwon/rsync-link-backup/paramiko-deadlock-bug/paramiko/lockwrapper.py", line 23, in _log rawdata += "".join(traceback.format_stack()) -- Dwayne Litzenberger, B.A.Sc. Information Technology Analyst Open Systems Canada Limited #210 - 2332 11th Ave Regina, SK S4P0K1 Office: (306) 359-OSCL (6725) http://www.oscl.ca/ From alan at codescape.net Mon Apr 14 17:26:02 2008 From: alan at codescape.net (Alan Briolat) Date: Tue, 15 Apr 2008 01:26:02 +0100 Subject: [paramiko] Dynamic (SOCKS) forwarding Message-ID: I'm writing an SSH tunnel manager to integrate with GNOME at the moment, and one thing I think might cause me some trouble using paramiko is trying to do the dynamic forwards (ssh -D 1234). Has anybody ever given any thought to how this might be achieved with paramiko? Am I likely to have to write something like a SOCKS server (or use an existing one) and have paramiko spawn channels for every connection attempt, in the same way the "real" ssh clients do? -- Alan Briolat (http://www.codescape.net/) 2nd Year, Computer Systems and Software Engineering (MEng), University of York, UK Computing Officer, York Student Television (http://ystv.york.ac.uk/) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.lag.net/pipermail/paramiko/attachments/20080415/f8bb70c2/attachment.htm From dwayne at oscl.ca Tue Apr 15 10:02:14 2008 From: dwayne at oscl.ca (Dwayne Litzenberger) Date: Tue, 15 Apr 2008 11:02:14 -0600 Subject: [paramiko] paramiko stops responding after huge data is transferred ! In-Reply-To: <200804141802.26573.dwayne@oscl.ca> References: <48224a820803150626k10c6054eld26ba1390b451d61@mail.gmail.com> <200803311401.18875.dwayne@oscl.ca> <200804141802.26573.dwayne@oscl.ca> Message-ID: <200804151102.15507.dwayne@oscl.ca> On April 14, 2008 06:02:25 pm Dwayne Litzenberger wrote: > It looks like Channel._window_adjust (or other like functions) are > sometimes being called by threads that do not hold the Channel.lock. It's happening in a few different places, actually. More on this as I find out... -- Dwayne Litzenberger, B.A.Sc. Information Technology Analyst Open Systems Canada Limited #210 - 2332 11th Ave Regina, SK S4P0K1 Office: (306) 359-OSCL (6725) http://www.oscl.ca/ From dwayne at oscl.ca Tue Apr 15 12:03:00 2008 From: dwayne at oscl.ca (Dwayne Litzenberger) Date: Tue, 15 Apr 2008 13:03:00 -0600 Subject: [paramiko] paramiko stops responding after huge data is transferred ! In-Reply-To: <200804151102.15507.dwayne@oscl.ca> References: <48224a820803150626k10c6054eld26ba1390b451d61@mail.gmail.com> <200804141802.26573.dwayne@oscl.ca> <200804151102.15507.dwayne@oscl.ca> Message-ID: <200804151303.01787.dwayne@oscl.ca> On April 15, 2008 11:02:14 am Dwayne Litzenberger wrote: > More on this as I find out... In the main thread: Channel.send acquires Channel.lock, calls Channel._wait_for_send_window, then calls Transport._send_user_message with a MSG_CHANNEL_DATA message. Transport._send_user_message then waits for Transport.clear_to_send to be set, but it's not set for some reason. Note that Channel.lock is still held by the main thread. Meanwhile, the Transport thread tries to process a MSG_WINDOW_ADJUST message. It calls Channel._window_adjust, but that can't proceed until Channel.lock is released. At this point, the main thread and the Transport thread are deadlocked. Remaining question: Why is Transport._parse_newkeys the only place where Transport.clear_to_send is set? Can't we resume sending as soon as *our own* MSG_NEWKEYS is transmitted? -- Dwayne Litzenberger, B.A.Sc. Information Technology Analyst Open Systems Canada Limited #210 - 2332 11th Ave Regina, SK S4P0K1 Office: (306) 359-OSCL (6725) http://www.oscl.ca/ From dwayne at oscl.ca Tue Apr 15 15:58:05 2008 From: dwayne at oscl.ca (Dwayne Litzenberger) Date: Tue, 15 Apr 2008 16:58:05 -0600 Subject: [paramiko] paramiko stops responding after huge data is transferred ! In-Reply-To: <200804151303.01787.dwayne@oscl.ca> References: <48224a820803150626k10c6054eld26ba1390b451d61@mail.gmail.com> <200804151102.15507.dwayne@oscl.ca> <200804151303.01787.dwayne@oscl.ca> Message-ID: <200804151658.05679.dwayne@oscl.ca> On April 15, 2008 01:03:00 pm Dwayne Litzenberger wrote: > In the main thread: > > Channel.send acquires Channel.lock, calls Channel._wait_for_send_window, > then calls Transport._send_user_message with a MSG_CHANNEL_DATA message. > Transport._send_user_message then waits for Transport.clear_to_send to be > set, but it's not set for some reason. Note that Channel.lock is still > held by the main thread. > > Meanwhile, the Transport thread tries to process a MSG_WINDOW_ADJUST > message. It calls Channel._window_adjust, but that can't proceed until > Channel.lock is released. clear_to_send is unset (correctly) because we've just sent MSG_KEXINIT. The problem seems to be that Channel.send() is holding Channel.lock, thus preventing still-in-transit messages like MSG_WINDOW_ADJUST from being processed by the Transport thread, even though we haven't received the remote side's MSG_KEXINIT yet. What resources is Channel.lock intended to protect? -- Dwayne Litzenberger, B.A.Sc. Information Technology Analyst Open Systems Canada Limited #210 - 2332 11th Ave Regina, SK S4P0K1 Office: (306) 359-OSCL (6725) http://www.oscl.ca/ From laprice at gmail.com Thu Apr 17 00:10:09 2008 From: laprice at gmail.com (larry price) Date: Thu, 17 Apr 2008 00:10:09 -0700 Subject: [paramiko] how to verify a public key? Message-ID: Hi, I've googled the archives and looked through the documentation trying to answer this question. I want to take a string of text and determine if it is or is not a valid (well-formed) dsa or rsa public key and then hash it for comparison. I also want to be able to do elementary repair (stripping whitespace and illegal chars out of the text blob) to deal with broken email clients or cut and paste strangeness. I looked through pycrypto too, and although that seemed more promising it deals with the generation but not the verification step. I assume that somewhere in the server components you do something that looks like parsing an authorized_keys file. Where is that spot? I see that check_auth_publickey is a placeholder, is there somewhere else I should be looking? From dwayne at oscl.ca Thu Apr 17 09:26:03 2008 From: dwayne at oscl.ca (Dwayne Litzenberger) Date: Thu, 17 Apr 2008 10:26:03 -0600 Subject: [paramiko] how to verify a public key? In-Reply-To: References: Message-ID: <200804171026.07297.dwayne@oscl.ca> On April 17, 2008 01:10:09 am larry price wrote: > I want to take a string of text and determine if it is or is not a > valid (well-formed) dsa or rsa public key and then hash it for > comparison. > > I also want to be able to do elementary repair (stripping whitespace > and illegal chars out of the text blob) to deal with broken email > clients or cut and paste strangeness. [snip] > I assume that somewhere in the server components you do something that > looks like parsing an authorized_keys file. Where is that spot? Paramiko doesn't support OpenSSH's authorized_keys file format directly, though the building blocks are there. I did it (without support for option specifications) in 18 lines: # ============================================= import paramiko import base64 def get_authorized_keys(file): for rawline in file: line = rawline.strip() if line == "" or line.startswith("#"): continue try: (keytype, b64key, comment) = (line.split(" ", 2) + [''] * 3)[:3] if keytype == 'ssh-rsa': yield paramiko.RSAKey(data=base64.decodestring(b64key)) elif keytype == 'ssh-dss': yield paramiko.DSSKey(data=base64.decodestring(b64key)) else: raise ValueError("Unknown key type %r" % (keytype,)) except ValueError: continue # ============================================= As for stripping whitespace, invalid chars, etc, if you can determine whether the key is RSA or DSS (which is indicated in plain ASCII in the file, and also encoded into the base64 message block), and you can get the base64-encoded message block, then Python's base64 decoder will happily skip any invalid characters. Regarding hashing the , once you have a paramiko.RSAKey or paramiko.DSSKey object, you can call .get_fingerprint() to get an MD5 hash of the key. Or, if you want a different hash function, you can do something like SHA256.new(str(pk)).digest(). -- Dwayne Litzenberger, B.A.Sc. Information Technology Analyst Open Systems Canada Limited #210 - 2332 11th Ave Regina, SK S4P0K1 Office: (306) 359-OSCL (6725) http://www.oscl.ca/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://www.lag.net/pipermail/paramiko/attachments/20080417/ca8fe4d8/attachment.pgp From sebeeek at gmail.com Thu Apr 17 13:45:30 2008 From: sebeeek at gmail.com (sebek) Date: Thu, 17 Apr 2008 23:45:30 +0300 Subject: [paramiko] redistributing parts of paramiko Message-ID: <1208465130.6698.33.camel@bourdon> Hello list, I am new to the list and I am currently developing a graphical ssh connection manager under the GPL licence based on paramiko and pygtk. As I will be asking to my users to install paramiko by themselves, I won't redistribute paramiko with my software. However, I wonder if I can redistribute the file "interactive.py" that is included in the paramiko examples. This file is handy to create interactive connections. I will keep the file as a whole (especially the licence and copyright). Can I redistribute it? thank you BR From dwayne at oscl.ca Thu Apr 17 14:06:46 2008 From: dwayne at oscl.ca (Dwayne Litzenberger) Date: Thu, 17 Apr 2008 15:06:46 -0600 Subject: [paramiko] redistributing parts of paramiko In-Reply-To: <1208465130.6698.33.camel@bourdon> References: <1208465130.6698.33.camel@bourdon> Message-ID: <200804171506.47081.dwayne@oscl.ca> On April 17, 2008 02:45:30 pm sebek wrote: > Hello list, > > I am new to the list and I am currently developing a graphical ssh > connection manager under the GPL licence based on paramiko and pygtk. > > As I will be asking to my users to install paramiko by themselves, I > won't redistribute paramiko with my software. > > However, I wonder if I can redistribute the file "interactive.py" that > is included in the paramiko examples. This file is handy to create > interactive connections. I will keep the file as a whole (especially the > licence and copyright). > > Can I redistribute it? I am neither your lawyer, nor the copyright holder for interactive.py. However, I note that interactive.py has the following header: Copyright (C) 2003-2007 Robey Pointer This file is part of paramiko. Paramiko is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version. Section 3 of the GNU LGPL 2.1 states: 3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices. Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy. This option is useful when you wish to copy part of the code of the Library into a program that is not a library. So if your program is GPL-licenced, I believe it can incorporate LGPL-covered Paramiko. -- Dwayne Litzenberger, B.A.Sc. Information Technology Analyst Open Systems Canada Limited #210 - 2332 11th Ave Regina, SK S4P0K1 Office: (306) 359-OSCL (6725) http://www.oscl.ca/ From samu at linuxasylum.net Fri Apr 18 10:23:45 2008 From: samu at linuxasylum.net (Samuele Giovanni Tonon) Date: Fri, 18 Apr 2008 19:23:45 +0200 Subject: [paramiko] demo_server and port forwarding ( -L only) Message-ID: <4808D921.9050105@linuxasylum.net> hello all, i've started looking to paramiko to develop some kind of tunneling between PC behind a Nat firewall. I've found the demos very useful and after some playing i wanted to implement the port forwarding in the demo_server example . After some looking to the documentation i'm stuck : suppose we want to do something like : ssh -L 4000:somemachine:4005 somemachine and demo_server is running on somemachine on forward.py we have chan = self.ssh_transport.open_channel('direct-tcpip', (self.chain_host, self.chain_port), self.request.getpeername()) which is responsible on creating the chan that will read and write from local port to the ssh server on "somemachine" demo_sever (with some changes) is now able to accept data and also able to print (for debugging purpose) on output.. now the problem is: how to write whatever i read on "demo_server" chan on somemachine:4005 ? i first thought of a simple solution by "overloading" check_channel_direct_tcpip_request of Server Class in demo_server def check_channel_direct_tcpip_request(self, chanid, origin,destination): self.lsender = socket.socket(socket.AF_INET,socket.SOCK_STREAM) self.lsender.connect(destination) self.event.set() return paramiko.OPEN_SUCCEEDED and then later, when channel is open run a simple select like this: while True: r, w, x = select.select([chan, server.lsender],[],[]) if server.lsender in r: data = server.lsender.recv(1024) if len(data) == 0: break chan.send(data) if chan in r: data = chan.recv(1024) if len(data) == 0: break server.lsender.send(data) chan.close() server.lsender.close() All is working fine, all seems correct to me, am i wrong in something or actually i did in the right way ? if all is good then i'll start look on how to work for a port forwarding (the -R way speaking with ssh options like ) Regards Samuele -- While various networks have become deeply rooted, and thoughts have been sent out as light and electrons in a singular direction, this era has yet to digitize/computerize to the degree necessary for individuals to become a singular complex entity. KOUKAKU KIDOUTAI Stand Alone Complex From dwayne at oscl.ca Fri Apr 18 13:15:36 2008 From: dwayne at oscl.ca (Dwayne Litzenberger) Date: Fri, 18 Apr 2008 14:15:36 -0600 Subject: [paramiko] [MERGE] Fix obscure deadlock that can occur during re-keying In-Reply-To: <200804151658.05679.dwayne@oscl.ca> References: <48224a820803150626k10c6054eld26ba1390b451d61@mail.gmail.com> <200804151303.01787.dwayne@oscl.ca> <200804151658.05679.dwayne@oscl.ca> Message-ID: <200804181415.40332.dwayne@oscl.ca> Robey, I've attached a patch does the following: - Fix deadlock: Paramiko sometimes deadlocks if the user tries to send data immediately after paramiko has initiated a key exchange (re-keying), but before the remote MSG_KEXINIT has been received. The deadlock occurs when certain messages are received (e.g. MSG_CHANNEL_WINDOW_ADJUST) that were in-transit when the initial MSG_KEXINIT was sent. - Add a test case for the deadlock - Fix __dump_packets support for SFTPServer and SFTPClient. (Needed to make test.py work when Packetizer.__dump_packets = True. This patch took about 38 hours to produce, and was funded entirely by my employer, Open Systems Canada Limited. They also paid for a lot of my work on the PRNG bugfixes (especially the as-yet unmerged rng*.py implementation). Basically, everything that came from my oscl.ca email address has been paid for by them. It would be nice if they got some credit somewhere... They're a small, FOSS-friendly IT services firm that could use the brand exposure. Cheers, - Dwayne On April 15, 2008 04:58:05 pm Dwayne Litzenberger wrote: > On April 15, 2008 01:03:00 pm Dwayne Litzenberger wrote: > > In the main thread: > > > > Channel.send acquires Channel.lock, calls Channel._wait_for_send_window, > > then calls Transport._send_user_message with a MSG_CHANNEL_DATA message. > > Transport._send_user_message then waits for Transport.clear_to_send to be > > set, but it's not set for some reason. Note that Channel.lock is still > > held by the main thread. > > > > Meanwhile, the Transport thread tries to process a MSG_WINDOW_ADJUST > > message. It calls Channel._window_adjust, but that can't proceed until > > Channel.lock is released. > > clear_to_send is unset (correctly) because we've just sent MSG_KEXINIT. > The problem seems to be that Channel.send() is holding Channel.lock, thus > preventing still-in-transit messages like MSG_WINDOW_ADJUST from being > processed by the Transport thread, even though we haven't received the > remote side's MSG_KEXINIT yet. -- Dwayne Litzenberger, B.A.Sc. Information Technology Analyst Open Systems Canada Limited #210 - 2332 11th Ave Regina, SK S4P0K1 Office: (306) 359-OSCL (6725) http://www.oscl.ca/ -------------- next part -------------- A non-text attachment was scrubbed... Name: paramiko-deadlock-bugfix-and-testcase.bundle Type: text/x-diff Size: 16007 bytes Desc: not available Url : http://www.lag.net/pipermail/paramiko/attachments/20080418/005dc7f2/attachment.diff -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://www.lag.net/pipermail/paramiko/attachments/20080418/005dc7f2/attachment.pgp From robey at lag.net Sat Apr 19 16:14:29 2008 From: robey at lag.net (Robey Pointer) Date: Sat, 19 Apr 2008 16:14:29 -0700 Subject: [paramiko] redistributing parts of paramiko In-Reply-To: <200804171506.47081.dwayne@oscl.ca> References: <1208465130.6698.33.camel@bourdon> <200804171506.47081.dwayne@oscl.ca> Message-ID: <20701F34-74FF-4ADD-A8FA-A40222094B29@lag.net> On 17 Apr 2008, at 14:06, Dwayne Litzenberger wrote: > On April 17, 2008 02:45:30 pm sebek wrote: >> Hello list, >> >> I am new to the list and I am currently developing a graphical ssh >> connection manager under the GPL licence based on paramiko and pygtk. >> >> As I will be asking to my users to install paramiko by themselves, I >> won't redistribute paramiko with my software. >> >> However, I wonder if I can redistribute the file "interactive.py" >> that >> is included in the paramiko examples. This file is handy to create >> interactive connections. I will keep the file as a whole >> (especially the >> licence and copyright). >> >> Can I redistribute it? > > I am neither your lawyer, nor the copyright holder for interactive.py. > However, I note that interactive.py has the following header: I agree with Dwayne's assessment: the LGPL license makes it compatible with your GPL'd code. I am happy with that kind of use. robey