From dlitz at dlitz.net  Sat Mar  1 22:44:35 2008
From: dlitz at dlitz.net (Dwayne C. Litzenberger)
Date: Sun, 2 Mar 2008 00:44:35 -0600
Subject: [paramiko] [PATCH] osrandom doesn't work nicely in chroot()
	environment
Message-ID: <20080302064435.GA12173@rivest.dlitz.net>

I'm implementing an SFTP server for paramiko, and this server supports 
chroot()ing into an individual user's home directory.

Unfortunately, once you do os.chroot(), os.urandom() fails with 
NotImplementedError:

     >>> import paramiko, os
     >>> paramiko.randpool.get_bytes(4)
     '@\x92:\xa7'
     >>> os.chroot("/home/dwon")
     >>> paramiko.randpool.get_bytes(4)
     Traceback (most recent call last):
       File "<stdin>", line 1, in ?
       File "os.py", line 720, in urandom
     NotImplementedError: /dev/urandom (or equivalent) not found

I've attached a patch that works around this problem by making
OSRandomPool automatically fall back to using a previously-opened file 
descriptor connected to /dev/urandom.  The result is that if you import the 
paramiko module before performing os.chroot(), paramiko is still able to 
get random numbers.

This patch has not been tested on win32.  Someone should do that before the 
next paramiko release, as I am known to have typos in my patches. :)

Cheers,
 - Dwayne

-- 
Dwayne C. Litzenberger <dlitz at dlitz.net>
-------------- next part --------------
# Bazaar merge directive format 2 (Bazaar 0.90)
# revision_id: dlitz at dlitz.net-20080302055903-yar80xyhaxf5zzs5
# target_branch: http://www.lag.net/paramiko/bzr/paramiko/
# testament_sha1: bdc3ebac67bb6319245b0c8a0e22d1740d56f486
# timestamp: 2008-03-02 00:34:46 -0600
# base_revision_id: robey at lag.net-20080220060035-yi82h5kc7jod5hlu
# 
# Begin patch
=== modified file 'paramiko/osrandom.py'
--- paramiko/osrandom.py	2008-02-18 05:12:29 +0000
+++ paramiko/osrandom.py	2008-03-02 05:59:03 +0000
@@ -20,74 +20,142 @@
 
 import sys
 
-# Detect an OS random number source
+##
+## Find potential random number sources
+##
+
+# Try to import os.urandom
+try:
+    from os import urandom
+except ImportError:
+    urandom = None
+
+# Try to import the "winrandom" module
+try:
+    from Crypto.Util import winrandom
+except ImportError:
+    winrandom = None
+
+# Try to open /dev/urandom now so that paramiko will be able to access
+# it even if os.chroot() is invoked later.
+try:
+    _dev_urandom = open("/dev/urandom", "rb", 0)
+except EnvironmentError:
+    _dev_urandom = None
+
+##
+## Define RandomPool classes
+##
+
+def _workaround_windows_cryptgenrandom_bug(self):
+    # According to "Cryptanalysis of the Random Number Generator of the
+    # Windows Operating System", by Leo Dorrendorf and Zvi Gutterman
+    # and Benny Pinkas <http://eprint.iacr.org/2007/419>,
+    # CryptGenRandom only updates its internal state using kernel-provided
+    # random data every 128KiB of output.
+    self.get_bytes(128*1024)    # discard 128 KiB of output
+
+class BaseOSRandomPool(object):
+    def __init__(self, numbytes=160, cipher=None, hash=None):
+        pass
+
+    def stir(self, s=''):
+        pass
+
+    def randomize(self, N=0):
+        self.stir()
+
+    def add_event(self, s=None):
+        pass
+
+class WinRandomPool(BaseOSRandomPool):
+    """RandomPool that uses the C{winrandom} module for input"""
+    def __init__(self, numbytes=160, cipher=None, hash=None):
+        self._wr = winrandom.new()
+        self.get_bytes = self._wr.get_bytes
+        self.randomize()
+
+    def stir(self, s=''):
+        _workaround_windows_cryptgenrandom_bug(self)
+
+class DevUrandomPool(BaseOSRandomPool):
+    """RandomPool that uses the C{/dev/urandom} special device node for input"""
+    def __init__(self, numbytes=160, cipher=None, hash=None):
+        self.randomize()
+
+    def get_bytes(self, n):
+        return _dev_urandom.read(n)
+
+class OSUrandomPool(BaseOSRandomPool):
+    """RandomPool that uses the C{os.urandom} function for input.
+    
+    This module falls back to reading /dev/urandom if os.urandom is unavailable.
+    """
+    def __init__(self, numbytes=160, cipher=None, hash=None):
+        self.randomize()
+
+    def stir(self, s=''):
+        if sys.platform == 'win32':
+            _workaround_windows_cryptgenrandom_bug(self)
+
+    def get_bytes(self, n):
+        try:
+            if urandom is None:
+                raise NotImplementedError
+            return urandom(n)   # might also raise NotImplementedError (especially in chroot environment)
+        except NotImplementedError:
+            return _dev_urandom.read(n)
+
+##
+## Detect default random number source
+##
 osrandom_source = None
 
 # Try os.urandom
-if osrandom_source is None:
-    try:
-        from os import urandom
-        osrandom_source = "os.urandom"
-    except ImportError:
-        pass
+if osrandom_source is None and urandom is not None:
+    osrandom_source = "os.urandom"
+    DefaultRandomPoolClass = OSUrandomPool
 
 # Try winrandom
-if osrandom_source is None:
-    try:
-        from Crypto.Util import winrandom
-        osrandom_source = "winrandom"
-    except ImportError:
-        pass
+if osrandom_source is None and winrandom is not None:
+    osrandom_source = "winrandom"
+    DefaultRandomPoolClass = WinRandomPool
 
 # Try /dev/urandom
-if osrandom_source is None:
-    try:
-        _dev_urandom = open("/dev/urandom", "rb", 0)
-        def urandom(bytes):
-            return _dev_urandom.read(bytes)
-        osrandom_source = "/dev/urandom"
-    except (OSError, IOError):
-        pass
+if osrandom_source is None and _dev_urandom is not None:
+    osrandom_source = "/dev/urandom"
+    DefaultRandomPoolClass = DevUrandomPool
 
 # Give up
 if osrandom_source is None:
     raise ImportError("Cannot find OS entropy source")
 
-class BaseOSRandomPool(object):
-    def __init__(self, numbytes=160, cipher=None, hash=None):
-        pass
+
+##
+## Define wrapper class
+##
+
+class OSRandomPool(object):
+    """RandomPool wrapper.
+
+    The C{randpool} attribute of this object may be modified by users of this class at runtime.
+    """
+
+    def __init__(self, instance=None):
+        if instance is None:
+            instance = DefaultRandomPoolClass()
+        self.randpool = instance
 
     def stir(self, s=''):
-        # According to "Cryptanalysis of the Random Number Generator of the
-        # Windows Operating System", by Leo Dorrendorf and Zvi Gutterman
-        # and Benny Pinkas <http://eprint.iacr.org/2007/419>,
-        # CryptGenRandom only updates its internal state using kernel-provided
-        # random data every 128KiB of output.
-        if osrandom_source == 'winrandom' or sys.platform == 'win32':
-            self.get_bytes(128*1024)    # discard 128 KiB of output
+        self.randpool.stir(s)
 
     def randomize(self, N=0):
-        self.stir()
+        self.randpool.randomize(N)
 
     def add_event(self, s=None):
-        pass
-
-class WinrandomOSRandomPool(BaseOSRandomPool):
-    def __init__(self, numbytes=160, cipher=None, hash=None):
-        self._wr = winrandom.new()
-        self.get_bytes = self._wr.get_bytes
-        self.randomize()
-
-class UrandomOSRandomPool(BaseOSRandomPool):
-    def __init__(self, numbytes=160, cipher=None, hash=None):
-        self.get_bytes = urandom
-        self.randomize()
-
-if osrandom_source in ("/dev/urandom", "os.urandom"):
-    OSRandomPool = UrandomOSRandomPool
-elif osrandom_source == "winrandom":
-    OSRandomPool = WinrandomOSRandomPool
-else:
-    raise AssertionError("Unrecognized osrandom_source %r" % (osrandom_source,))
+        self.randpool.add_event(s)
+
+    def get_bytes(self, N):
+        return self.randpool.get_bytes(N)
 
 # vim:set ts=4 sw=4 sts=4 expandtab:

# Begin bundle
IyBCYXphYXIgcmV2aXNpb24gYnVuZGxlIHY0CiMKQlpoOTFBWSZTWRNWhU0AA8FfgERUWff//3+v
3pC////6YAjPva4O6lbQmlfdrvdyHbudvVw5z3Rngkk0EJqZI9PSniYTSMnpDQ0yGNQAaNBpkEkg
EaaaCRoNFPRNPU0ep6ho0AAANDQHGTJoxDTQwE0MTRpkxAyMJo00wgyYSIiTIp5lJmpmk8g1AYgZ
ABoAaAGg2lEnqbSgNPSNA0AAAAAAANABIkhommTQmCNQ9TNMppPNU9T1NHqNGIBiaGhIQBgpaH5Y
azYscceLVP6EGpNdbSavqqsJNatSMdn8e7BaM8yHJQBCK2r2A3e4zXkhfFzVRjZC34BtK0ao+DI4
lCJ6DXUdNqZaah9jDLi0CECtSK2SQmhrxtjakcLtgjcfXJ9OFmZBY/3DPKvDc5n7OO3jrbpibXdJ
WxQ3uy4qwo9XVB6EzhiM8b04WTSA4vTR6d4Uq8235c5isVJMVHZPgxOJ0ZKMXZ/ohugdPRzVk+AT
/5tss6+vLeANOcNLPs4/WxVifq7c76K4StqXvlg7RbY4zybMK9zBtDhbeE6S1xLwjFYqIO9JdxGO
ujtLNVkUfWOdM461wjROiZhltzWNa0DAxen46J2zEh1tNVwm6lNrkIKmTo6QtbJMur+/i7I9tu32
Ije7EHZgNEBZ8Xh198Cst100VgwhjbH5QMQw8agmjCAK0frmuRYI5dORb2ixt1RhQzF0JE6tKpVf
gYUKnTQ/My6X5lEqaTjr5U0XKqbz3MZVihWSpxd2wrGmFAdIsNBUIn+o+c4OPfFqV1do0Om+Tqvl
7FRx6u3Ihhbs6QVFRkQGg4clOLOG4d2TwYejpxMHaitbqLXIR9euOG0JSibXBAbiRtFAdZ21bhUC
iwKnYUgcAkRKiPM4n2XhTnB9mALZSsGxtJjWzrnP6Sh8pIzbEY7OAb6lMTw54u9mrZHQei0WRPRm
K4W3UCuyihzlCesgk8kiukK0w1EGg8ToPCCizvYHUo6yUWSdF/dkYEl0xeP4g+eLVoFsNoluODqw
PMuWVevmOki/Aj5hsL5EyK4Joy6RjPHIf1bXJC5jPGdwLp3AmcSp0LwXeKUiaGTGpvpW2K0fdqPv
jPUxksFUeaophJsATpnYJ4eRQ6y9s6Rw1ac11DFrLIMx8yks0H3IzcIZNSJIXfRRQ68fPoxOWxUK
5UZy8Ku0L/A8jMzDvZC4NIwweFg8st+whrUuRgrjvuyoGbgMknnAs0wePoSmizUS77Jh+JfKBxB2
NHZ6lCUpxnNCcVSgaa6GbLSANghiLgYT+oERzDxhH8otCr4JVZBqnvHykHPNHDu4ceTn3e7bReRh
UEtC7xFZTcMTT20OD01XplgrkVr4e3HpJ2ByPSdxvZPqfZ4a+Yx0wd5NHMeUM7KzS68kREoVrFYo
UCYXmhNgNsTTQmAq2r+4i0cmF4h8YTB61BZPqMnHVaLmyJaIvQVPqrOnoPOZS1QVrF6xbRqo47lq
sISrDtSMxmORaLStu278tOAMya7fb3hDlCOx3NUs4KkXaoZUhuphg2LlAGUSsq1mJSTrlIWoqVw6
2tOItLKqtaLzAVT9SMETjLiuFPklyWmlO9AI1FwQs+t8Eb8hSQ1Dji1Kpaqgpe+dMT7EMRZQeast
jZ1F54FgsWIu9hy7C+waRDoNm/PrJ/6ufdrd8Vn9G0kirBUT7oSndW8W/bhi7w3UjmIssHp6O71d
vAKdtmGw2zd0A0NpbQNMUhkotogaaDUeNGZYgV6WnOGCIGjPvHFAFXBeFyzCt6EptZBdJCIgH0IS
7RdJxMk0eBadJYvywnMywGDXpPbFdKPQrkZmKtR9ITU58jznvPJ3rcEMHWFoeoTD+2sN4dpKh8lW
t+vWI4VWr5GLFXJ4NNruBDxzTPFhLVDn4Q4VPPUva4VpQ/x+/MEHqRljTlxfqj15LBJrscPB3j1W
eZWZLmByOcgjyszTrF+cqBO4h7feEvFCLZ41sHIsy9nSZKp61ny6A9JIMbyyiBgrDugMiYU/ei/4
pibt7OPIm+YgoVqEtYlfQyp5Bx3DCXOnzU4AaGhGJgggL9SVhMoUXNokUmZbBOD8Z2KYMSUa42jR
HcmOFWlaMpBAVsqZbJRDVjGEKBICZCAkW4wG0kqaZbIiwiz7QFN0kqhREoDExsGOg1DRIoUfSNji
7NWjU3yEZkfDHgcqx5/7ihasSNrXrBGaFlpDaSRnsrEvUQuiclMqbaQwYOAkMWgM0AwxYufkqg9d
iU1YHu+UR1P1qS0rOsysjBdAFRHXPKFJdqmfB38OC8V1TLC8yHvgNobKl+2F7RIVcuJb14YD4yD0
C5tCd68Qy1PzRDYY4MyGUboKBUhAmHzwoOWW5jZQwhkLVBIYaCgdoOnFfCUos6NW0WmqQF7aoV8u
9IXRoGydFMrJ7Da2NktzaCYSZbYQOrfwsV6zOcqttC4Vyhl5hZdZIoGzJskT7U6A/Ma099WNt5IU
MvQzUzim26LGK+FFkI5iztsPCK9VBu4eRRaXLRlCoB3YN4shzLplRlMHnEfgBd9VriPE2o19RFqh
pDG94UWdRCuQ7p7FYnz6pYRdVkZA06zMnmpjniIEPOUKD6FaKIYowSl+JTejIq+EpKOEd4M2w9kG
hk+qehTlY9txAlpVD0qQeEVXMZ3L2lx2gWZOnwx2CRvJJbeVjzpy8lEe/kLeHOqqdl7unSdykOkj
cSTOIDbCotxF9D57QLBq9PpdZIAcEct37zKL33R9+iILQpaGQTW90Cz4ZrJ0V3IkZWyIrFSIVIyk
MonQjHneqBSQSy0QdWsjtRsJT4D/F3JFOFCQE1aFTQ==

From dlitz at dlitz.net  Sun Mar  2 18:25:43 2008
From: dlitz at dlitz.net (Dwayne C. Litzenberger)
Date: Sun, 2 Mar 2008 20:25:43 -0600
Subject: [paramiko] PySFTPd (was: basic paramiko based SFTP server)
In-Reply-To: <200802270834.20742.dwayne@oscl.ca>
References: <48224a820802270415p6c969798i1a82b8e56831a1be@mail.gmail.com>
	<200802270834.20742.dwayne@oscl.ca>
Message-ID: <20080303022543.GA32654@rivest.dlitz.net>

On Wed, Feb 27, 2008 at 08:34:20AM -0600, Dwayne Litzenberger wrote:
>On February 27, 2008 06:15:54 am Deepak Rokade wrote:
>> Hi
>> I am in search of paramiko based basic SFTP server which will be able to
>> handle basic file transfer commands.
>> Since I need it just for testing purpose I am avoiding writing the
>> comeplete server.
>> Is such SFTP server readily available ?
>
>Not that I've found.  I have one that's mostly-written, but I probably won't 
>have time to release it for a week or two.

It's called PySFTPd, and it can be found here:

     http://www.dlitz.net/software/pysftpd/

Some caveats:

     - It's alpha-quality; It might have bugs.

     - It's sparsely documented.

     - It currently only supports read-only operation (though you can extend 
       it fairly easily to support read-write operations)

     - The --chroot option probably won't work unless you apply my last 
       patch against paramiko.  Note that you don't need --chroot to 
       restrict individual users to particular directories.
     
     - It's licensed under GPL >= 3

Comments/suggestions/vulnerability reports/patches are welcome.

SHA256SUMS:
29228bdaad834fd2a9b8befbb47862b6f1c1d24089e4e6c2defd1da06ec77f76 *PySFTPd-0.1.0.tar.gz

-- 
Dwayne C. Litzenberger <dlitz at dlitz.net>


From jhcook at gmail.com  Tue Mar  4 00:44:53 2008
From: jhcook at gmail.com (Justin Cook)
Date: Tue, 4 Mar 2008 08:44:53 +0000
Subject: [paramiko] Handling sudo
In-Reply-To: <fa2952810803031914q59f636afj2861601eadb622bd@mail.gmail.com>
References: <f5f1ebf70802260316j6457e954i27a6f1139affe2a3@mail.gmail.com>
	<fa2952810802260410x2babea1dlff9495eb77262fff@mail.gmail.com>
	<f5f1ebf70802260632u5725e85fgf22f59b238a0b565@mail.gmail.com>
	<fa2952810803031914q59f636afj2861601eadb622bd@mail.gmail.com>
Message-ID: <f5f1ebf70803040044l37d48587ide06f3b320c6d112@mail.gmail.com>

Yes,

I have it working. I developed a class using some of the code from one
of the demo files. This sudo_command function in the class does not
handle interactive commands, but works well with simply executing a
process as sudo. It's not finished yet and uses logging facility, but
can easily be modified to say, return a file with sterr and stout. It
does return the return code which is useful.

I tried to handle the different use cases of sudo, for instance if the
user does not have a valid timestamp, if the user is not in sudoers
file or if the user has no permissions to execute that command. Also,
this class does not use passwd auth for SSH -- only agent -- but that
can easily be placed in with the demo code quite easily.

Once I have time to actually have this polished off I will submit it
for inclusion in the demo directory with paramiko, but if you want to
use it for now, let me know how you fair. It's pretty straightforward,
you just need your agent running. It's been used on Linux.

[code]
#!/bin/env python2.5

import os
import sys
import getpass
from Connection import *

password = getpass.getpass('Enter password for %s: ' % os.getlogin())
conn = Connection('ttraflonrh20', 22)
try:
     conn.connect(os.getlogin(), password)
except ConnectionError, e:
     print 'Could not connect to host: %s' % str(e)
     sys.exit(-1)
try:
     exitcode = conn.sudo_command('ls -l /root')
except ConnectionError, e:
     print 'Could not execute sudo command: %s' % e
     sys.exit(-1)

print exitcode
sys.exit(0)

[/code]

Yields the following:
$ ./test.py
Enter password for justinc:
0

If you want to retrieve the output you will have to modify the code or
setup the global logging facility in which case all the paramiko and
data returned from the host will be logged to whichever file you
choose. Like I mentioned, it should return an exit code and file
descriptors of stout and sterr so the class will be programmer
friendly.

Obviously, this is still a work in progress such as no close()
function yet, but if you want to just strip out the sudo_command
function and modify it, let me know how you get on.

Cheers,

On Tue, Mar 4, 2008 at 3:14 AM, Jon Sabo <jonathan.sabo at gmail.com> wrote:
> Hey did you get it working?

-- 
Justin Cook
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Connection.py
Url: http://www.lag.net/pipermail/paramiko/attachments/20080304/cf5e75b6/attachment.txt 

From jbardin at bu.edu  Tue Mar  4 09:59:40 2008
From: jbardin at bu.edu (James Bardin)
Date: Tue, 04 Mar 2008 12:59:40 -0500
Subject: [paramiko] mpc
In-Reply-To: <f5f1ebf70803040841g6131c590n6f4c4bdaca8038c2@mail.gmail.com>
References: <f5f1ebf70803040841g6131c590n6f4c4bdaca8038c2@mail.gmail.com>
Message-ID: <47CD8E0C.1070302@bu.edu>

Hello,

To anyone that may be using the mpc program I posted a while back, I
decided to put it up on launchpad for easy access. PyMPC is a program to
run ssh in parallel to a number of hosts. It's very different from the
version posted last year, so please read the config file mpc.cfg, and
the mpclib docstring (or run 'mpc -h')

The main branch is at
'bzr branch http://bazaar.launchpad.net/~jbardin/pympc/main'

And the tarball is at:
https://launchpad.net/pympc/trunk/2.9.5/+download/pympc-2.9.5.tgz


Thanks
-jim



From k12umm at gmail.com  Tue Mar  4 16:33:32 2008
From: k12umm at gmail.com (Stan)
Date: Wed, 5 Mar 2008 11:33:32 +1100
Subject: [paramiko] Handling sudo
In-Reply-To: <47CDEA0A.2000502@al.com.au>
References: <f5f1ebf70802260316j6457e954i27a6f1139affe2a3@mail.gmail.com>
	<fa2952810802260410x2babea1dlff9495eb77262fff@mail.gmail.com>
	<f5f1ebf70802260555h6544c59u187b54117aba2b5c@mail.gmail.com>
	<f5f1ebf70802260625td4a7cb8i28d3b54e1da3d240@mail.gmail.com>
	<47C4B100.5070305@al.com.au> <47CDE676.3060002@al.com.au>
	<47CDE73D.80003@al.com.au> <47CDEA0A.2000502@al.com.au>
Message-ID: <ff64a03a0803041633k416fc377h95e79b2c675eaa1e@mail.gmail.com>

Cant you just pipe the password and grab the outputs/readlines? For example
the command i have to run as sudo = rsh dunebot cifs top
so I just send the command = echo mysuperhardpassword | sudo -S rsh dunebot
cifs top
and that seems to work in normal ssh.


>>> Justin Cook wrote:
>>>> Ok, I'm an idiot. Password prompt goes to stderr...
>>>>
>>>> On Tue, Feb 26, 2008 at 1:55 PM, Justin Cook <jhcook at gmail.com> wrote:
>>>>
>>>>> There are a couple ways I can see to do it readily offhand. One, I
>>>>>  haven't figured out how to receive the sudo password prompt yet.
>>>>>  Apparently, it writes the password prompt to a terminal device. So,
>>>>>  you should be able to set an alarm and send the password down the
>>>>>  channel in event there is no response from the command. This is
>>>>> dirty
>>>>>  IMO.
>>>>>
>>>>>  Secondly, and perhaps more clean to use in conjunction with the
>>>>> first
>>>>>  option, is to use the -k or -K option to invalidate the sudo
>>>>> timestamp
>>>>>  and thus requiring to send the password on every invocation and not
>>>>>  worry about whether or not you've been prompted. However, this isn't
>>>>>  very clean either in case no password is required.
>>>>>
>>>>>  Not a good solution in either respect in my opinion. If this can be
>>>>>  done easily with SSHClient someone shoot me in the foot!
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>> "Formulations of number theory: Complete, Consistent, Non-trivial.
>>> Choose two."
>>
>> --
>> "Formulations of number theory: Complete, Consistent, Non-trivial.
>> Choose two."
>

--
"Formulations of number theory: Complete, Consistent, Non-trivial. Choose
two."


Animal Logic
http://www.animallogic.com

Please think of the environment before printing this email.

This email and any attachments may be confidential and/or privileged. If you
are not the intended recipient of this email, you must not disclose or use
the information contained in it. Please notify the sender immediately and
delete this document if you have received it in error. We do not guarantee
this email is error or virus free.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.lag.net/pipermail/paramiko/attachments/20080305/6145dcde/attachment.htm 

From jonathan.sabo at gmail.com  Tue Mar  4 20:14:04 2008
From: jonathan.sabo at gmail.com (Jon Sabo)
Date: Tue, 4 Mar 2008 23:14:04 -0500
Subject: [paramiko] Handling sudo
In-Reply-To: <ff64a03a0803041633k416fc377h95e79b2c675eaa1e@mail.gmail.com>
References: <f5f1ebf70802260316j6457e954i27a6f1139affe2a3@mail.gmail.com>
	<fa2952810802260410x2babea1dlff9495eb77262fff@mail.gmail.com>
	<f5f1ebf70802260555h6544c59u187b54117aba2b5c@mail.gmail.com>
	<f5f1ebf70802260625td4a7cb8i28d3b54e1da3d240@mail.gmail.com>
	<47C4B100.5070305@al.com.au> <47CDE676.3060002@al.com.au>
	<47CDE73D.80003@al.com.au> <47CDEA0A.2000502@al.com.au>
	<ff64a03a0803041633k416fc377h95e79b2c675eaa1e@mail.gmail.com>
Message-ID: <fa2952810803042014i71147db7heade1aa6b4236b9@mail.gmail.com>

You could put it in a file and then cat the file so every other user
on the box can't see your password with ps -ef.

2008/3/4 Stan <k12umm at gmail.com>:
> Cant you just pipe the password and grab the outputs/readlines? For example
> the command i have to run as sudo = rsh dunebot cifs top
> so I just send the command = echo mysuperhardpassword | sudo -S rsh dunebot
> cifs top
>  and that seems to work in normal ssh.
>
>
>
>  >>> Justin Cook wrote:
>  >>>> Ok, I'm an idiot. Password prompt goes to stderr...
>  >>>>
>  >>>> On Tue, Feb 26, 2008 at 1:55 PM, Justin Cook <jhcook at gmail.com> wrote:
>  >>>>
>  >>>>> There are a couple ways I can see to do it readily offhand. One, I
>  >>>>>  haven't figured out how to receive the sudo password prompt yet.
>  >>>>>  Apparently, it writes the password prompt to a terminal device. So,
>  >>>>>  you should be able to set an alarm and send the password down the
>  >>>>>  channel in event there is no response from the command. This is
>  >>>>> dirty
>  >>>>>  IMO.
>  >>>>>
>  >>>>>  Secondly, and perhaps more clean to use in conjunction with the
>  >>>>> first
>  >>>>>  option, is to use the -k or -K option to invalidate the sudo
>  >>>>> timestamp
>  >>>>>  and thus requiring to send the password on every invocation and not
>  >>>>>  worry about whether or not you've been prompted. However, this isn't
>  >>>>>  very clean either in case no password is required.
>  >>>>>
>  >>>>>  Not a good solution in either respect in my opinion. If this can be
>  >>>>>  done easily with SSHClient someone shoot me in the foot!
>  >>>>>
>  >>>>
>  >>>>
>  >>>>
>  >>>>
>  >>>
>  >>> --
>  >>> "Formulations of number theory: Complete, Consistent, Non-trivial.
>  >>> Choose two."
>  >>
>  >> --
>  >> "Formulations of number theory: Complete, Consistent, Non-trivial.
>  >> Choose two."
>  >
>
>  --
>  "Formulations of number theory: Complete, Consistent, Non-trivial. Choose
> two."
>
>
>  Animal Logic
>  http://www.animallogic.com
>
>  Please think of the environment before printing this email.
>
>  This email and any attachments may be confidential and/or privileged. If
> you are not the intended recipient of this email, you must not disclose or
> use the information contained in it. Please notify the sender immediately
> and delete this document if you have received it in error. We do not
> guarantee this email is error or virus free.
>
>
>
>
>
> _______________________________________________
>  paramiko mailing list
>  paramiko at lag.net
>  http://www.lag.net/cgi-bin/mailman/listinfo/paramiko
>


From karmazilla at gmail.com  Wed Mar  5 02:38:17 2008
From: karmazilla at gmail.com (Christian Vest Hansen)
Date: Wed, 5 Mar 2008 11:38:17 +0100
Subject: [paramiko] Handling sudo
In-Reply-To: <fa2952810803042014i71147db7heade1aa6b4236b9@mail.gmail.com>
References: <f5f1ebf70802260316j6457e954i27a6f1139affe2a3@mail.gmail.com>
	<fa2952810802260410x2babea1dlff9495eb77262fff@mail.gmail.com>
	<f5f1ebf70802260555h6544c59u187b54117aba2b5c@mail.gmail.com>
	<f5f1ebf70802260625td4a7cb8i28d3b54e1da3d240@mail.gmail.com>
	<47C4B100.5070305@al.com.au> <47CDE676.3060002@al.com.au>
	<47CDE73D.80003@al.com.au> <47CDEA0A.2000502@al.com.au>
	<ff64a03a0803041633k416fc377h95e79b2c675eaa1e@mail.gmail.com>
	<fa2952810803042014i71147db7heade1aa6b4236b9@mail.gmail.com>
Message-ID: <90622e530803050238p265a2f74of7acc04343dcd761@mail.gmail.com>

On 3/5/08, Jon Sabo <jonathan.sabo at gmail.com> wrote:
> You could put it in a file and then cat the file so every other user
>  on the box can't see your password with ps -ef.

But then they could read the file, no? How would guarentee -rw-------
permisions?

>
>  2008/3/4 Stan <k12umm at gmail.com>:
>
> > Cant you just pipe the password and grab the outputs/readlines? For example
>  > the command i have to run as sudo = rsh dunebot cifs top
>  > so I just send the command = echo mysuperhardpassword | sudo -S rsh dunebot
>  > cifs top
>  >  and that seems to work in normal ssh.
>  >
>  >
>  >
>  >  >>> Justin Cook wrote:
>  >  >>>> Ok, I'm an idiot. Password prompt goes to stderr...
>  >  >>>>
>  >  >>>> On Tue, Feb 26, 2008 at 1:55 PM, Justin Cook <jhcook at gmail.com> wrote:
>  >  >>>>
>  >  >>>>> There are a couple ways I can see to do it readily offhand. One, I
>  >  >>>>>  haven't figured out how to receive the sudo password prompt yet.
>  >  >>>>>  Apparently, it writes the password prompt to a terminal device. So,
>  >  >>>>>  you should be able to set an alarm and send the password down the
>  >  >>>>>  channel in event there is no response from the command. This is
>  >  >>>>> dirty
>  >  >>>>>  IMO.
>  >  >>>>>
>  >  >>>>>  Secondly, and perhaps more clean to use in conjunction with the
>  >  >>>>> first
>  >  >>>>>  option, is to use the -k or -K option to invalidate the sudo
>  >  >>>>> timestamp
>  >  >>>>>  and thus requiring to send the password on every invocation and not
>  >  >>>>>  worry about whether or not you've been prompted. However, this isn't
>  >  >>>>>  very clean either in case no password is required.
>  >  >>>>>
>  >  >>>>>  Not a good solution in either respect in my opinion. If this can be
>  >  >>>>>  done easily with SSHClient someone shoot me in the foot!
>  >  >>>>>
>  >  >>>>
>  >  >>>>
>  >  >>>>
>  >  >>>>
>  >  >>>
>  >  >>> --
>  >  >>> "Formulations of number theory: Complete, Consistent, Non-trivial.
>  >  >>> Choose two."
>  >  >>
>  >  >> --
>  >  >> "Formulations of number theory: Complete, Consistent, Non-trivial.
>  >  >> Choose two."
>  >  >
>  >
>  >  --
>  >  "Formulations of number theory: Complete, Consistent, Non-trivial. Choose
>  > two."
>  >
>  >
>  >  Animal Logic
>  >  http://www.animallogic.com
>  >
>  >  Please think of the environment before printing this email.
>  >
>  >  This email and any attachments may be confidential and/or privileged. If
>  > you are not the intended recipient of this email, you must not disclose or
>  > use the information contained in it. Please notify the sender immediately
>  > and delete this document if you have received it in error. We do not
>  > guarantee this email is error or virus free.
>  >
>  >
>  >
>  >
>  >
>
> > _______________________________________________
>  >  paramiko mailing list
>  >  paramiko at lag.net
>  >  http://www.lag.net/cgi-bin/mailman/listinfo/paramiko
>  >
>
>  _______________________________________________
>  paramiko mailing list
>  paramiko at lag.net
>  http://www.lag.net/cgi-bin/mailman/listinfo/paramiko
>


-- 
Venlig hilsen / Kind regards,
Christian Vest Hansen.


From jhcook at gmail.com  Tue Mar 11 06:22:20 2008
From: jhcook at gmail.com (Justin Cook)
Date: Tue, 11 Mar 2008 13:22:20 +0000
Subject: [paramiko] channel.recv_exit_status_ready()
Message-ID: <f5f1ebf70803110622r24a8aaa1q5e7af1956ea145aa@mail.gmail.com>

It would be useful to have a function added to the channel object that
provides information as to whether an exit status is available from
the server. This can be used much in the same way as the existing
channel.recv_ready(). It is quite trivial to implement, and I have
provided the diff below. Sorry for my rambling doc string. It's not
exactly accurate. @return is.

--- channel.py  2008-03-11 11:13:11.000000000 +0000
+++ channel.py.orig     2008-03-11 11:03:09.000000000 +0000
@@ -283,22 +283,6 @@
             self.status_event.wait(0.1)
         return self.exit_status

-    def recv_exit_status_ready(self):
-        """
-        Return if we have an exit status available. This is mostly useful
-        for polling if there is an exit status available. Note, the server
-        may not return an exit status for badly written code.
-
-        @return: True if an exit code maybe waiting. False if not.
-        @rtype: bool
-
-        @since: 1.7.2
-        """
-        if self.closed or self.status_event.isSet():
-                return True
-        else:
-                return False
-
     def send_exit_status(self, status):
         """
         Send the exit status of an executed command to the client.  (This

Cheers,

-- 
Justin Cook
-------------- next part --------------
A non-text attachment was scrubbed...
Name: channel.py.diff
Type: text/x-patch
Size: 867 bytes
Desc: not available
Url : http://www.lag.net/pipermail/paramiko/attachments/20080311/bb53132b/attachment.bin 

From smartpawn at gmail.com  Sat Mar 15 06:26:26 2008
From: smartpawn at gmail.com (Deepak Rokade)
Date: Sat, 15 Mar 2008 18:56:26 +0530
Subject: [paramiko] paramiko stops responding after huge data is transferred
	!
Message-ID: <48224a820803150626k10c6054eld26ba1390b451d61@mail.gmail.com>

Hi All,
I am using paramiko 1.5.3 in my python application.
I found that when large data is fetched using paramiko with prefetch,
deadlock condition occurs.
I found through paramiko debug level logs, that deadlock occurs when
paramiko goes for rekeying.
Below is the paramiko log.

DEB [20080315-18:27:58.843] thr=1   paramiko.transport: Rekeying (hit 91
packets, 1051212 bytes received)

Above is the last log I saw after which my application stopped responding.

For reproducing deadlock quickly, I had set the low limit for REKEY_PACKETS.
I set the limit as
    REKEY_PACKETS = pow(2, 20)
    REKEY_BYTES = pow(2, 20)
(In file paramiko/packet.py , class Packetizer)


For tackling this problem I close connections periodically.
Has this problem been solved in later verion of paramiko ?.

I tried paramiko 1.7.1 for short test in which I did not observe deadlock
condition even after setting REKEY_PACKETS limit.
Below are the debug logs.

DEB [20080315-18:23:00.193] thr=6   paramiko.transport: Switch to new keys
...
DEB [20080315-18:23:00.467] thr=6   paramiko.transport: Rekeying (hit 91
packets, 1049340 bytes received)
DEB [20080315-18:23:00.571] thr=6   paramiko.transport: kex
algos:['diffie-hellman-group-exchange-sha1', 'diffie-hellman-group1-sha1']
server
 key:['ssh-rsa', 'ssh-dss'] client encrypt:['aes128-cbc', '3des-cbc',
'blowfish-cbc', 'cast128-cbc', '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-cb
c', '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-ripemd1
60', 'hmac-ripemd160 at openssh.com', 'hmac-sha1-96', 'hmac-md5-96'] client
compress:['none', 'zlib'] server compress:['none', 'zlib'] client la


However I am not sure if this problem is actually solved in version 1.7.1
Please guide.


-- 
Thanx & Regards,
Deepak Rokade

Do what u Enjoy &
               Enjoy what u Do...........
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.lag.net/pipermail/paramiko/attachments/20080315/0bad97b5/attachment.htm 

From dwayne at oscl.ca  Mon Mar 17 08:37:43 2008
From: dwayne at oscl.ca (Dwayne Litzenberger)
Date: Mon, 17 Mar 2008 09:37:43 -0600
Subject: [paramiko] paramiko stops responding after huge data is
	transferred !
In-Reply-To: <48224a820803150626k10c6054eld26ba1390b451d61@mail.gmail.com>
References: <48224a820803150626k10c6054eld26ba1390b451d61@mail.gmail.com>
Message-ID: <200803170937.45352.dwayne@oscl.ca>

I saw this behaviour too, recently.  I was going to see if I could reproduce 
it, but apparently you've done that for me.

On March 15, 2008 07:26:26 am Deepak Rokade wrote:
> Hi All,
> I am using paramiko 1.5.3 in my python application.
> I found that when large data is fetched using paramiko with prefetch,
> deadlock condition occurs.
> I found through paramiko debug level logs, that deadlock occurs when
> paramiko goes for rekeying.
> Below is the paramiko log.
>
> DEB [20080315-18:27:58.843] thr=1   paramiko.transport: Rekeying (hit 91
> packets, 1051212 bytes received)
>
> Above is the last log I saw after which my application stopped responding.
>
> For reproducing deadlock quickly, I had set the low limit for
> REKEY_PACKETS. I set the limit as
>     REKEY_PACKETS = pow(2, 20)
>     REKEY_BYTES = pow(2, 20)
> (In file paramiko/packet.py , class Packetizer)
>
>
> For tackling this problem I close connections periodically.
> Has this problem been solved in later verion of paramiko ?.
>
> I tried paramiko 1.7.1 for short test in which I did not observe deadlock
> condition even after setting REKEY_PACKETS limit.
> Below are the debug logs.
>
> DEB [20080315-18:23:00.193] thr=6   paramiko.transport: Switch to new keys
> ...
> DEB [20080315-18:23:00.467] thr=6   paramiko.transport: Rekeying (hit 91
> packets, 1049340 bytes received)
> DEB [20080315-18:23:00.571] thr=6   paramiko.transport: kex
> algos:['diffie-hellman-group-exchange-sha1', 'diffie-hellman-group1-sha1']
> server
>  key:['ssh-rsa', 'ssh-dss'] client encrypt:['aes128-cbc', '3des-cbc',
> 'blowfish-cbc', 'cast128-cbc', '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-cb
> c', '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-ripemd1
> 60', 'hmac-ripemd160 at openssh.com', 'hmac-sha1-96', 'hmac-md5-96'] client
> compress:['none', 'zlib'] server compress:['none', 'zlib'] client la
>
>
> However I am not sure if this problem is actually solved in version 1.7.1
> Please guide.



-- 
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 jhcook at gmail.com  Tue Mar 18 09:30:05 2008
From: jhcook at gmail.com (Justin Cook)
Date: Tue, 18 Mar 2008 16:30:05 +0000
Subject: [paramiko] transport threads not shutting down
Message-ID: <f5f1ebf70803180930i60c47c32t9c3f1b98c20b55a@mail.gmail.com>

After calling transport.close(), it appears the transport threads are
not stopping in a timely manner. Furthermore, the socket module is
being destroyed before the thread stops / exits. Obviously this is at
interpreter shutdown. Sometimes I receive the following exception at
program exit:

Exception in thread Thread-1 (most likely raised during interpreter shutdown):
Traceback (most recent call last):
  File "/usr/local/lib/python2.5/threading.py", line 486, in __bootstrap_inner
  File "/usr/local/lib/python2.5/site-packages/paramiko/transport.py",
line 1505, in run
<type 'exceptions.AttributeError'>: 'NoneType' object has no attribute 'error'
Unhandled exception in thread started by
Error in sys.excepthook:

Original exception was:

Am I missing something?

-- 
Justin Cook


From dwayne at oscl.ca  Wed Mar 19 09:20:58 2008
From: dwayne at oscl.ca (Dwayne Litzenberger)
Date: Wed, 19 Mar 2008 10:20:58 -0600
Subject: [paramiko] transport threads not shutting down
In-Reply-To: <f5f1ebf70803180930i60c47c32t9c3f1b98c20b55a@mail.gmail.com>
References: <f5f1ebf70803180930i60c47c32t9c3f1b98c20b55a@mail.gmail.com>
Message-ID: <200803191021.00049.dwayne@oscl.ca>

On March 18, 2008 10:30:05 am Justin Cook wrote:
> After calling transport.close(), it appears the transport threads are
> not stopping in a timely manner.

Are you explicitly calling transport.close() during normal program execution, 
or is this during __del__  or atexit processing?


-- 
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 jhcook at gmail.com  Wed Mar 19 09:27:56 2008
From: jhcook at gmail.com (Justin Cook)
Date: Wed, 19 Mar 2008 16:27:56 +0000
Subject: [paramiko] transport threads not shutting down
In-Reply-To: <200803191021.00049.dwayne@oscl.ca>
References: <f5f1ebf70803180930i60c47c32t9c3f1b98c20b55a@mail.gmail.com>
	<200803191021.00049.dwayne@oscl.ca>
Message-ID: <f5f1ebf70803190927x6beeb058x53f627848a82f1f2@mail.gmail.com>

I've tried both ways. When the program exits, the classes __del__
method closes the transport. I've even tried atexit handling it. It's
not every time. Just sometimes this happens. Just weird why the socket
module would be destroyed while the thread is still running.

On Wed, Mar 19, 2008 at 4:20 PM, Dwayne Litzenberger <dwayne at oscl.ca> wrote:
> On March 18, 2008 10:30:05 am Justin Cook wrote:
>  > After calling transport.close(), it appears the transport threads are
>  > not stopping in a timely manner.
>
>  Are you explicitly calling transport.close() during normal program execution,
>  or is this during __del__  or atexit processing?


-- 
Justin Cook


From dwayne at oscl.ca  Wed Mar 19 09:45:26 2008
From: dwayne at oscl.ca (Dwayne Litzenberger)
Date: Wed, 19 Mar 2008 10:45:26 -0600
Subject: [paramiko] transport threads not shutting down
In-Reply-To: <f5f1ebf70803190927x6beeb058x53f627848a82f1f2@mail.gmail.com>
References: <f5f1ebf70803180930i60c47c32t9c3f1b98c20b55a@mail.gmail.com>
	<200803191021.00049.dwayne@oscl.ca>
	<f5f1ebf70803190927x6beeb058x53f627848a82f1f2@mail.gmail.com>
Message-ID: <200803191045.26493.dwayne@oscl.ca>

There are three ways to close a transport:

1. transport.close()
2. __del__
3. atexit

If you're using #2 or #3, it's more-or-less known Python behaviour (see 
http://www.thescripts.com/forum/thread41024.html).  There are ways of 
modifying the code so that it doesn't happen, but it could possibly take a 
lot of work and make the code a lot uglier (it involves avoiding the use of 
_any_ globals in code paths that might be called from __del__ or atexit).  As 
a rule, you shouldn't rely on the garbage collector to take care of cleaning 
up threads and other complicated tasks.

#1 should always work properly, though.

Could you build a test script that we can use to reproduce this problem?


On March 19, 2008 10:27:56 am Justin Cook wrote:
> I've tried both ways. When the program exits, the classes __del__
> method closes the transport. I've even tried atexit handling it. It's
> not every time. Just sometimes this happens. Just weird why the socket
> module would be destroyed while the thread is still running.
>
> On Wed, Mar 19, 2008 at 4:20 PM, Dwayne Litzenberger <dwayne at oscl.ca> wrote:
> > On March 18, 2008 10:30:05 am Justin Cook wrote:
> >  > After calling transport.close(), it appears the transport threads are
> >  > not stopping in a timely manner.
> >
> >  Are you explicitly calling transport.close() during normal program
> > execution, or is this during __del__  or atexit processing?


-- 
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 robey at lag.net  Sat Mar 22 14:23:36 2008
From: robey at lag.net (Robey Pointer)
Date: Sat, 22 Mar 2008 14:23:36 -0700
Subject: [paramiko] www.lag.net server issue?
In-Reply-To: <20080219060239.GA7263@rivest.dlitz.net>
References: <799406d60802141313g334d17d3ia7f87762ff34c831@mail.gmail.com>
	<799406d60802141339t5b6d18d2y6d5fc714dc0dc098@mail.gmail.com>
	<148F1BEC-1219-40B8-852C-249AE5909E6F@lag.net>
	<20080219060239.GA7263@rivest.dlitz.net>
Message-ID: <E2A7455B-1F15-43BB-92A7-A82B888E9730@lag.net>

On 18 Feb 2008, at 22:02, Dwayne C. Litzenberger wrote:

> On Sun, Feb 17, 2008 at 04:21:38PM -0800, Robey Pointer wrote:
>>> Fetching failed:: peer certificate cannot be authenticated with  
>>> known
>>> CA certificates
>>
>> Another good example of why SSH is a superior protocol to SSL. I'm  
>> not
>> going to pay thousands of dollars to a financial corporation just to
>> have the "right kind" of cert. Therefore self-signed certs are a fact
>> of life, and all these SSL clients complaining about them just make
>> SSL look confusing to end users.
>
> Robey,
>
> For somebody browsing on an open wi-fi network---particularly  
> someone who
> has never visited www.lag.net before---the "right kind" of SSL certs
> provide a useful service: They make it much more difficult for an  
> attacker
> on the local wireless LAN to substitute your software with a modified
> version, and they would make it possible to bootstrap trust for your  
> public
> GPG key.  In this use case, self-signed certificates are just as  
> useful as
> the practice of _not_ checking SSH host keys: They provide a false  
> sense of
> security, and completely fail to address the bootstrapping problem.

Sorry for the late reply. Unfortunately because of the cost issue,  
self-signed certs need to be presented to the user, and need to be  
cached by the browser. Not doing so makes SSL operate worse than SSH,  
since SSH *does* present the key to the user and cache it. I realize  
that SSL is trying to enforce security through a hierarchy of cash  
registers, but it's just not a practical solution for casual users  
(like me).


> If you shop around, you can get an annual SSL cert for less than US 
> $100
> (http://www.rapidssl.com/ currently advertises US$69/year).

I did actually look at some of the sites offering free certs, but none  
of them appeared to be listed in my browser's CA list, which would  
seem to take away some of the usefulness.


> As the maintainer of an important cryptography library, you should be
> providing _some_ means for end-users and distributors to verify that  
> the
> software they download is the same software you release.

I do give MD5s, but you're right, signing would be better. I will make  
a note to post GPG signatures with the next release.

I'm moderately surprised that you're the first person to point this  
out, since it seems like an obvious gap in retrospect. :)

robey



From robey at lag.net  Sat Mar 22 14:54:42 2008
From: robey at lag.net (Robey Pointer)
Date: Sat, 22 Mar 2008 14:54:42 -0700
Subject: [paramiko] [PATCH] osrandom doesn't work nicely in chroot()
	environment
In-Reply-To: <20080302064435.GA12173@rivest.dlitz.net>
References: <20080302064435.GA12173@rivest.dlitz.net>
Message-ID: <4ED4E5A5-4B66-4678-84DD-5AAA11310105@lag.net>

On 1 Mar 2008, at 22:44, Dwayne C. Litzenberger wrote:

> I'm implementing an SFTP server for paramiko, and this server  
> supports chroot()ing into an individual user's home directory.
>
> Unfortunately, once you do os.chroot(), os.urandom() fails with  
> NotImplementedError:
>
>    >>> import paramiko, os
>    >>> paramiko.randpool.get_bytes(4)
>    '@\x92:\xa7'
>    >>> os.chroot("/home/dwon")
>    >>> paramiko.randpool.get_bytes(4)
>    Traceback (most recent call last):
>      File "<stdin>", line 1, in ?
>      File "os.py", line 720, in urandom
>    NotImplementedError: /dev/urandom (or equivalent) not found
>
> I've attached a patch that works around this problem by making
> OSRandomPool automatically fall back to using a previously-opened  
> file descriptor connected to /dev/urandom.  The result is that if  
> you import the paramiko module before performing os.chroot(),  
> paramiko is still able to get random numbers.
>
> This patch has not been tested on win32.  Someone should do that  
> before the next paramiko release, as I am known to have typos in my  
> patches. :)

Looks okay to me. Actually, looking at the source for os.urandom, we  
might as well skip that part entirely. It's not doing anything more  
than you're doing, except they don't keep the file open.

The tests pass, so I'm committing it like that (with os.urandom  
removed). I'll test it out in a Windows VM before releasing.

robey



From robey at lag.net  Sat Mar 22 19:06:42 2008
From: robey at lag.net (Robey Pointer)
Date: Sat, 22 Mar 2008 19:06:42 -0700
Subject: [paramiko] paramiko stops responding after huge data is
	transferred !
In-Reply-To: <48224a820803150626k10c6054eld26ba1390b451d61@mail.gmail.com>
References: <48224a820803150626k10c6054eld26ba1390b451d61@mail.gmail.com>
Message-ID: <78A450CD-29CF-4373-8846-38F8F8333775@lag.net>

On 15 Mar 2008, at 6:26, Deepak Rokade wrote:

> Hi All,
> I am using paramiko 1.5.3 in my python application.
> I found that when large data is fetched using paramiko with  
> prefetch, deadlock condition occurs.
> I found through paramiko debug level logs, that deadlock occurs when  
> paramiko goes for rekeying.
> Below is the paramiko log.
>
> DEB [20080315-18:27:58.843] thr=1   paramiko.transport: Rekeying  
> (hit 91 packets, 1051212 bytes received)
>
> Above is the last log I saw after which my application stopped  
> responding.
>
> For reproducing deadlock quickly, I had set the low limit for  
> REKEY_PACKETS.
> I set the limit as
>     REKEY_PACKETS = pow(2, 20)
>     REKEY_BYTES = pow(2, 20)
> (In file paramiko/packet.py , class Packetizer)
>
>
> For tackling this problem I close connections periodically.
> Has this problem been solved in later verion of paramiko ?.
>
> I tried paramiko 1.7.1 for short test in which I did not observe  
> deadlock condition even after setting REKEY_PACKETS limit.

Sounds like it's fixed, then. Version 1.5.3 is from over 2 years ago,  
so a lot has changed, and some of the changed code is related to  
prefetch.

Just to be safe, I added some more code to the "renegotiate while  
sending large files" test, to make it renegotiate while receiving a  
large file too.

If you can reproduce the problem against the current release, please  
send me some code to reproduce, and I'll try to figure it out.  
Anything you think should be in the unit tests, that isn't, would also  
be great. :)

robey



From robey at lag.net  Sat Mar 22 19:08:00 2008
From: robey at lag.net (Robey Pointer)
Date: Sat, 22 Mar 2008 19:08:00 -0700
Subject: [paramiko] channel.recv_exit_status_ready()
In-Reply-To: <f5f1ebf70803110622r24a8aaa1q5e7af1956ea145aa@mail.gmail.com>
References: <f5f1ebf70803110622r24a8aaa1q5e7af1956ea145aa@mail.gmail.com>
Message-ID: <8FE0134B-9FC3-4826-9305-BDFDBC631240@lag.net>

On 11 Mar 2008, at 6:22, Justin Cook wrote:

> It would be useful to have a function added to the channel object that
> provides information as to whether an exit status is available from
> the server. This can be used much in the same way as the existing
> channel.recv_ready(). It is quite trivial to implement, and I have
> provided the diff below. Sorry for my rambling doc string. It's not
> exactly accurate. @return is.

I tweaked it a bit, renamed it to "exit_status_ready", and committed.

robey



From robey at lag.net  Sat Mar 22 19:14:57 2008
From: robey at lag.net (Robey Pointer)
Date: Sat, 22 Mar 2008 19:14:57 -0700
Subject: [paramiko] PySFTPd (was: basic paramiko based SFTP server)
In-Reply-To: <20080303022543.GA32654@rivest.dlitz.net>
References: <48224a820802270415p6c969798i1a82b8e56831a1be@mail.gmail.com>
	<200802270834.20742.dwayne@oscl.ca>
	<20080303022543.GA32654@rivest.dlitz.net>
Message-ID: <9426F22F-8278-4230-B988-FAFF45C53C4B@lag.net>

On 2 Mar 2008, at 18:25, Dwayne C. Litzenberger wrote:

> On Wed, Feb 27, 2008 at 08:34:20AM -0600, Dwayne Litzenberger wrote:
>> On February 27, 2008 06:15:54 am Deepak Rokade wrote:
>>> Hi
>>> I am in search of paramiko based basic SFTP server which will be  
>>> able to
>>> handle basic file transfer commands.
>>> Since I need it just for testing purpose I am avoiding writing the
>>> comeplete server.
>>> Is such SFTP server readily available ?
>>
>> Not that I've found.  I have one that's mostly-written, but I  
>> probably won't
>> have time to release it for a week or two.
>
> It's called PySFTPd, and it can be found here:
>
>     http://www.dlitz.net/software/pysftpd/

I had the beginnings of an sftpd server, too, at a bazaar branch here:

     http://www.lag.net/robey/code/vault/

Feel free to borrow any chunks of it that are useful. I never got very  
far and long since abandoned it. PySFTPd looks a lot further along  
than I got.

robey



From robey at lag.net  Mon Mar 24 00:28:04 2008
From: robey at lag.net (Robey Pointer)
Date: Mon, 24 Mar 2008 00:28:04 -0700
Subject: [paramiko] release: paramiko 1.7.3
Message-ID: <8F6D9F39-5CC2-4124-A8F7-C54634E453A0@lag.net>

This took a lot longer than I meant to -- I got caught up in the new  
job.

Paramiko 1.7.3 "Clara" is released:
    http://www.lag.net/paramiko/

The signature for the zip file is posted online, and attached.

This is mostly bug fixes (some pretty important) and a few new features.


v1.7.3 (Clara) 23mar08
----------------------
   * SSHClient can be asked not to use an SSH agent now, and not to  
search
     for private keys
   * added WarningPolicy option for SSHClient (warn, but allow, on  
unknown
     server keys)
   * added Channel.exit_status_ready to poll if a channel has received  
an
     exit status yet
   * new demo for reverse port forwarding
   * (bug 177117) fix UTF-8 passwords
   * (bug 189466) fix typo in osrandom.py
   * (bug 191657) potentially fix a race at channel shutdown
   * (bug 192749) document that SSHClient.connect may raise socket.error
   * (bug 193779) translate EOFError into AuthException during  
authentication
   * (bug 200416) don't create a new logger object for each channel


Clara wasted away.

robey

-------------- next part --------------
A non-text attachment was scrubbed...
Name: paramiko-1.7.3.zip.asc
Type: application/octet-stream
Size: 194 bytes
Desc: not available
Url : http://www.lag.net/pipermail/paramiko/attachments/20080324/51777d10/attachment.obj 
-------------- next part --------------


From eric.noulard at gmail.com  Mon Mar 24 03:24:22 2008
From: eric.noulard at gmail.com (Eric Noulard)
Date: Mon, 24 Mar 2008 11:24:22 +0100
Subject: [paramiko] Howto implement client-side X11 forwarding?
Message-ID: <cbe23c50803240324j4af6991bv5258aed6fb23ce80@mail.gmail.com>

Hi all,

I did already ask this on launchpad
(https://answers.launchpad.net/paramiko/+question/27775)
but since I don't know whether if it's effectively used or not
I may cross-post here.

>>>>>>>>>>>

I do use paramiko as client SSH using

SSHClient and SSHShell.

As soon as I do call SSHShell.request_x11()
I do get
 File "/var/lib/python-support/python2.4/paramiko/channel.py", line
367, in request_x11
   self._wait_for_event()
 File "/var/lib/python-support/python2.4/paramiko/channel.py", line
1062, in _wait_for_event
   raise e
SSHException: Channel closed.

My need is to be able to:

SSHClient.invoke_shell('vt100',80,300)
then
SSHShell.request_x11()
then
SSHShell.send(/usr/bin/xterm)

Using this I want the remote xterm command to access
the local X11 server in order to display the xterm window.

My local X11 server accept X11 forward.
At least the following command

ssh me at remotehost /usr/bin/xterm

works as expected.

I'm certainly missunderstanding the way X11 forwarding work
would anybody help me with an example on how to do that?



-- 
Erk


From tkapoor at wscm.net  Tue Mar 25 07:52:57 2008
From: tkapoor at wscm.net (Tarun Kapoor)
Date: Tue, 25 Mar 2008 09:52:57 -0500
Subject: [paramiko] Paramiko bugs out on windows 2003 server
Message-ID: <C1E12E3378F89C4DA422B4089741418408B199@wscmmail.wscm.corp>

 

I am using the paramiko library to pull a data from a server using SFTP.
It works perfect on a windows xp machine but bugs out a windows 2003
server. I get the following error:

Traceback (most recent call last):

  File "S:\Temp\ftpBOA.py", line 5, in ?

    import paramiko

  File "C:\Python23\lib\paramiko\__init__.py", line 69, in ?

    from transport import randpool, SecurityOptions, Transport

  File "C:\Python23\lib\paramiko\transport.py", line 32, in ?

    from paramiko import util

  File "C:\Python23\lib\paramiko\util.py", line 31, in ?

    from paramiko.common import *

  File "C:\Python23\lib\paramiko\common.py", line 98, in ?

    from osrandom import OSRandomPool

  File "C:\Python23\lib\paramiko\osrandom.py", line 54, in ?

    raise ImportError("Cannot find OS entropy source")

ImportError: Cannot find OS entropy source

 

Anyone knows how to solve it ?

Mucho Gracias !

Tarun Kapoor

 



Disclaimer

This e-mail and any attachments is confidential and intended solely for the use of the individual(s) to whom it is addressed. Any views or opinions presented are solely those of the author and do not necessarily represent those of Waterstone Capital Management, L.P and affiliates. If you are not the intended recipient, be advised that you have received this e-mail in error and that any use, dissemination, printing, forwarding or copying of this email is strictly prohibited. Please contact the sender if you have received this e-mail in error. You should also be aware that e-mails are susceptible to interference and you should not assume that the contents of this e-mail originated from the sender above or that they have been accurately reproduced in their original form. Waterstone Capital Management, L.P. and affiliates accepts no responsibility for information, or errors or omissions in this e-mail or use or misuse thereof. If in doubt, please verify the authenticity with the sender.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.lag.net/pipermail/paramiko/attachments/20080325/e0c0d623/attachment.htm 

From dwayne at oscl.ca  Tue Mar 25 09:12:33 2008
From: dwayne at oscl.ca (Dwayne Litzenberger)
Date: Tue, 25 Mar 2008 10:12:33 -0600
Subject: [paramiko] Paramiko bugs out on windows 2003 server
In-Reply-To: <C1E12E3378F89C4DA422B4089741418408B199@wscmmail.wscm.corp>
References: <C1E12E3378F89C4DA422B4089741418408B199@wscmmail.wscm.corp>
Message-ID: <200803251012.33694.dwayne@oscl.ca>

On March 25, 2008 08:52:57 am Tarun Kapoor wrote:
> I am using the paramiko library to pull a data from a server using SFTP.
> It works perfect on a windows xp machine but bugs out a windows 2003
> server. I get the following error:
[snip]
> ImportError: Cannot find OS entropy source
>
>
>
> Anyone knows how to solve it ?

You need a newer version of Python (>= 2.4), or a modified version of PyCrypto 
that isn't missing the winrandom module.  (If you have a moment, please bug 
Andrew Kuchling <amk at amk.ca> and ask him to contact me <dlitz at dlitz.net> 
about this.  He doesn't seem to be getting my emails.)

-- 
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 tkapoor at wscm.net  Tue Mar 25 12:33:04 2008
From: tkapoor at wscm.net (Tarun Kapoor)
Date: Tue, 25 Mar 2008 14:33:04 -0500
Subject: [paramiko] Paramiko bugs out on windows 2003 server
In-Reply-To: <mailman.1.1206471605.23375.paramiko@lag.net>
References: <mailman.1.1206471605.23375.paramiko@lag.net>
Message-ID: <C1E12E3378F89C4DA422B4089741418408B1A5@wscmmail.wscm.corp>

Date: Tue, 25 Mar 2008 10:12:33 -0600
From: Dwayne Litzenberger <dwayne at oscl.ca>
Subject: Re: [paramiko] Paramiko bugs out on windows 2003 server
To: paramiko at lag.net
Message-ID: <200803251012.33694.dwayne at oscl.ca>
Content-Type: text/plain;  charset="utf-8"

On March 25, 2008 08:52:57 am Tarun Kapoor wrote:
> I am using the paramiko library to pull a data from a server using
SFTP.
> It works perfect on a windows xp machine but bugs out a windows 2003
> server. I get the following error:
[snip]
> ImportError: Cannot find OS entropy source
>
>
>
> Anyone knows how to solve it ?

You need a newer version of Python (>= 2.4), or a modified version of
PyCrypto 
that isn't missing the winrandom module.  (If you have a moment, please
bug 
Andrew Kuchling <amk at amk.ca> and ask him to contact me <dlitz at dlitz.net>

about this.  He doesn't seem to be getting my emails.)

-- 
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/


I have another machine where I have python 2.5 and latest version of
pycrypto.
Even in the latest version, PyCrypto does not have a winrandom module. I
looked around to see that is a know bug.



Disclaimer

This e-mail and any attachments is confidential and intended solely for the use of the individual(s) to whom it is addressed. Any views or opinions presented are solely those of the author and do not necessarily represent those of Waterstone Capital Management, L.P and affiliates. If you are not the intended recipient, be advised that you have received this e-mail in error and that any use, dissemination, printing, forwarding or copying of this email is strictly prohibited. Please contact the sender if you have received this e-mail in error. You should also be aware that e-mails are susceptible to interference and you should not assume that the contents of this e-mail originated from the sender above or that they have been accurately reproduced in their original form. Waterstone Capital Management, L.P. and affiliates accepts no responsibility for information, or errors or omissions in this e-mail or use or misuse thereof. If in doubt, please verify the authenticity with the sender.




From tkapoor at wscm.net  Tue Mar 25 12:34:39 2008
From: tkapoor at wscm.net (Tarun Kapoor)
Date: Tue, 25 Mar 2008 14:34:39 -0500
Subject: [paramiko] dumb question
Message-ID: <C1E12E3378F89C4DA422B4089741418408B1A6@wscmmail.wscm.corp>

Sorry for a dumb question.

 How does one reply to an existing message to make sure it becomes part
of that thread?

Tarun Kapoor



Disclaimer

This e-mail and any attachments is confidential and intended solely for the use of the individual(s) to whom it is addressed. Any views or opinions presented are solely those of the author and do not necessarily represent those of Waterstone Capital Management, L.P and affiliates. If you are not the intended recipient, be advised that you have received this e-mail in error and that any use, dissemination, printing, forwarding or copying of this email is strictly prohibited. Please contact the sender if you have received this e-mail in error. You should also be aware that e-mails are susceptible to interference and you should not assume that the contents of this e-mail originated from the sender above or that they have been accurately reproduced in their original form. Waterstone Capital Management, L.P. and affiliates accepts no responsibility for information, or errors or omissions in this e-mail or use or misuse thereof. If in doubt, please verify the authenticity with the sender.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.lag.net/pipermail/paramiko/attachments/20080325/331d25ef/attachment.htm 

From robey at lag.net  Tue Mar 25 12:45:03 2008
From: robey at lag.net (Robey Pointer)
Date: Tue, 25 Mar 2008 12:45:03 -0700
Subject: [paramiko] Paramiko bugs out on windows 2003 server
In-Reply-To: <C1E12E3378F89C4DA422B4089741418408B199@wscmmail.wscm.corp>
References: <C1E12E3378F89C4DA422B4089741418408B199@wscmmail.wscm.corp>
Message-ID: <B190D3D6-37F1-49D7-9C6B-6501929C7D82@lag.net>

On Mar 25, 2008, at 7:52 AM, Tarun Kapoor wrote:
> I am using the paramiko library to pull a data from a server using  
> SFTP. It works perfect on a windows xp machine but bugs out a  
> windows 2003 server. I get the following error:
>

The line numbers don't match up with 1.7.3. Can you try against 1.7.3  
and see if you have the same error?

robey



From tkapoor at wscm.net  Tue Mar 25 12:51:33 2008
From: tkapoor at wscm.net (Tarun Kapoor)
Date: Tue, 25 Mar 2008 14:51:33 -0500
Subject: [paramiko] Paramiko bugs out on windows 2003 server
In-Reply-To: <B190D3D6-37F1-49D7-9C6B-6501929C7D82@lag.net>
References: <C1E12E3378F89C4DA422B4089741418408B199@wscmmail.wscm.corp>
	<B190D3D6-37F1-49D7-9C6B-6501929C7D82@lag.net>
Message-ID: <C1E12E3378F89C4DA422B4089741418408B1A7@wscmmail.wscm.corp>

The windows server machine has python 2.3 which cannot be upgraded
(unfortunately). So the version of paramiko and pycrypto are latest ones
I can install on python 2.3

-----Original Message-----
From: Robey Pointer [mailto:robey at lag.net] 
Sent: Tuesday, March 25, 2008 2:45 PM
To: Tarun Kapoor
Cc: paramiko at lag.net
Subject: Re: [paramiko] Paramiko bugs out on windows 2003 server

On Mar 25, 2008, at 7:52 AM, Tarun Kapoor wrote:
> I am using the paramiko library to pull a data from a server using  
> SFTP. It works perfect on a windows xp machine but bugs out a  
> windows 2003 server. I get the following error:
>

The line numbers don't match up with 1.7.3. Can you try against 1.7.3  
and see if you have the same error?

robey



Disclaimer

This e-mail and any attachments is confidential and intended solely for the use of the individual(s) to whom it is addressed. Any views or opinions presented are solely those of the author and do not necessarily represent those of Waterstone Capital Management, L.P and affiliates. If you are not the intended recipient, be advised that you have received this e-mail in error and that any use, dissemination, printing, forwarding or copying of this email is strictly prohibited. Please contact the sender if you have received this e-mail in error. You should also be aware that e-mails are susceptible to interference and you should not assume that the contents of this e-mail originated from the sender above or that they have been accurately reproduced in their original form. Waterstone Capital Management, L.P. and affiliates accepts no responsibility for information, or errors or omissions in this e-mail or use or misuse thereof. If in doubt, please verify the authenticity with the sender.




From dwayne at oscl.ca  Tue Mar 25 14:38:19 2008
From: dwayne at oscl.ca (Dwayne Litzenberger)
Date: Tue, 25 Mar 2008 15:38:19 -0600
Subject: [paramiko] Paramiko bugs out on windows 2003 server
In-Reply-To: <C1E12E3378F89C4DA422B4089741418408B1A7@wscmmail.wscm.corp>
References: <C1E12E3378F89C4DA422B4089741418408B199@wscmmail.wscm.corp>
	<B190D3D6-37F1-49D7-9C6B-6501929C7D82@lag.net>
	<C1E12E3378F89C4DA422B4089741418408B1A7@wscmmail.wscm.corp>
Message-ID: <200803251538.20820.dwayne@oscl.ca>

On March 25, 2008 01:51:33 pm Tarun Kapoor wrote:
> The windows server machine has python 2.3 which cannot be upgraded
> (unfortunately). So the version of paramiko and pycrypto are latest ones
> I can install on python 2.3

Old versions of paramiko *looked* like they were working, but would sometimes 
run totally insecurely on Win32---depending on the configuration---due to a 
lack of a strong random number generator.  See this email: 
http://www.lag.net/pipermail/paramiko/2008-January/000599.html

The newest version of paramiko detects the problem and aborts if it can't find 
a good source of random numbers.

If you can't upgrade to Python >= 2.4 and you can't install a modified version 
of PyCrypto, then there is currently no secure way to run *any version* of 
paramiko on your server, since the random number generator is very weak.  
Sorry.

I repeat: If you are getting this error with the latest version of Paramiko, 
then older versions of Paramiko might work, but they will be insecure.

-- 
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 Mar 25 14:39:52 2008
From: dwayne at oscl.ca (Dwayne Litzenberger)
Date: Tue, 25 Mar 2008 15:39:52 -0600
Subject: [paramiko] dumb question
In-Reply-To: <C1E12E3378F89C4DA422B4089741418408B1A6@wscmmail.wscm.corp>
References: <C1E12E3378F89C4DA422B4089741418408B1A6@wscmmail.wscm.corp>
Message-ID: <200803251539.53711.dwayne@oscl.ca>

On March 25, 2008 01:34:39 pm Tarun Kapoor wrote:
> Sorry for a dumb question.
>
>  How does one reply to an existing message to make sure it becomes part
> of that thread?

Just use the "reply" function of your mail client.  It will automatically add 
the necessary In-Reply-To header.


-- 
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  Fri Mar 28 10:24:23 2008
From: dwayne at oscl.ca (Dwayne Litzenberger)
Date: Fri, 28 Mar 2008 11:24:23 -0600
Subject: [paramiko] paramiko stops responding after huge data is
	transferred !
In-Reply-To: <200803170937.45352.dwayne@oscl.ca>
References: <48224a820803150626k10c6054eld26ba1390b451d61@mail.gmail.com>
	<200803170937.45352.dwayne@oscl.ca>
Message-ID: <200803281124.24380.dwayne@oscl.ca>

I just saw this problem again last night on two different machines with the 
latest code from Robey's bzr tree.  I'm working on reproducing it now.

FYI:  The client was Paramiko/Python 2.5/Win32, the server was 
Paramiko/Python2.4/Linux.

On March 17, 2008 09:37:43 am Dwayne Litzenberger wrote:
> I saw this behaviour too, recently.  I was going to see if I could
> reproduce it, but apparently you've done that for me.
>
> On March 15, 2008 07:26:26 am Deepak Rokade wrote:
> > Hi All,
> > I am using paramiko 1.5.3 in my python application.
> > I found that when large data is fetched using paramiko with prefetch,
> > deadlock condition occurs.
> > I found through paramiko debug level logs, that deadlock occurs when
> > paramiko goes for rekeying.
> > Below is the paramiko log.
> >
> > DEB [20080315-18:27:58.843] thr=1   paramiko.transport: Rekeying (hit 91
> > packets, 1051212 bytes received)
> >
> > Above is the last log I saw after which my application stopped
> > responding.
> >
> > For reproducing deadlock quickly, I had set the low limit for
> > REKEY_PACKETS. I set the limit as
> >     REKEY_PACKETS = pow(2, 20)
> >     REKEY_BYTES = pow(2, 20)
> > (In file paramiko/packet.py , class Packetizer)
> >
> >
> > For tackling this problem I close connections periodically.
> > Has this problem been solved in later verion of paramiko ?.
> >
> > I tried paramiko 1.7.1 for short test in which I did not observe deadlock
> > condition even after setting REKEY_PACKETS limit.
> > Below are the debug logs.
> >
> > DEB [20080315-18:23:00.193] thr=6   paramiko.transport: Switch to new
> > keys ...
> > DEB [20080315-18:23:00.467] thr=6   paramiko.transport: Rekeying (hit 91
> > packets, 1049340 bytes received)
> > DEB [20080315-18:23:00.571] thr=6   paramiko.transport: kex
> > algos:['diffie-hellman-group-exchange-sha1',
> > 'diffie-hellman-group1-sha1'] server
> >  key:['ssh-rsa', 'ssh-dss'] client encrypt:['aes128-cbc', '3des-cbc',
> > 'blowfish-cbc', 'cast128-cbc', '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-cb
> > c', '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-ripemd1 60', 'hmac-ripemd160 at openssh.com', 'hmac-sha1-96',
> > 'hmac-md5-96'] client compress:['none', 'zlib'] server compress:['none',
> > 'zlib'] client la
> >
> >
> > However I am not sure if this problem is actually solved in version 1.7.1
> > Please guide.



-- 
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  Fri Mar 28 13:18:43 2008
From: dwayne at oscl.ca (Dwayne Litzenberger)
Date: Fri, 28 Mar 2008 14:18:43 -0600
Subject: [paramiko] paramiko stops responding after huge data is
	transferred !
In-Reply-To: <200803281124.24380.dwayne@oscl.ca>
References: <48224a820803150626k10c6054eld26ba1390b451d61@mail.gmail.com>
	<200803170937.45352.dwayne@oscl.ca>
	<200803281124.24380.dwayne@oscl.ca>
Message-ID: <200803281418.43586.dwayne@oscl.ca>

On March 28, 2008 11:24:23 am Dwayne Litzenberger wrote:
> I just saw this problem again last night on two different machines with the
> latest code from Robey's bzr tree.  I'm working on reproducing it now.
>
> FYI:  The client was Paramiko/Python 2.5/Win32, the server was
> Paramiko/Python2.4/Linux.

To clarify, my problem has nothing to do with SFTP, and I can't reproduce it 
reliably yet (well, I can, but only on a production system).

It might be a threading issue.

-- 
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  Mon Mar 31 13:01:18 2008
From: dwayne at oscl.ca (Dwayne Litzenberger)
Date: Mon, 31 Mar 2008 14:01:18 -0600
Subject: [paramiko] paramiko stops responding after huge data is
	transferred !
In-Reply-To: <200803281418.43586.dwayne@oscl.ca>
References: <48224a820803150626k10c6054eld26ba1390b451d61@mail.gmail.com>
	<200803281124.24380.dwayne@oscl.ca>
	<200803281418.43586.dwayne@oscl.ca>
Message-ID: <200803311401.18875.dwayne@oscl.ca>

On March 28, 2008 02:18:43 pm Dwayne Litzenberger wrote:
> It might be a threading issue.

Robey: Does paramiko have a defined lock hierarchy?  Could you describe the 
order that the various locks are acquired?  I'm attempting to trace how locks 
are acquired right now, but it would be helpful to find out what the code is 
_supposed_ to be doing.

-- 
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/