From dwayne at oscl.ca Thu Dec 6 11:55:17 2007 From: dwayne at oscl.ca (Dwayne Litzenberger) Date: Thu, 6 Dec 2007 13:55:17 -0600 Subject: [paramiko] [MERGE] Add bufsize to SSHClient.exec_command Message-ID: <200712061355.18160.dwayne@oscl.ca> This patch adds a "bufsize" argument to SSHClient.exec_command. Note that, from what I can tell (I haven't delved into the workings of BufferedFile too much), BufferedFile._set_mode currently behaves identically when given bufsize=0 (unbuffered) and bufsize=-1 (system default). The result is that chan.makefile('wb') returns a ChannelFile instance with _no_ buffering, contrary to what one might expect. Cheers! -- 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/ -------------- next part -------------- A non-text attachment was scrubbed... Name: paramiko-sshclient-execcommand-bufsize.bundle Type: text/x-diff Size: 3141 bytes Desc: not available Url : http://www.lag.net/pipermail/paramiko/attachments/20071206/a058e650/attachment.diff From heine.andersen at gmail.com Fri Dec 7 15:34:12 2007 From: heine.andersen at gmail.com (Heine Andersen) Date: Sat, 8 Dec 2007 00:34:12 +0100 Subject: [paramiko] Problem using channels Message-ID: Hi, I'm trying to create a program that log in to a chain of hosts, and setup the users keys, to do this job I have created a recursive program, but the problem is that i only work for the first host i log in to. this is just a snip to show my problem, #!/usr/bin/env python import paramiko, socket, time, sys def exec_cmd(username, password, hostname, cmd): sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) sock.connect((hostname, 22)) transport = paramiko.Transport(sock) transport.connect(username=username, password=password) channel = transport.open_session() channel.setblocking(0) channel.set_combine_stderr(True) channel.exec_command(cmd) channel.send(password) rc = channel.recv_exit_status() cmdout = "" while channel.recv_ready() and rc != -1: cmdout += channel.recv(1024) transport.close() return cmdout if __name__ == "__main__": try: count = sys.argv[1] print count password = sys.stdin.read() password = password.strip(" \n") paramiko.util.log_to_file("para.log" + count, level=10) count = int(count) - 1 if count > 0: print exec_cmd("user", password, "localhost", "./paratest.py " + str(count)) except: print "Unexpected error:", sys.exc_info()[0] I run it like this : user at comp:~$ cat pw | ./paratest.py 2 2 If i hardcode the password instead of parssing it ( using stdin ) it's working great, anybody can tell me what I'm missing here ? regards From toddw at activestate.com Fri Dec 7 17:55:33 2007 From: toddw at activestate.com (Todd Whiteman) Date: Fri, 07 Dec 2007 17:55:33 -0800 Subject: [paramiko] Problem using channels In-Reply-To: References: Message-ID: <4759F995.7060705@activestate.com> Heine Andersen wrote: > Hi, > > I'm trying to create a program that log in to a chain of hosts, and > setup the users keys, > to do this job I have created a recursive program, but the problem is > that i only work for the first host i log in to. > > this is just a snip to show my problem, > > > password = sys.stdin.read() > password = password.strip(" \n") > sys.stdin.read() will read all of the input (multiple lines) in one go. The next time the code loops, it blocks at the sys.stdin.read() call, but there is no more data to read. You might want to use sys.stdin.readline() instead. Cheers, Todd From jbardin at bu.edu Fri Dec 7 20:04:31 2007 From: jbardin at bu.edu (james bardin) Date: Fri, 7 Dec 2007 23:04:31 -0500 Subject: [paramiko] Problem using channels In-Reply-To: <4759F995.7060705@activestate.com> References: <4759F995.7060705@activestate.com> Message-ID: I think that when you send the password to the next host, the program needs to get an EOF so the read() can finish and continue. I'm not really sure how to handle this though, as I don't think that readlines() will stop blocking either. For example the following won't finish until you press Ctrl+D #!/usr/bin/python import sys p = sys.stdin.readlines() print p An easy way out would be to allow the program to take the password as an optional argument, and pass everything to the next host in one string. -jim -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.lag.net/pipermail/paramiko/attachments/20071207/e5904bb8/attachment.htm From heine.andersen at gmail.com Fri Dec 7 23:57:04 2007 From: heine.andersen at gmail.com (Heine Andersen) Date: Sat, 8 Dec 2007 08:57:04 +0100 Subject: [paramiko] Problem using channels In-Reply-To: References: <4759F995.7060705@activestate.com> Message-ID: Thx for the suggestions, using readline doesn't solve the problem. The reason for not parsing the password as en argument, is that it would be revealed if another user do a ps -ef. But a hack could be to transfer it using sftp, then again if something goes wrong, I have all these small textfiles containing passwords floating around in the users homedirs :( On Dec 8, 2007 5:04 AM, james bardin wrote: > I think that when you send the password to the next host, the program needs > to get an EOF so the read() can finish and continue. > I'm not really sure how to handle this though, as I don't think that > readlines() will stop blocking either. > For example the following won't finish until you press Ctrl+D > #!/usr/bin/python > import sys > p = sys.stdin.readlines() > print p > > An easy way out would be to allow the program to take the password as an > optional argument, and pass everything to the next host in one string. > > -jim > From heine.andersen at gmail.com Sat Dec 8 17:09:01 2007 From: heine.andersen at gmail.com (Heine Andersen) Date: Sun, 9 Dec 2007 02:09:01 +0100 Subject: [paramiko] Problem using channels In-Reply-To: <4759F995.7060705@activestate.com> References: <4759F995.7060705@activestate.com> Message-ID: Must have been late last night, using readline works like a charm, thx ! On Dec 8, 2007 2:55 AM, Todd Whiteman wrote: > Heine Andersen wrote: > > Hi, > > > > I'm trying to create a program that log in to a chain of hosts, and > > setup the users keys, > > to do this job I have created a recursive program, but the problem is > > that i only work for the first host i log in to. > > > > this is just a snip to show my problem, > > > > > > password = sys.stdin.read() > > password = password.strip(" \n") > > > > sys.stdin.read() will read all of the input (multiple lines) in one go. > > The next time the code loops, it blocks at the sys.stdin.read() call, > but there is no more data to read. You might want to use > sys.stdin.readline() instead. > > Cheers, > Todd > From david at guerizec.net Sun Dec 9 13:10:18 2007 From: david at guerizec.net (David Guerizec) Date: Sun, 9 Dec 2007 22:10:18 +0100 Subject: [paramiko] patch for local port forwarding Message-ID: <200712092210.19431.david@guerizec.net> Hello Robey, I couldn't manage to make local forwarding (server side) to work in sshproxy, and looking at the paramiko sources, I couldn't find any hook to do it. So here is a patch, slightly adapted from the first one I sent a year ago. I'm currently entering the RC cycle for sshproxy-0.6, so it would be nice if the patch is merged before paramiko-1.7.2. If 1.7.2 is almost ready, I'll try to synchronize sshproxy-0.6 release date with paramiko to avoid distributing myself a patched version of paramiko. Best regards, David -------------- next part -------------- A non-text attachment was scrubbed... Name: local_port_forwarding.patch Type: text/x-diff Size: 3415 bytes Desc: not available Url : http://www.lag.net/pipermail/paramiko/attachments/20071209/b3cb2a55/attachment.patch From saint at akpa.pl Fri Dec 14 00:01:36 2007 From: saint at akpa.pl (=?iso-8859-2?B?Um9iZXJ0IKZ3aep0b2Nob3dza2k=?=) Date: Fri, 14 Dec 2007 09:01:36 +0100 Subject: [paramiko] SFTP connection to host outside a firewall Message-ID: Hi, How to write script implementing this: sftp -o "ProxyCommand ssh username1 at hostname1 sftp-proxy hostname2" username2 at hostname2 using paramiko? Best regards, Robert -- AKPA Polska Press Sp. z o.o., 02-221 Warszawa, ul. Zb?szy?ska 5, NIP 521-10-00-270 S?d Rejonowy dla m.st. Warszawy, XIII Wydzia? Gospodarczy KRS 0000023945; Kapita? zak?adowy 516.900,00 PLN (w ca?o?ci op?acony). From dwayne at oscl.ca Wed Dec 19 07:41:21 2007 From: dwayne at oscl.ca (Dwayne Litzenberger) Date: Wed, 19 Dec 2007 09:41:21 -0600 Subject: [paramiko] [PATCH] SSHClient, win_pageant and missing MFC71.DLL: Disallowing the use of ssh-agent Message-ID: <200712190941.22135.dwayne@oscl.ca> On machines that don't have MFC71.DLL installed, I get a modal dialog box when public key authentication fails: --------------------------- python.exe - Unable To Locate Component --------------------------- This application has failed to start because MFC71.DLL was not found. Re-installing the application may fix this problem. --------------------------- OK --------------------------- This dialog box blocks the process until somebody presses OK, which is bad for a background service. I've traced the problem to the following lines: client.py:398:for key in Agent().get_keys(): agent.py:68:import win_pageant win_pageant.py:35:import win32ui Agent.__init__ imports win_pageant, which attempts to import win32ui. Importing the win32ui module is what causes the dialog box to pop up. In my application, I don't want paramiko to try to talk to the agent anyway, since it needs to use an application-specific private key. I've attached a patch that adds an "allow_agent" parameter to SSHClient.connect(). Regards, - Dwayne -- Dwayne Litzenberger, B.A.Sc. Information Technology Analyst Open Systems Canada Limited #210 - 2332 11th Ave Regina, SK S4P0K1 Office: (306) 359-OSCL (6725) http://www.oscl.ca/ -------------- next part -------------- A non-text attachment was scrubbed... Name: paramiko-allow_agent.patch Type: text/x-diff Size: 2458 bytes Desc: not available Url : http://www.lag.net/pipermail/paramiko/attachments/20071219/c41b8816/attachment.patch From thk at kaotonik.net Thu Dec 20 11:03:09 2007 From: thk at kaotonik.net (thk) Date: Thu, 20 Dec 2007 21:03:09 +0200 Subject: [paramiko] SSHClient.exec_command , ChannelException: Administratively prohibited Message-ID: <476ABC6D.3030509@kaotonik.net> Hello. I am using paramiko.SSHClient in a python application I am building. I am issuing "cd" commands but it seems that SSHClient does not keep the session open so if I "cd" to another directory and issue "pwd" after , I am again in my home directory . I mean every command is like connecting again and being in the ~ directory. if I issue a command like " cd dir; pwd" then I see from the output of pwd that it has changed directory to dir. But not if I do : SSHClient.exec_command("cd dir") SSHClient.exec_command("pwd"). Am I missing something or is this the way paramiko supposed to work? Also: In another situation I am connecting with sshclient and then I issue commands on the remote host, at every 5000 milliseconds interval. After the 10th or so time , paramiko sshclient raises an exception: / File "/usr/lib/python2.5/site-packages/paramiko/client.py", line 314, in exec_command chan = self._transport.open_session() File "/usr/lib/python2.5/site-packages/paramiko/transport.py", line 595, in open_session return self.open_channel('session') File "/usr/lib/python2.5/site-packages/paramiko/transport.py", line 696, in open_channel raise e ChannelException: Administratively prohibited /If I catch the exception and try reconnect the loop goes on, but I have noticed on the ssh server, that every time the connections increase per one. So as you can figure there are left open connections. It seems that the SSHClient that raised the exception still has an open connection. So what is this : /ChannelException: Administratively prohibited/ and how do you propose I should handle this situation, meaning: A loop that executes some commands on the ssh server at every time interval. I want to connect once and stay connected and then execute commands , on each interval. Should i handle exceptions of paramiko? Ansd then if so, which ? Any help appreciated. Thanks. From jbardin at bu.edu Thu Dec 20 11:19:56 2007 From: jbardin at bu.edu (James Bardin) Date: Thu, 20 Dec 2007 14:19:56 -0500 Subject: [paramiko] SSHClient.exec_command , ChannelException: Administratively prohibited In-Reply-To: <476ABC6D.3030509@kaotonik.net> References: <476ABC6D.3030509@kaotonik.net> Message-ID: <476AC05C.40906@bu.edu> thk wrote: > Hello. > I am using paramiko.SSHClient in a python application I am building. I > am issuing "cd" commands but it seems that SSHClient does not keep the > session open so if I "cd" to another directory and issue "pwd" after , > I am again in my home directory . > I mean every command is like connecting again and being in the ~ directory. > if I issue a command like " cd dir; pwd" then I see from the output of > pwd that it has changed directory to dir. > But not if I do : > SSHClient.exec_command("cd dir") > SSHClient.exec_command("pwd"). > exec_command opens a new channel for each command. From channel.exec_command: " When the command finishes executing, the channel will be closed and can't be reused. You must open a new channel if you wish to execute another command." You probably want to look at SSHClient.invoke_shell(self, term='vt100', width=80, height=24) for an interactive shell. > Also: > In another situation I am connecting with sshclient and then I issue > commands > on the remote host, at every 5000 milliseconds interval. > > After the 10th or so time , > paramiko sshclient raises an exception: > > / File "/usr/lib/python2.5/site-packages/paramiko/client.py", line 314, > in exec_command > chan = self._transport.open_session() > File "/usr/lib/python2.5/site-packages/paramiko/transport.py", line > 595, in open_session > return self.open_channel('session') > File "/usr/lib/python2.5/site-packages/paramiko/transport.py", line > 696, in open_channel > raise e > ChannelException: Administratively prohibited > I think that's the server throttling your number of channels. You either need to maintain an open channel for subsequent commands, or send everything as one command. Take a look at interactive.py in the demos folder, and invoke_shell() in both client.py and channel.py -jim From thk at kaotonik.net Thu Dec 20 12:01:28 2007 From: thk at kaotonik.net (thk) Date: Thu, 20 Dec 2007 22:01:28 +0200 Subject: [paramiko] SSHClient.exec_command , ChannelException: Administratively prohibited 2 Message-ID: <476ACA18.8050303@kaotonik.net> James Bardin wrote: > thk wrote: >> Hello. >> I am using paramiko.SSHClient in a python application I am building. >> I am issuing "cd" commands but it seems that SSHClient does not keep >> the session open so if I "cd" to another directory and issue "pwd" >> after , I am again in my home directory . >> I mean every command is like connecting again and being in the ~ >> directory. >> if I issue a command like " cd dir; pwd" then I see from the output >> of pwd that it has changed directory to dir. >> But not if I do : >> SSHClient.exec_command("cd dir") >> SSHClient.exec_command("pwd"). >> > exec_command opens a new channel for each command. From > channel.exec_command: > " When the command finishes executing, the channel will be closed and > can't be reused. You must open a new channel if you wish to > execute > another command." > > You probably want to look at SSHClient.invoke_shell(self, > term='vt100', width=80, height=24) for an interactive shell. > >> Also: >> In another situation I am connecting with sshclient and then I issue >> commands >> on the remote host, at every 5000 milliseconds interval. >> >> After the 10th or so time , >> paramiko sshclient raises an exception: >> >> / File "/usr/lib/python2.5/site-packages/paramiko/client.py", line >> 314, in exec_command >> chan = self._transport.open_session() >> File "/usr/lib/python2.5/site-packages/paramiko/transport.py", line >> 595, in open_session >> return self.open_channel('session') >> File "/usr/lib/python2.5/site-packages/paramiko/transport.py", line >> 696, in open_channel >> raise e >> ChannelException: Administratively prohibited >> > I think that's the server throttling your number of channels. But aren't the channels closing? > You either need to maintain an open channel for subsequent commands, > or send everything as one command. > > Take a look at interactive.py in the demos folder, and invoke_shell() > in both client.py and channel.py > > > -jim > Thanks for the reply. Basically i am looking for a non blocking way to execute commands on the server. I believe if i use interactive_shell I have to implement it with threads so I can code a non blocking function , because these methods block ? So one alternative is to do a transport connect and the in each loop get a new channel with t.open_session()? From jbardin at bu.edu Thu Dec 20 12:25:28 2007 From: jbardin at bu.edu (James Bardin) Date: Thu, 20 Dec 2007 15:25:28 -0500 Subject: [paramiko] SSHClient.exec_command , ChannelException: Administratively prohibited In-Reply-To: <476AC6CF.20906@kaotonik.net> References: <476ABC6D.3030509@kaotonik.net> <476AC05C.40906@bu.edu> <476AC6CF.20906@kaotonik.net> Message-ID: <476ACFB8.8080008@bu.edu> thk wrote: >>> >> I think that's the server throttling your number of channels. > > But aren't the channels closing? > I would think so, but maybe the server takes longer to give up on the connections. "Administratively prohibited" is a failure code from the server, so I would look at the server logs (in debug if you can). > Thanks for the reply. > Basically i am looking for a non blocking way to execute commands on > the server. > I believe if i use interactive_shell I have to implement it with > threads so I can code a non blocking function , because these methods > block ? But won't anything with a read() be blocking? If read() would block because the server is still sending data, you would need a new channel anyways. > > So one alternative is to do a transport connect and the in each loop > get a new channel with t.open_session()? > This is exactly what exec_command is doing, so I don't think it would help. If you're not on windows, maybe you could use select.select() (python module) to check the status of the stdout so you don't need to go into a blocking state to read?? -jim From robey at lag.net Sun Dec 30 16:36:33 2007 From: robey at lag.net (Robey Pointer) Date: Sun, 30 Dec 2007 16:36:33 -0800 Subject: [paramiko] [MERGE] Add bufsize to SSHClient.exec_command In-Reply-To: <200712061355.18160.dwayne@oscl.ca> References: <200712061355.18160.dwayne@oscl.ca> Message-ID: <87A75F6C-92AD-4101-AA2D-3C8D1F6628AE@lag.net> On 6 Dec 2007, at 11:55, Dwayne Litzenberger wrote: > This patch adds a "bufsize" argument to SSHClient.exec_command. > > Note that, from what I can tell (I haven't delved into the workings of > BufferedFile too much), BufferedFile._set_mode currently behaves > identically > when given bufsize=0 (unbuffered) and bufsize=-1 (system default). > The > result is that chan.makefile('wb') returns a ChannelFile instance > with _no_ > buffering, contrary to what one might expect. Thanks, merged! I've found that over a socket, having writes buffered by default is a good way to cause confusion and despair, since most people assume that when they call write() it will immediately go out. :) robey From robey at lag.net Sun Dec 30 21:30:59 2007 From: robey at lag.net (Robey Pointer) Date: Sun, 30 Dec 2007 21:30:59 -0800 Subject: [paramiko] patch for local port forwarding In-Reply-To: <200712092210.19431.david@guerizec.net> References: <200712092210.19431.david@guerizec.net> Message-ID: <1F8EDCB0-54FA-473E-8AF5-9AAC680C3C30@lag.net> On 9 Dec 2007, at 13:10, David Guerizec wrote: > Hello Robey, > > I couldn't manage to make local forwarding (server side) to work in > sshproxy, > and looking at the paramiko sources, I couldn't find any hook to do > it. > > So here is a patch, slightly adapted from the first one I sent a > year ago. > > I'm currently entering the RC cycle for sshproxy-0.6, so it would be > nice if > the patch is merged before paramiko-1.7.2. > If 1.7.2 is almost ready, I'll try to synchronize sshproxy-0.6 > release date > with paramiko to avoid distributing myself a patched version of > paramiko. Thanks, I merged the patch with one change (you had originator and destination fields reversed, according to the RFC) and with a unit test added. robey From robey at lag.net Sun Dec 30 22:11:26 2007 From: robey at lag.net (Robey Pointer) Date: Sun, 30 Dec 2007 22:11:26 -0800 Subject: [paramiko] Debugging a remote connection In-Reply-To: <7c25bb490711161228s50bcf61bgc9f158f4f1123ac8@mail.gmail.com> References: <7c25bb490711161228s50bcf61bgc9f158f4f1123ac8@mail.gmail.com> Message-ID: <251A8FFB-B1C0-4352-B132-CF141D0C92B0@lag.net> On 16 Nov 2007, at 12:28, jay wrote: > 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? Unfortunately, the logs are only saying what you said: password auth is allowed, but the password isn't accepted by the server. Beyond the obvious (make sure the password is spelled out correctly), I can't think of any suggestions. It's possible your other sessions are using a private key to auth, and the password is being used to unlock the key. So you might check for a key in ~/.ssh/ just in case. robey From colinlandrum at gmail.com Mon Dec 31 15:55:55 2007 From: colinlandrum at gmail.com (Colin Landrum) Date: Mon, 31 Dec 2007 15:55:55 -0800 Subject: [paramiko] compiling pycrypto on AIX Message-ID: <35dab7eb0712311555p1592c352s83ba7e349dfbb551@mail.gmail.com> I am trying to install Paramiko on an AIX box that doesn't have cc_r. It does have gcc. running python setup.py build --help-compiler just tells me --compiler=unix standard UNIX-style compiler If I try python setup.py build -c gcc it tells me: running build running build_py running build_ext error: don't know how to compile C/C++ code on platform 'posix' with 'gcc' compiler How can I use gcc already!!??! thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.lag.net/pipermail/paramiko/attachments/20071231/180e47dd/attachment.htm