From jbardin at bu.edu Fri Nov 2 14:16:53 2007 From: jbardin at bu.edu (James Bardin) Date: Fri, 02 Nov 2007 17:16:53 -0400 Subject: [paramiko] SSHClient.close should be able to be called multiple time Message-ID: <472B93C5.5000902@bu.edu> Hi Robey, Here's a simple patch if you'd like. I have a finally block that's trying to cleanup open sockets, but in some cases SSHClient.close() may be called more than once. Most close methods are safe to call multiple times, so I just added this in client.py: Thanks -jim === modified file 'client.py' --- client.py 2007-11-02 21:07:21 +0000 +++ client.py 2007-11-02 21:11:18 +0000 @@ -294,6 +294,8 @@ """ Close this SSHClient and its underlying L{Transport}. """ + if not self._transport: + return self._transport.close() self._transport = None From elventear at gmail.com Tue Nov 6 10:19:18 2007 From: elventear at gmail.com (Pepe Barbe) Date: Tue, 6 Nov 2007 12:19:18 -0600 Subject: [paramiko] Check connection status Message-ID: <66ABC4F6-58DA-4ADC-B16B-A545F39B8DCB@gmail.com> Hello everyone, I would like to know what will paramiko do if it is blocking on a recv request, given that there is no data to retrieve, and the connection drops. Will paramiko raise an Exception? Or do I have to frequently timeout and check if the connection is still up? How can I check if a connection is still up? My guess is transport.is_authenticated but I am not sure. Thanks, Pepe From jbardin at bu.edu Tue Nov 6 15:03:02 2007 From: jbardin at bu.edu (James Bardin) Date: Tue, 06 Nov 2007 18:03:02 -0500 Subject: [paramiko] Check connection status In-Reply-To: <66ABC4F6-58DA-4ADC-B16B-A545F39B8DCB@gmail.com> References: <66ABC4F6-58DA-4ADC-B16B-A545F39B8DCB@gmail.com> Message-ID: <4730F2A6.1070103@bu.edu> Hi Pepe, I think that you may want to use transport.is_active() Paramiko won't throw an exception just because the connection drops, but the transport is always checking to make sure the connecting is active. -jim Pepe Barbe wrote: > Hello everyone, > > I would like to know what will paramiko do if it is blocking on a recv > request, given that there is no data to retrieve, and the connection > drops. Will paramiko raise an Exception? Or do I have to frequently > timeout and check if the connection is still up? > > How can I check if a connection is still up? My guess is > transport.is_authenticated but I am not sure. > > Thanks, > Pepe > > _______________________________________________ > paramiko mailing list > paramiko at lag.net > http://www.lag.net/cgi-bin/mailman/listinfo/paramiko > > From robey at lag.net Fri Nov 9 22:38:49 2007 From: robey at lag.net (Robey Pointer) Date: Fri, 9 Nov 2007 22:38:49 -0800 Subject: [paramiko] Check connection status In-Reply-To: <66ABC4F6-58DA-4ADC-B16B-A545F39B8DCB@gmail.com> References: <66ABC4F6-58DA-4ADC-B16B-A545F39B8DCB@gmail.com> Message-ID: On Nov 6, 2007, at 10:19 AM, Pepe Barbe wrote: > Hello everyone, > > I would like to know what will paramiko do if it is blocking on a recv > request, given that there is no data to retrieve, and the connection > drops. Will paramiko raise an Exception? Or do I have to frequently > timeout and check if the connection is still up? If the connection drops, the Channel should signal EOF, which will wake up any recv() and make it return with an empty string (which is python's way of indicating EOF). So you should be able to call recv() with no timeout if you wish. > How can I check if a connection is still up? My guess is > transport.is_authenticated but I am not sure. Transport.is_active() is probably what you want. robey From robey at lag.net Fri Nov 9 22:51:34 2007 From: robey at lag.net (Robey Pointer) Date: Fri, 9 Nov 2007 22:51:34 -0800 Subject: [paramiko] Suggested addition to get channel from SSHClient (with patch) In-Reply-To: References: Message-ID: On Oct 23, 2007, at 6:25 AM, Paul Rouse wrote: > This is a suggestion that SSHClient should provide methods > for opening channels of any types (not just one on which a shell > has been invoked). > > My reason is this: arguably the most useful service provided by > SSHClient is its high-level handling of the SSH connection, > particularly authentication. Once set up, though, there is > sometimes a need to have more control over the channels, for > example setting timeouts or merging stderr with stdout. > > It seems a shame to abandon the authentication aspects of SSHClient > simply so that arbitrary channels can be opened (and it is > probably even worse to get round it by accessing its private > _transport attribute!) > > I have included a patch which simply exposes channel-creation > methods on the underlying Transport. The alternative would > be to provide direct access to the Transport, but to me that > alternative does seem to cut too much across the levels. Hm, several people have asked in the past for a way to access the Transport object, for different reasons, so maybe I should just add an accessor for that. I don't really want to start adding helper methods to SSHClient for every method in Transport. robey From robey at lag.net Fri Nov 9 22:52:16 2007 From: robey at lag.net (Robey Pointer) Date: Fri, 9 Nov 2007 22:52:16 -0800 Subject: [paramiko] SSHClient.close should be able to be called multiple time In-Reply-To: <472B93C5.5000902@bu.edu> References: <472B93C5.5000902@bu.edu> Message-ID: On Nov 2, 2007, at 2:16 PM, James Bardin wrote: > Hi Robey, > > Here's a simple patch if you'd like. > I have a finally block that's trying to cleanup open sockets, but in > some cases SSHClient.close() may be called more than once. Most close > methods are safe to call multiple times, so I just added this in > client.py: Thanks! robey From p.rouse at rms.co.uk Mon Nov 12 00:36:47 2007 From: p.rouse at rms.co.uk (Paul Rouse) Date: Mon, 12 Nov 2007 08:36:47 -0000 Subject: [paramiko] Suggested addition to get channel from SSHClient (with patch) Message-ID: Fine - that would solve my problem perfectly well. The choice between your suggestion and mine is purely a matter of judgement, which I will leave to you! - Paul Rouse -----Original Message----- From: Robey Pointer [mailto:robey at lag.net] Sent: 10 November 2007 06:52 To: Paul Rouse Cc: paramiko at www.lag.net Subject: Re: [paramiko] Suggested addition to get channel from SSHClient (with patch) On Oct 23, 2007, at 6:25 AM, Paul Rouse wrote: > This is a suggestion that SSHClient should provide methods > for opening channels of any types (not just one on which a shell > has been invoked). > > My reason is this: arguably the most useful service provided by > SSHClient is its high-level handling of the SSH connection, > particularly authentication. Once set up, though, there is > sometimes a need to have more control over the channels, for > example setting timeouts or merging stderr with stdout. > > It seems a shame to abandon the authentication aspects of SSHClient > simply so that arbitrary channels can be opened (and it is > probably even worse to get round it by accessing its private > _transport attribute!) > > I have included a patch which simply exposes channel-creation > methods on the underlying Transport. The alternative would > be to provide direct access to the Transport, but to me that > alternative does seem to cut too much across the levels. Hm, several people have asked in the past for a way to access the Transport object, for different reasons, so maybe I should just add an accessor for that. I don't really want to start adding helper methods to SSHClient for every method in Transport. robey _____________________________________________________________________ This message has been checked for all known viruses by the RMS Services Ltd Virus Scanning Service. For further information visit http://www.rms.co.uk or call UK 01454 281265 _____________________________________________________________________ This message has been checked for all known viruses by the RMS Services Ltd Virus Scanning Service. For further information visit http://www.rms.co.uk or call UK 01454 281265 From elventear at gmail.com Mon Nov 12 14:48:14 2007 From: elventear at gmail.com (Pepe Barbe) Date: Mon, 12 Nov 2007 16:48:14 -0600 Subject: [paramiko] Interactive Programs with 'exec_command' Message-ID: Hi, I am curious of what should I expect from Paramiko when I issue and exec_command on a channel object, and the command itself is quite interactive. I've been able to interact with the command using channel.send but after I supposedly exited the program, the channel doesn't close nor I get the exit_status from the server. Is this the normal behavior? Thanks, Pepe From dwayne at oscl.ca Tue Nov 13 06:28:29 2007 From: dwayne at oscl.ca (Dwayne Litzenberger) Date: Tue, 13 Nov 2007 08:28:29 -0600 Subject: [paramiko] Using select() to determine when channel write buffer not full Message-ID: <200711130828.30155.dwayne@oscl.ca> Hi there! When working with a native socket, if I want to check if a send() would not block, I can do something like this: (rr, ww, ee) = select.select([], [sock], [], 0) That obviously doesn't work with Paramiko channels, since (from what I can tell) the file descriptor returned by Channel.fileno() isn't actually used for I/O. Imagine that I want to copy data coming in at high speed over a socket to a much slower Paramiko channel. What I would like to do is something like this, but it doesn't seem to be possible: writeBuf = "" while loop: if writeBuf != "": channel.set_notify_on_writable(True) else: channel.set_notify_on_writable(False) rr = [abort_fd, channel, sock] if len(writeBuf) >= 8192: # Don't allow writeBuf to grow infinitely rr.remove(sock) (rr, ww, ee) = select.select(rr, [], [], 0) if abort_fd in rr: # Another thread has requested that we abort break if sock in rr: # Data is ready to be read from the socket writeBuf += sock.recv(8192) if channel in rr: if channel.recv_ready(): # do stuff if channel.recv_stderr_ready(): # do stuff if channel.send_ready(): count = channel.send(writeBuf) writeBuf = writeBuf[count:] # ... Is anything similar possible? -- Dwayne Litzenberger, B.A.Sc. Information Technology Analyst Open Systems Canada Limited 1627 Broad Street Regina, SK S4P1X3 Office: 306.359.6725 http://www.oscl.ca/ From titleistfour at gmail.com Fri Nov 16 12:28:35 2007 From: titleistfour at gmail.com (jay) Date: Fri, 16 Nov 2007 14:28:35 -0600 Subject: [paramiko] Debugging a remote connection Message-ID: <7c25bb490711161228s50bcf61bgc9f158f4f1123ac8@mail.gmail.com> Hello, I have a remote SFTP, not managed by me, that I am unable to connect to with Paramiko. The demo scripts won't even connect. All I get is Authentication password failed. However, I can take the same host, username and password, past it into any other client, and it works fine without problems. That includes Openssh sftp, filezilla, winscp and putty. What type of debugging could I possibly do to figure this out? Here is the output from the demo_sftp.py script DEB [20071116-14:01:49.616] thr=1 paramiko.transport: starting thread (client mode): 0xf6c69c8cL INF [20071116-14:01:49.770] thr=1 paramiko.transport: Connected (version 1.99, client OpenSSH_3.8.1p1) DEB [20071116-14:01:49.867] thr=1 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-cbc', 'arcfour', 'aes192-cbc', 'aes256-cbc', 'rijndael-cbc at lysator.liu.se', 'aes128-ctr', 'aes192-ctr', 'aes256-ctr'] client mac:['hmac-md5', 'hmac-sha1', 'hmac-ripemd160', 'hmac-ripemd160 at openssh.com', 'hmac-sha1-96', 'hmac-md5-96'] server mac:['hmac-md5', 'hmac-sha1', 'hmac-ripemd160', 'hmac-ripemd160 at openssh.com', 'hmac-sha1-96', 'hmac-md5-96'] client compress:['none', 'zlib'] server compress:['none', 'zlib'] client lang:[''] server lang:[''] kex follows?False DEB [20071116-14:01:49.868] thr=1 paramiko.transport: Ciphers agreed: local=aes128-cbc, remote=aes128-cbc DEB [20071116-14:01:49.868] thr=1 paramiko.transport: using kex diffie-hellman-group1-sha1; server key type ssh-rsa; cipher: local aes128-cbc, remote aes128-cbc; mac: local hmac-sha1, remote hmac-sha1; compression: local none, remote none DEB [20071116-14:01:50.102] thr=1 paramiko.transport: Switch to new keys ... DEB [20071116-14:01:50.108] thr=2 paramiko.transport: Host key verified (ssh-rsa) DEB [20071116-14:01:50.108] thr=2 paramiko.transport: Attempting password auth... DEB [20071116-14:01:50.283] thr=1 paramiko.transport: userauth is OK INF [20071116-14:01:50.470] thr=1 paramiko.transport: Authentication (password) failed. DEB [20071116-14:01:50.572] thr=1 paramiko.transport: EOF in transport thread I get the same thing no matter what I try. I've tried moving my script to other boxes with differing versions of python, and same problem. Connecting to other boxes with the same code yields a successful connection, python and paramiko are working on all remote systems but this one. I'm a bit perplexed as to why this box won't allow me to login. Is there any way to increase the verbosity of the debugging output? Perhaps that would yield something helpful. Thanks for any input Jay From dlitz at dlitz.net Sun Nov 18 19:18:38 2007 From: dlitz at dlitz.net (Dwayne C. Litzenberger) Date: Sun, 18 Nov 2007 21:18:38 -0600 Subject: [paramiko] [MERGE] "python -tt" (whitespace) fixes Message-ID: <20071119031838.GA9933@rivest.dlitz.net> This patch fixes some misuse of tab characters in Paramiko. -- Dwayne C. Litzenberger -------------- next part -------------- # Bazaar merge directive format 2 (Bazaar 0.90) # revision_id: dlitz at dlitz.net-20071119031209-leti7tcmozbtqp30 # target_branch: http://www.lag.net/paramiko/bzr/paramiko/ # testament_sha1: 91906db078f48f08762010e6518e8701dd3d389a # timestamp: 2007-11-18 21:16:49 -0600 # base_revision_id: robey at lag.net-20071029030520-ozmne7y4l6037m8h # # Begin patch === modified file 'paramiko/buffered_pipe.py' --- paramiko/buffered_pipe.py 2007-02-13 19:17:06 +0000 +++ paramiko/buffered_pipe.py 2007-11-19 03:12:09 +0000 @@ -76,7 +76,7 @@ if self._event is not None: self._event.set() self._buffer.fromstring(data) - self._cv.notifyAll() + self._cv.notifyAll() finally: self._lock.release() === modified file 'paramiko/common.py' --- paramiko/common.py 2007-02-13 19:17:06 +0000 +++ paramiko/common.py 2007-11-19 03:12:09 +0000 @@ -21,7 +21,7 @@ """ MSG_DISCONNECT, MSG_IGNORE, MSG_UNIMPLEMENTED, MSG_DEBUG, MSG_SERVICE_REQUEST, \ - MSG_SERVICE_ACCEPT = range(1, 7) + MSG_SERVICE_ACCEPT = range(1, 7) MSG_KEXINIT, MSG_NEWKEYS = range(20, 22) MSG_USERAUTH_REQUEST, MSG_USERAUTH_FAILURE, MSG_USERAUTH_SUCCESS, \ MSG_USERAUTH_BANNER = range(50, 54) @@ -29,9 +29,9 @@ MSG_USERAUTH_INFO_REQUEST, MSG_USERAUTH_INFO_RESPONSE = range(60, 62) MSG_GLOBAL_REQUEST, MSG_REQUEST_SUCCESS, MSG_REQUEST_FAILURE = range(80, 83) MSG_CHANNEL_OPEN, MSG_CHANNEL_OPEN_SUCCESS, MSG_CHANNEL_OPEN_FAILURE, \ - MSG_CHANNEL_WINDOW_ADJUST, MSG_CHANNEL_DATA, MSG_CHANNEL_EXTENDED_DATA, \ - MSG_CHANNEL_EOF, MSG_CHANNEL_CLOSE, MSG_CHANNEL_REQUEST, \ - MSG_CHANNEL_SUCCESS, MSG_CHANNEL_FAILURE = range(90, 101) + MSG_CHANNEL_WINDOW_ADJUST, MSG_CHANNEL_DATA, MSG_CHANNEL_EXTENDED_DATA, \ + MSG_CHANNEL_EOF, MSG_CHANNEL_CLOSE, MSG_CHANNEL_REQUEST, \ + MSG_CHANNEL_SUCCESS, MSG_CHANNEL_FAILURE = range(90, 101) # for debugging: # Begin bundle IyBCYXphYXIgcmV2aXNpb24gYnVuZGxlIHY0CiMKQlpoOTFBWSZTWaoBBSQAAjFfgEBQUWf//3/3 /8S////wUAS4vAAdaAHSgaUyg9J6hoB6jQBoaAGgAAAeoAahEfqRkDQDRoaDQAaAAA00yDQYoE0R P1R6aE0yAaDQAHqADR6gADhppkYjCaYCGATTCMExMhpkaGgEkgg0AmgBU/RlT9NCNDSekaYZIaeU aNPUaRUM7DQklZfpK5xCoTFFG2mXp4ueQYGOC+63nwwZpJeR7SqPWJBJAJemUj4dDDdpa4NZBNag i9j1Xk8NSBNposl+5WMQpQ2wgPJAyxWZMTblAQaENKTH2iTCKYiJQDfEuyAem26lJ3p+DdRMeSGi BKQFABSSdcDzD1HZ5+IDAN99G9jSqH3wPyRDj1m+gE9PCFm9OIwLuRFIMu4ZUJEVzlJB44iUJgck oFHiUgTlZ3EVNSTHXYhzD2aXCkhWmoOqRAB4G28kBPeU14uaQ8/NZFgPVpUUmLHXcBaVOfJekoID F3lepB7klMBIaOYcQnW4pJygoOorMaJ6lUicwNU2Bi32AoVBEcA5DgwJGQ0kyUDALB8qmTXkalEy D5jAkUGmrP6AnMsdMmMpSalaFhYZz8FPLFs9JOVRkqh5neVk0rA0mYuKjMTGeRMsqcZTLgNjYZxo FgYlZEavKVFhoGHIUjEtLZ1MVhgWAxMtoFyhdlsfZKkYrhAqg4vJy4icww4+yoqNE4D9zKoB4xcG I5417i0qNBiZiNhRYPIYBEJBCSsRNyAt7T1sl7WNusjztfQO4MaWhxHjmDd71w/187idqYQ6kEyD sLTt+YHyIwJ8gyOc7k1x7MOahjDvEOSQlva1ZJACYSpEhZNDqDJmASAHqz+6oXXAXr6MmUh8LgKQ H+NLpga1zmCy13kgg/YP4gBkLMtK5SIcKOHCui4L4wg4YDwZEBE6wFgBoK1Dl9T1NxB/mE7io8OV S9A4XqT+z61TBEeL3mg7jSMd52zncWdx4ILTBGjBOvZfGlB815/T5H7mYkZTEYY4jHeTnQeBP/KF 8dQDd7fICRUbRj6GY2m0d52luyDbAPVb2Su5zedJnKwiDXFP1sSksS8Y1GHOnn3QejUVAxst6Cvy JJ4/pOk0HAtKVXj2p+86VaV07mLSCLfWS60x0OwrceKYVGSFaK1yoyhtI4LIIMAK0EEUIUckdZsN Ax0nI5i8Vq5LyOB0mRl+E1iCAyWP3C7aaBOKOg7KxaUFIVdaTzam1YicYeSKeIf1mfHBBuXE4IGr 3CD2/8Tj/WYGoy5UbZpwnXpQQF7AOMhBzd+/eFXQtymXZrrH5tp1J2YB2MwgAdEyFMHkcs5m5gQH PF2Loh4CKQKOPXpIPgDeAXk1jB+wwZJkckSXFyw56QMF5gO58/wY169YTK9VBwVurmKaRtYYAa9j JUEkP9lxFVwAoyPFpFsPkKac1m4K0JpQkBERQcwsYErwqH9OBFPQMRCYICvcgPcHQDx+w/UKuQDq YBViFNtIHMOgSROtADbmJmClwyQdUVzvIT/jQUKpB79+pbewiiWTWDsyfBBcwQzwEDZQMB7OUf/F 3JFOFCQqgEFJAA== From robey at lag.net Mon Nov 19 11:45:10 2007 From: robey at lag.net (Robey Pointer) Date: Mon, 19 Nov 2007 11:45:10 -0800 Subject: [paramiko] [MERGE] "python -tt" (whitespace) fixes In-Reply-To: <20071119031838.GA9933@rivest.dlitz.net> References: <20071119031838.GA9933@rivest.dlitz.net> Message-ID: <04A9B3AE-88BF-4263-A3FC-E03D12BC9E58@lag.net> On 18 Nov 2007, at 19:18, Dwayne C. Litzenberger wrote: > This patch fixes some misuse of tab characters in Paramiko. Thanks; applied! robey From robey at lag.net Mon Nov 19 21:26:05 2007 From: robey at lag.net (Robey Pointer) Date: Tue, 20 Nov 2007 00:26:05 -0500 Subject: [paramiko] Using select() to determine when channel write buffer not full In-Reply-To: <200711130828.30155.dwayne@oscl.ca> References: <200711130828.30155.dwayne@oscl.ca> Message-ID: <6D7680B6-7CD9-4757-930F-083DE8C811B6@lag.net> On 13 Nov 2007, at 9:28, Dwayne Litzenberger wrote: > Hi there! > > When working with a native socket, if I want to check if a send() > would not > block, I can do something like this: > > (rr, ww, ee) = select.select([], [sock], [], 0) > > That obviously doesn't work with Paramiko channels, since (from what > I can > tell) the file descriptor returned by Channel.fileno() isn't > actually used > for I/O. Yeah, and it's only hooked up for detecting reads, not writes. > Imagine that I want to copy data coming in at high speed over a > socket to a > much slower Paramiko channel. What I would like to do is something > like > this, but it doesn't seem to be possible: I guess what you really want is something like "send_ready()" that would behave similar to "recv_ready()": return True if at least one byte can be written. Try the branch at revision 456 -- is that sufficient to do what you want? robey From robey at lag.net Tue Nov 20 12:46:32 2007 From: robey at lag.net (Robey Pointer) Date: Tue, 20 Nov 2007 15:46:32 -0500 Subject: [paramiko] Interactive Programs with 'exec_command' In-Reply-To: References: Message-ID: <7A0FAC77-CB9E-46F2-8557-3A24642BFE00@lag.net> On 12 Nov 2007, at 17:48, Pepe Barbe wrote: > I am curious of what should I expect from Paramiko when I issue and > exec_command on a channel object, and the command itself is quite > interactive. I've been able to interact with the command using > channel.send but after I supposedly exited the program, the channel > doesn't close nor I get the exit_status from the server. Is this the > normal behavior? The command may not close the channel until you close the "stdin" pipe. If you close "stdin", you may get the remote command to close its own "stdout" and exit. It's also possible that "stdout" isn't closed because there's data waiting for you to read it. robey