Re: [paramiko] Unknown private key cipher AES-128-CBC
On Wed, Sep 8, 2010 at 6:49 PM, Robey Pointer robeypoin...@gmail.com wrote:
It may be as simple as adding another line to the top of pkey.py, in the
_CIPHER_TABLE:
'AES-128-CBC': { 'cipher': AES, 'keysize': 16, 'blocksize': 16,
'mode': AES.MODE_CBC }
Could you try that and let me know if it fixes it?
Hi Robey,
That works using a private key generated by openssl.
--- a/paramiko/pkey.py
+++ b/paramiko/pkey.py
@@ -25,7 +25,7 @@ from binascii import hexlify, unhexlify
import os
from Crypto.Hash import MD5
-from Crypto.Cipher import DES3
+from Crypto.Cipher import DES3, AES
from paramiko.common import *
from paramiko import util
@@ -40,6 +40,7 @@ class PKey (object):
# known encryption types for private key files:
_CIPHER_TABLE = {
+'AES-128-CBC': { 'cipher': AES, 'keysize': 16, 'blocksize':
16, 'mode': AES.MODE_
'DES-EDE3-CBC': { 'cipher': DES3, 'keysize': 24, 'blocksize':
8, 'mode': DES3.MOD
}
___
paramiko mailing list
paramiko@lag.net
http://www.lag.net/cgi-bin/mailman/listinfo/paramiko
Re: [paramiko] Unknown private key cipher AES-128-CBC
On Mon, Sep 6, 2010 at 7:37 PM, Ludovico Fischer livre...@gmail.com wrote:
Hello,
I am on Fedora 13 with Paramiko 1.7.6. I am using a key generated on Fedora
12.
client = paramiko.SSHClient()
client.load_system_host_keys()
client.connect('hostname', username='autore')
raises the following exception
File /usr/lib/python2.6/site-packages/paramiko/client.py, line 327, in
connect
self._auth(username, password, pkey, key_filenames, allow_agent,
look_for_keys)
File /usr/lib/python2.6/site-packages/paramiko/client.py, line 481, in
_auth
raise saved_exception
paramiko.SSHException: Unknown private key cipher AES-128-CBC
paramiko only supports des3 encrypted private keys (DES-EDE3-CBC)
Now, I do not remember exactly what command I have used to generate this
key, but I don't think I did anything fancy.
So it seems a bit strange that the cipher could be particularly unusual. Is
this a bug with the distribution? Is there some library missing?
AFAIK, openssh currently only supports des3 as well, and the
ssh-keygen program has no options to specify cipher. I'm guessing that
you used another tool (like openssl) to generate your key file.
-jim
--
James Bardin
Systems Engineer
Boston University IST
___
paramiko mailing list
paramiko@lag.net
http://www.lag.net/cgi-bin/mailman/listinfo/paramiko
Re: [paramiko] Handling of badly behaved server
On Thu, Aug 12, 2010 at 9:28 AM, Giles Brown giles_br...@hotmail.com wrote: I’m new to using paramiko. I’m trying to get paramiko to give up when it encounters a badly behaved server (see below). Can anyone give me a tip on how to do this and whether it is possible? ... The client is running on Windows and so is the server. I’ve tried this with 1.7.6 under Python 2.6 and 1.7.1 under Python 2.3 with the same result in both cases. Since the server is at fault, the only way around it is to timeout on the client side, and kill the connection. At a high level, you could use a threading.Timer around ssh.connect() to cancel the negotiation. Your handler function calling close() on the SSHClient object should be sufficient here, which would raise an SSHException. If you're working at a lower level, you also have the choice of giving transport.start_client() a threading.Event to work asynchronously. -jim -- James Bardin jbar...@bu.edu Systems Engineer Boston University IST ___ paramiko mailing list paramiko@lag.net http://www.lag.net/cgi-bin/mailman/listinfo/paramiko
Re: [paramiko] select not returning in error.
On Tue, Jul 20, 2010 at 2:10 PM, jd jdsw2...@yahoo.com wrote: Anyone has ideas for this issue ? I see the condition you are demonstrating, but I'm not sure I understand what you're asking. The channel acts like a socket. Selecting on a closed socket 's', gives the same result: select.select([s], [s], [s], 1) ([socket._socketobject object at 0x2b8f4faeca10], [socket._socketobject object at 0x2b8f4faeca10], []) -jim select([chan,], [], [chan,], timeout) and check for it to be non-empty.. but does not seem to trigger. Any suggestion on how to work around this ? Is it that unless there is some exchange... the error will not trigger? ___ paramiko mailing list paramiko@lag.net http://www.lag.net/cgi-bin/mailman/listinfo/paramiko
Re: [paramiko] Multithreading
On Thu, Jul 1, 2010 at 12:06 PM, Nikolaus Rath nikol...@rath.org wrote: You can share it, like you can share anything you want between threads, you need proper locking, as the client only has one channel for communication. Since I can share anything I want if I synchronize access to it myself, my question was meant as can I share it without explicit locking. Generally in python, the only objects you can share without explicit locking are single instances of core data types - basically lists and dicts. ___ paramiko mailing list paramiko@lag.net http://www.lag.net/cgi-bin/mailman/listinfo/paramiko
Re: [paramiko] Multithreading
On Wed, Jun 30, 2010 at 11:13 AM, Marcin Krol mrk...@gmail.com wrote: Obviously, all the normal caveats about multithreading apply: remembering to sleep just in case after releasing locks to prevent starvation I never heard of that. Could you explain in more detail what you mean? http://linuxgazette.net/107/pai.html Caveat: I don't know if this has been improved in Python thread handling since that article has been written, but I add a bit of sleeping after lock release anyway just to be safe. That's a poor example of python coding. It's highlighting a GIL issue, but if you have that sort of contention, you shouldn't be using multiple threads. The author may have encountered a problem, but he didn't fully understand it, or his own solution; which is why adding a magic sleep seems to work. Note that you will get slightly different results on a multicore system. The main loop is a busy loop! It's hogging the GIL itself, and pegging a cpu core at %100. Because the threads only do work with a lock, there is no time for the GIL to switch threads., The sleep() simply allows a few cycles for the GIL to be released. -jim ___ paramiko mailing list paramiko@lag.net http://www.lag.net/cgi-bin/mailman/listinfo/paramiko
Re: [paramiko] Exception in thread Thread-1 (most likely raised during interpreter shutdown) using 1.7.6
On Fri, Mar 26, 2010 at 11:32 AM, ken cochrane kencochr...@gmail.com wrote: python: 2.5.4 paramiko: 1.7.6 pycrypto: 2.1.0 Django: 1.1.1 Although I don't know specifically what's going on, I do know that it doesn't happen in either python2.4 or python 2.6, so it may be a python2.5 bug. -jim ___ paramiko mailing list paramiko@lag.net http://www.lag.net/cgi-bin/mailman/listinfo/paramiko
Re: [paramiko] What is the correct way to implement reconnect
On Wed, Mar 17, 2010 at 6:47 AM, Roman Yakovenko roman.yakove...@gmail.com wrote: Hello. I am trying to implement reconnect functionality for my class. I would like to ping to a remote machine, using opened transport if ping fails for any reason, then to recreate the whole SSHClient object and continue from there. It looks like paramiko has a lot of active/alive properties here and there but they are passive. I mean if the remote host closes connection for some reason, those properties will not reflect true connection state. The solution: execute command - except error - reconnect can't be used in my case. transport.is_active() should report the condition of the ssh transport correctly. If the remote host simply stops responding and doesn't close the connection properly, there's is no way to detect it without testing the connection. The Transport class has send_ignore method, but it does nothing with the send result: doesn't propagate exception, doesn't update the instance state. send_ignore is to create line noise, or keep tcp sessions alive. It's purposely ignored. Channel class has all the logic that allows to treat exceptional situations but: * it does not allow to reset it - to clean all the buffers * it does not allow to send ignore message. I'm not sure what you're looking for here. If you're going to reconnect, which you would have to do if the connection is broken, there's nothing you can do with the channel, because it's no longer valid. -jim ___ paramiko mailing list paramiko@lag.net http://www.lag.net/cgi-bin/mailman/listinfo/paramiko
Re: [paramiko] What is the correct way to implement reconnect
On Wed, Mar 17, 2010 at 3:44 PM, Roman Yakovenko roman.yakove...@gmail.com wrote: transport.is_active() should report the condition of the ssh transport correctly. If the remote host simply stops responding and doesn't close the connection properly, there's is no way to detect it without testing the connection. This is exactly what I tried to achieve - to find light method to verify that the connection is alive. transport.is_active() doesn't help in such situation. I verified this, when the remote virtual machine was shutdown. Transport.active was True This is because the tcp connection is half-open, which is a condition that the socket doesn't know about. You can continue to send data with no errors. Initially, I thought about executing some useless command like 'echo 1', but didn't like that idea, mainly for the performance reasons ( not verified, just a feeling ). So I started to look for a light way and found send_ignore message. The Transport class has send_ignore method, but it does nothing with the send result: doesn't propagate exception, doesn't update the instance state. send_ignore is to create line noise, or keep tcp sessions alive. It's purposely ignored. Do you mean that remote side completely ignores this message and doesn't send any message back? Yes. It's designed to keep the network connection alive, not the ssh session. I am trying to execute a different set of commands against a host. During the remote command execution( on the server side ), the client side executes some logic that could raise an exception. This could leave the channel in some unknown state. I mean the read buffer could be full and the server still executes the command. I didn't find a way to reset the channel, but to create a new one. Now, in case the remote host closed the connection, my program was stalled in the Transport.open_session function. I tried to play with blocking/nonblocking/timeout option without success. The only way to clear out the channel is to read the data out of it. The pipe may backed up all the way to the kernel tcp buffers, and calling recv on the socket is the only way to free them up without closing the socket entirely. Think of the channel just like you would a tcp socket. If the remote host closes the connection, transport.is_alive() will be False, and paramiko will raise an exception. In the case of the remote host becoming unresponsive (crash, network down), you will have to implement a timeout of some sort. -jim ___ paramiko mailing list paramiko@lag.net http://www.lag.net/cgi-bin/mailman/listinfo/paramiko
Re: [paramiko] Handling the background thread
On Sun, Mar 14, 2010 at 7:31 PM, Nikolaus Rath nikol...@rath.org wrote: I'm running 1.7.4-0.1 (Ubuntu Karmic). Do you know in which version this changed? changed in commit 25417575. I think the next release was 1.7.5 ___ paramiko mailing list paramiko@lag.net http://www.lag.net/cgi-bin/mailman/listinfo/paramiko
Re: [paramiko] Handling the background thread
On Sat, Mar 13, 2010 at 7:08 PM, Nikolaus Rath nikol...@rath.org wrote: Hello, Is there a way to convince Paramiko to start its background thread as a daemon thread, so that it does not prevent the interpreter from terminating? Are you running the latest version? The transport threads have been set to daemon for a while now, because python 2.6 can't cleanup the threads at exit. -jim ___ paramiko mailing list paramiko@lag.net http://www.lag.net/cgi-bin/mailman/listinfo/paramiko
Re: [paramiko] Surviving fork()
On Mon, Mar 1, 2010 at 8:25 AM, Nikolaus Rath nikol...@rath.org wrote: Hello, I would like to keep an established ssh connection when daemonizing, i.e. when calling fork(). Is there a way to do this? I suppose paramiko would have to run either single threaded, or have to recreate its threads after the fork() call... Paramiko is threaded by design, and an established connection requires the cooperation of two or more threads. There isn't any reasonable way to recreate the threads after fork() from within paramiko, and I actually don't think python defines any mechanism to re-enter a thread after a fork. -jim ___ paramiko mailing list paramiko@lag.net http://www.lag.net/cgi-bin/mailman/listinfo/paramiko
Re: [paramiko] CPU usage while connecting
On Wed, Feb 10, 2010 at 7:13 AM, Marcin Krol mrk...@gmail.com wrote: Semi-good news/bad news routine: Bad news: Unfortunately the above doesn't seem to work, as Transport().close method doesn't want to cooperate (I get this while talking to that slow Solaris host). That is, I do: def printandclose(self): print trying to close transport self.trans.close() ... timer = threading.Timer(4, self.printandclose) ..and timer does indeed go off on timeout. But the trans.close() doesn't do anything, that is: neither trans.connect nor trans.start_client() methods return after timer calls trans.close. Code: I'm just shooting in the dark since I can't replicate this, but you could try to break the connection by closing the socket from underneath the transport (stored in transport.sock). ... Now this does *seem* to work: but my worry is that Transport().is_active() always seems to return True, even with that slow host (and I tested it with quite a few other hosts as well). transport.is_active() (or transport.active) isn't going to be a reliable indicator when you're trying to detect when you're stuck in negotiation, because it's immediately set when you call start_client(). You're better off waiting for the event to fire. You're probably going to have to dig down and find out where the code is hanging in order to clear this up entirely. -jim ___ paramiko mailing list paramiko@lag.net http://www.lag.net/cgi-bin/mailman/listinfo/paramiko
Re: [paramiko] Using invoke_shell to su root
On Thu, Feb 4, 2010 at 9:30 PM, Wan Li wanli...@gmail.com wrote: So is there a way to su root only one time to make each exec_command take the advantage of root privilege? Yes. You can use sudo. I personally prefer to use a root (or admin+sudo) account which can only login with a publickey, that way no passwords are needed. On Fri, Feb 5, 2010 at 2:54 AM, Wan Li wanli...@gmail.com wrote: I'm also looking into the demo.py to get some inspirations. The input and output are in different thread, it's OK a command line usage. But how can I know whether the command's output recv() is totally complete? Is there a eof_received or command_output_eof like state or even a event to check? That's the problem with using an interactive shell; you have to parse the output yourself. There's is no eof, just a pipe to the remote shell. ___ paramiko mailing list paramiko@lag.net http://www.lag.net/cgi-bin/mailman/listinfo/paramiko
Re: [paramiko] SCPClient slower than scp
On Mon, Feb 1, 2010 at 2:52 AM, Roman Yakovenko roman.yakove...@gmail.com wrote: Hello. I am using SCPClient class from branch( http://bazaar.launchpad.net/~jbardin/paramiko/paramiko_scp/annotate/500?file_id=scp.py-20081117202350-5q0ozjv6zz9ww66y-1 ) with paramiko 1.7.6 and Python 2.6 on Ubuntu Karmic Koala. I am testing my code with file size 1 GB. The SCPClient upload rate starts with 10 MB/s and than drops to 5.2 MB/s. The average is 5.2 MB/s. I tried to change buffer size, but this didn't help The scp command upload rate starts with 20 MB/s and then drops to 10 MB/s. The average is 10 MB/s. To complete the statistics, paramiko built-in SFTPClient average rate is 2.2 MB. I use put method as is, with the default configuration. I am not sure where to start to solve the problem. Initially, I suspected that local file reading is a problem, but that functionality works pretty well. You would normally start by using a profiler to see where the performance bottleneck is, before you start speculating. You would have seen that most of the time is spent in paramiko.Transport manipulating data, and waiting for pyCrypto. SCPClient adds almost nothing to the overall time. Right now, I am using work around ( executing scp with subprocess ) but it is less than optimal solution. Any help is appreciated. Yes, the solution written entirely in c will be significantly faster. Since this is mostly python, cpu is the limiting factor. There may be some places where optimizations could be made in paramiko and pyCrypto, but I haven't looked into it myself. -jim ___ paramiko mailing list paramiko@lag.net http://www.lag.net/cgi-bin/mailman/listinfo/paramiko
Re: [paramiko] SCPClient slower than scp
On Mon, Feb 1, 2010 at 11:49 AM, Roman Yakovenko roman.yakove...@gmail.com wrote: You would normally start by using a profiler to see where the performance bottleneck is, before you start speculating. You would have seen that most of the time is spent in paramiko.Transport manipulating data, and waiting for pyCrypto. SCPClient adds almost nothing to the overall time. Thanks for advice. I'll follow it. It was not a complete speculation. The CPU usage was pretty same for all solutions. There are some other limiting factors in both paramiko and openssh(http://www.psc.edu/networking/projects/hpn-ssh/), but I have always hit the cpu wall with paramiko long before anything else is relevant. If you're maxing out 1 processor core for each, you're just seeing the difference in the efficiency of the c code vs the python+c code (pyCrypto does the heavy lifting in c). Yes, the solution written entirely in c will be significantly faster. Since this is mostly python, cpu is the limiting factor. I have zero experience in ssh and encryption, but my expection was that at least in the case of transfering 10+ Gb files, the process will be bounded by network and not CPU. The size of the file has nothing to do with it once the connection and negotiation time become irrelevant. It's an encrypted stream of data, so you're limited by how fast you can process it, not by how long it is. ___ paramiko mailing list paramiko@lag.net http://www.lag.net/cgi-bin/mailman/listinfo/paramiko
Re: [paramiko] SCPClient slower than scp
On Mon, Feb 1, 2010 at 12:16 PM, james bardin jbar...@bu.edu wrote: Yes, the solution written entirely in c will be significantly faster. Since this is mostly python, cpu is the limiting factor. I have zero experience in ssh and encryption, but my expection was that at least in the case of transfering 10+ Gb files, the process will be bounded by network and not CPU. Your email got me thinking, so I did a few tests: The biggest boost in performance was had by using the latest pycrypto(2.1.0). You'll get a deprecation warning from paramiko that you can ignore for now (bug already submitted in github). There was a change to the HMAC code that made a huge difference in paramiko's performance. I tried using a limited bandwidth connection, and paramiko was on par with openssh when cpu wasn't a concern. When bandwidth wasn't an issue (using loopback), paramiko was about 85% of the speed of openssh on my machine. Each newer version of python2.X was slightly faster as well. ___ paramiko mailing list paramiko@lag.net http://www.lag.net/cgi-bin/mailman/listinfo/paramiko
Re: [paramiko] alternate ciphers
On Wed, Jan 27, 2010 at 6:40 AM, Marcin Krol mrk...@gmail.com wrote:
###
import paramiko
import socket
s = socket.socket()
s.connect(('localhost', 22))
t = paramiko.Transport(s)
t.get_security_options().ciphers = ('arcfour128',)
t.connect
.
Regardless of what I set as .ciphers in transport (using both = and method
_set_ciphers), the transport still uses original ciphers tuple.
You have to set the ciphers before you connect. You can't change the
cipher once the encryption has already been negotiated.
The above code does work - here's the log output from the server side:
sshd[22168]: debug1: kex: client-server arcfour128 hmac-sha1 none
sshd[22168]: debug1: kex: server-client arcfour128 hmac-sha1 none
The code:
cph = transport.get_security_options()._get_ciphers()
print 'orig ciphers', cph
if 'blowfish-cbc' in cph:
cph = list(cph)
cph.remove('blowfish-cbc')
cph = tuple(['blowfish-cbc'] + cph)
#transport.get_security_options()._set_ciphers(cph)
transport.get_security_options().ciphers = cph
transport.get_security_options().ciphers = ('blowfish-cbc',)
print 'ciphers', transport.get_security_options()._get_ciphers()
channel = transport.open_session()
scpcmd = 'scp -t -v %s\n' % self.rfpath
try:
channel.exec_command(scpcmd)
except paramiko.SSHException, e:
___
paramiko mailing list
paramiko@lag.net
http://www.lag.net/cgi-bin/mailman/listinfo/paramiko
Re: [paramiko] remote command info
On Tue, Jan 26, 2010 at 5:20 PM, stefano landucci marlonba...@gmail.com wrote:
Hi,
I'm a paramiko's newbie. I started with a simple ssh connection and command
execution like below:
import sys
import paramiko
client = paramiko.SSHClient()
client.load_system_host_keys()
ip = 'ip_server'
client.set_missing_host_key_policy(paramiko.AutoAddPolicy())
client.connect(ip,port=22, username='my_user',password='**')
i, o, e = client.exec_command('ls -la')
print o.read()
client.close()
I don't understand the steps to exec multiple commands, like the example
below.
Es: if I exec before cd /etc command and after few time I want to exec a
ls command. What I do?
The short answer is, you don't.
Run your commands separately with exec_command(), and remove their
dependencies on one another, and you will be much happier.
You can get an interactive shell with invoke_shell(), but then you
have to script being interactive - send command, wait for complete
response or timeout, parse response and/or return code, send another
command, etc. Some situations may really require this, but they are
few and far between.
-jim
___
paramiko mailing list
paramiko@lag.net
http://www.lag.net/cgi-bin/mailman/listinfo/paramiko
Re: [paramiko] alternate ciphers
On Thu, Dec 31, 2009 at 11:19 AM, Marcin Krol mrk...@gmail.com wrote: Hello, I'm using paramiko to concurrently distribute large files/dirs to many hosts. This is heavy on CPU. Is there any way to say to SSHClient or channel or transport what cipher to use? Which one would be recommended anyway? I was thinking of Blowfish as it is typically recommended for scp (or not?) I believe the arcfour-128 stream cipher is the least cpu intensive of the generally supported ciphers. If security really isn't a concern, and you can't implement ftp, or rcp, you could use a null cipher. Paramiko doesn't support this by default, but it's pretty simple to implement, and I remember seeing a patch on this mailing list at one time. I don't think that ever got merged into openssh, but some implementations may have it available. -jim ___ paramiko mailing list paramiko@lag.net http://www.lag.net/cgi-bin/mailman/listinfo/paramiko
Re: [paramiko] adding a handler to the paramiko loggers
On Sun, Dec 13, 2009 at 10:01 PM, Moritz Beber moritz.be...@googlemail.com wrote: I can add a handler of my choosing to the Transport.logger but then something strange happens: I get duplicate entries on stdout. I checked the list of handlers for Transport.logger and it contains only one handler. When I do not add a handler, the list is empty, but logging still occurs to stdout. How are you going about adding the handler? I couldn't replicate this from a quick test. So I poked around in the sources and saw that logging is done by the Transport.packetizer as well. Unfortunately, that class' logger is private so I couldn't check the available handlers there. If you're new to python, nothing is really private. You should respect the private pieces of the api by convention, but there's no reason you can't inspect those pieces to debug your problem. Since I couldn't find anywhere in the initialisation order when creating a Transport instance that would add a handler to the packetizer I guess something default is being done when importing. AFAIK, no handlers are added by default. This actually causes the logging module to print a warning to stdout if it gets called, because it always expects to have a handler present. -jim ___ paramiko mailing list paramiko@lag.net http://www.lag.net/cgi-bin/mailman/listinfo/paramiko
Re: [paramiko] Paramiko SSHClient
2009/12/4 Petrucci Andreas petrucci_2...@hotmail.com
A quite strange thing is that with this specific host most of the time the
connection is established successfully but sometimes the above SSHException
occurs.
From my perspective, it's not up to me to correct this, am I right?
Yes, this is the fault of the remote host, or the network itself.
class 'paramiko.SSHException': EOF during negotiation
args = ('EOF during negotiation',)
message = 'EOF during negotiation'
It looks like the server is doing something wrong, or doesn't support
the sftp subsystem.
What type of server are you connecting to?
-jim
___
paramiko mailing list
paramiko@lag.net
http://www.lag.net/cgi-bin/mailman/listinfo/paramiko
Re: [paramiko] Paramiko SSHClient
On Fri, Dec 4, 2009 at 3:19 PM, Petrucci Andreas petrucci_2...@hotmail.com wrote: it's a PlanetLab node, and i have this problem with all PlanetLab nodes that i cope with. I mean what is the ssh-server/OS? Does other sftp clients work (like sftp from openssh)? ___ paramiko mailing list paramiko@lag.net http://www.lag.net/cgi-bin/mailman/listinfo/paramiko
Re: [paramiko] Paramiko SSHClient
On Fri, Dec 4, 2009 at 4:19 PM, Petrucci Andreas petrucci_2...@hotmail.com wrote: OpenSSH_4.7p1, OpenSSL 0.9.8b 04 May 2006 Fedora release 8 2.6.22.19 You may not have any control over this, but Fedora 8 has been out of support for a year now. I tried with filezilla and sftp but no connection was accomplished. Any alternatives? If that's the case, then the server is probably not configured to allow sftp, or is misconfigured in some way. If the scp binary is available on the server, you could use that. Paramiko doesn't have an scp module included, but I've posted my implementation to the list before: http://www.lag.net/pipermail/paramiko/2009-December/001189.html -jim ___ paramiko mailing list paramiko@lag.net http://www.lag.net/cgi-bin/mailman/listinfo/paramiko
Re: [paramiko] ssh.exec_command() hangs up
On Tue, Nov 24, 2009 at 6:06 AM, himanchali himanch...@inmobi.com wrote: hi.. I m using ssh =paramiko.SSHClient() object to exec_command. But I m using VPN connection to connect to hosts, so if the host disconnects, my exec_command() hangs up. There is no timeout option there i think. Even the connection is not there, ssh.get_transport().is_alive() , .is_active(), .is_authenticated() are returning true. is there not any way to check for the connection before exec_command(). If I remember correctly, this can be a problem with using an unreliable vpn. Transport.is_active() will return True as long as the tcp socket is open. When the vpn collapses, it's like a network cable is unplugged, so the client doesn't know what's happening on the other end, it just has to wait. Try setting Transport.set_keepalive(N), where N is the interval in seconds to send keepalive messages to the server. Hopefully this will allow to client to recognize when it can no longer reach the server, and is_active() will return usefully (is_alive/isAlive is only for the underlying thread). Otherwise, you could use the Transport directly, and bail if open_session() fails. -jim ___ paramiko mailing list paramiko@lag.net http://www.lag.net/cgi-bin/mailman/listinfo/paramiko
Re: [paramiko] Fwd: Bug#556946: python-paramiko: returns None in exec_command
On Mon, Nov 23, 2009 at 12:26 AM, Ritesh Raj Sarraf r...@researchut.com wrote: In my case, in the above example, it reads and then gets a 'None'. My logger, log, only accepts strings. So it fails when it receives a 'None'. Am I doing something wrong here in the way I'm reading the output from exec_command() ?? That sounds correct. Can you make a small test case where this happens? Reading a channel shouldn't ever be able to return anything but a string. -jim ___ paramiko mailing list paramiko@lag.net http://www.lag.net/cgi-bin/mailman/listinfo/paramiko
Re: [paramiko] getting stdout and stderr together
On Mon, Nov 23, 2009 at 1:26 PM, Todd Whiteman to...@activestate.com wrote: Marcin Krol wrote: Hello, Is there any way to get standard output and standard error arranged chronologically together in one text stream as they come from ssh server, while doing connection_object.exec_command() of course? Sometimes you do want to separate standard output from standard error. But sometimes you don't. Example: when I do the following command over paramiko: Hi Marcin, You can do this using the set_combine_stderr method on the Channel object: [http://www.lag.net/paramiko/docs/paramiko.Channel-class.html#set_combine_stderr] Thanks. Sorry Marcin, I completely forgot about that option. As James noted, the ordering is not 100% reliable - but it should be close enough. Paramiko combines them at a fairly low level, so this should be pretty close to what you would see on the host. -jim ___ paramiko mailing list paramiko@lag.net http://www.lag.net/cgi-bin/mailman/listinfo/paramiko
Re: [paramiko] demo script error
On Mon, May 18, 2009 at 5:26 AM, LIU YI liu_yi_b...@yahoo.com wrote:
Hi All,
I am a new user of paramiko. I dowloaded paramiko-1.7.4 in my Debian Voygae
Linux OS recently. Python2.4 and Pycrypto2.0.1 were installed before.
When I run the rforward.py which is in demo directory, an error occured.
usage: rforward.py [options] ssh-server[:server-port]
rforward.py: error: Incorrect number of arguments.
You need to specify the server, per the usage: line.
Then I wrote a simple Code:
import paramiko
ssh = paramiko.SSHClient()
ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy())
ssh.connect('ip', username='***',password='***')
Result:
user:~# python test.py
(after about 3 seconds)
user:~#
You script connects, then does nothing.
What were you expecting to happen?
-jim
___
paramiko mailing list
paramiko@lag.net
http://www.lag.net/cgi-bin/mailman/listinfo/paramiko
Re: [paramiko] Unhandled exception
The funny thing is that my code seemed to complete what is was doing before the exception was thrown, so it appears to have thrown it on the way out as my script finished. I think the problem is in the thread cleanup (the paramiko transports are threaded). Did you make sure that you have closed all the connections before you exit? Here some info from python.org if you want to read through http://bugs.python.org/issue1722344 but I don't know if it will apply to your code. I think there is some cleanup to be done in the paramiko threading. I've seen some people trigger interesting exceptions when doing something out of the ordinary, usually around module import or deletion. -jim ___ paramiko mailing list paramiko@lag.net http://www.lag.net/cgi-bin/mailman/listinfo/paramiko
Re: [paramiko] Does Paramiko 1.7.2 and 1.6.4 work with CentOS 4
On Wed, Feb 25, 2009 at 4:16 AM, Eric Noulard eric.noul...@gmail.com wrote: 2009/2/25 Shah Sultan Alam ssa...@gmail.com: 1. Does Paramiko 1.7.2 and 1.6.4 work with CentOS 4 If you can't find it in a reasonably up-to-date repository, you could just download the tarball, and run 'python setup.py install'. You will also need to pick up python-crypto, which you can get from the epel repos: http://fedoraproject.org/wiki/EPEL -jim ___ paramiko mailing list paramiko@lag.net http://www.lag.net/cgi-bin/mailman/listinfo/paramiko
