From tim.mann at bt.com Thu Feb 1 02:53:49 2007 From: tim.mann at bt.com (tim.mann at bt.com) Date: Wed, 31 Jan 2007 15:53:49 -0000 Subject: Patch to fix the 255 status code problem Message-ID: Hi, Currently using openssh-4.5p1 on Solaris 8 in conjunction with Oracle 8i dataguard. Is there a patch available to prevent ssh returning status code 255 for a successful execution of a remote connection/command. Many Thanks, Tim Mann From tim.mann at bt.com Thu Feb 1 03:48:39 2007 From: tim.mann at bt.com (tim.mann at bt.com) Date: Wed, 31 Jan 2007 16:48:39 -0000 Subject: Patch to fix the 255 status code problem Message-ID: Hi, Thanks for your reply. I'm having problems with a dataguard deployment using Oracle 8.1.7.4. I found an article on Metalink which seem to explain the problem I was having. It states that with openssh (on Solaris) it returns status code 255 for a successful execution and this is interpreted by dataguard as a connection failure. When I run ssh on the command line everything is fine. The other solution the article states is to use SSH1 instead. Regards, Tim -----Original Message----- From: Daniel Kahn Gillmor [mailto:dkg-openssh.com at fifthhorseman.net] Sent: 31 January 2007 16:40 To: Mann,TJ,Tim,XWK3 R Cc: openssh-unix-dev at mindrot.org Subject: Re: Patch to fix the 255 status code problem At 2007-01-31 15:53, tim.mann at bt.com said: > Currently using openssh-4.5p1 on Solaris 8 in conjunction with Oracle > 8i dataguard. Is there a patch available to prevent ssh returning > status code 255 for a successful execution of a remote > connection/command. I believe it should already do what you need. the man page [0] says: ssh exits with the exit status of the remote command or with 255 if an error occurred. Can you provide more details about the problem you're having? The behavior it sounds like you want is already present on my setup here (openssh 4.2p1 and 3.8.1p1 on linux 2.6). My prompt shows the return value of the previous command: [0 dkg at baboon ~]$ ssh gorilla true [0 dkg at baboon ~]$ ssh gorilla false [1 dkg at baboon ~]$ hth, --dkg [0] http://www.openbsd.org/cgi-bin/man.cgi?query=ssh From dkg-openssh.com at fifthhorseman.net Thu Feb 1 03:39:40 2007 From: dkg-openssh.com at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 31 Jan 2007 11:39:40 -0500 Subject: Patch to fix the 255 status code problem In-Reply-To: References: Message-ID: <17856.50764.391018.851997@squeak.fifthhorseman.net> At 2007-01-31 15:53, tim.mann at bt.com said: > Currently using openssh-4.5p1 on Solaris 8 in conjunction with > Oracle 8i dataguard. Is there a patch available to prevent ssh > returning status code 255 for a successful execution of a remote > connection/command. I believe it should already do what you need. the man page [0] says: ssh exits with the exit status of the remote command or with 255 if an error occurred. Can you provide more details about the problem you're having? The behavior it sounds like you want is already present on my setup here (openssh 4.2p1 and 3.8.1p1 on linux 2.6). My prompt shows the return value of the previous command: [0 dkg at baboon ~]$ ssh gorilla true [0 dkg at baboon ~]$ ssh gorilla false [1 dkg at baboon ~]$ hth, --dkg [0] http://www.openbsd.org/cgi-bin/man.cgi?query=ssh From djm at mindrot.org Thu Feb 1 05:01:34 2007 From: djm at mindrot.org (Damien Miller) Date: Thu, 1 Feb 2007 05:01:34 +1100 (EST) Subject: Patch to fix the 255 status code problem In-Reply-To: References: Message-ID: On Wed, 31 Jan 2007, tim.mann at bt.com wrote: > Hi, > > Thanks for your reply. > > I'm having problems with a dataguard deployment using Oracle 8.1.7.4. I > found an article on Metalink which seem to explain the problem I was > having. It states that with openssh (on Solaris) it returns status code > 255 for a successful execution and this is interpreted by dataguard as a > connection failure. My guess would be that dataguard is exiting abnormally. Exit code 255 is returned when the child process exited due to reception of a signal (including crashes due to SIGSEGV/SIGBUS/SIGABORT): [djm at fuyu djm]$ ssh localhost false ; echo $? 1 [djm at fuyu djm]$ ssh localhost true ; echo $? 0 [djm at fuyu djm]$ ssh localhost 'sh -c "kill -SEGV $$"' ; echo $? 255 SSH protocol 1 has no way to signal that the child process terminated abnormally. -d From dtucker at zip.com.au Thu Feb 1 07:06:03 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 1 Feb 2007 07:06:03 +1100 Subject: Patch to fix the 255 status code problem In-Reply-To: References: Message-ID: <20070131200603.GA8775@gate.dtucker.net> On Wed, Jan 31, 2007 at 04:48:39PM -0000, tim.mann at bt.com wrote: > I'm having problems with a dataguard deployment using Oracle 8.1.7.4. I > found an article on Metalink which seem to explain the problem I was > having. It states that with openssh (on Solaris) it returns status code > 255 for a successful execution and this is interpreted by dataguard as a > connection failure. > > When I run ssh on the command line everything is fine. What's the server at the other end? I vaguely recall a problem something like that when the server is SunSSH. Can you run ssh with -vvv and redirect stderr to a file? Maybe with a wrapper script? -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dmprantz at yahoo.com Thu Feb 1 16:58:20 2007 From: dmprantz at yahoo.com (Pomerantz Daniel) Date: Wed, 31 Jan 2007 21:58:20 -0800 (PST) Subject: OpenSSH port to the .Net Platform Message-ID: <868057.73009.qm@web56311.mail.re3.yahoo.com> I am interested in starting a project to port stable versions of OpenSSH to C#, compilable as a stable .Net Library. I was wondering what the list's feelings would be on such a port, if any one else would be interested in such a port, and for any suggestions on raising interest from others to perform such a port. I have nothing against Java and would welcome a similar effort from that arena. I am tempted to suggest Java / J# only, but I feel that would alienate many c# users. Any information or advice would be appreciated. Please bcc: this eMail address in any replies. Thanks! dmp ____________________________________________________________________________________ Never Miss an Email Stay connected with Yahoo! Mail on your mobile. Get started! http://mobile.yahoo.com/services?promote=mail From stuge-openssh-unix-dev at cdy.org Fri Feb 2 02:36:17 2007 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Thu, 1 Feb 2007 16:36:17 +0100 Subject: OpenSSH port to the .Net Platform In-Reply-To: <868057.73009.qm@web56311.mail.re3.yahoo.com> References: <868057.73009.qm@web56311.mail.re3.yahoo.com> Message-ID: <20070201153617.2253.qmail@cdy.org> On Wed, Jan 31, 2007 at 09:58:20PM -0800, Pomerantz Daniel wrote: > I am interested in starting a project to port stable versions of > OpenSSH to C#, compilable as a stable .Net Library. I was > wondering what the list's feelings would be on such a port, I don't think anyone would oppose it, but beware that OpenSSH assumes a POSIX(-ish) system in many places. I think that will cause headache with C# or J or any other non-POSIX:ish system. //Peter From kruse at silicann.com Fri Feb 2 02:28:24 2007 From: kruse at silicann.com (Lars Kruse) Date: Thu, 1 Feb 2007 16:28:24 +0100 Subject: X forwarding: trying to forward to busy local port Message-ID: <20070201162824.6d5f8b77@jackdaw.neusy> Hi, Summary of my problem: Remote X forwarding is apperently randomly impossible for different display numbers. At the end of this mail you will find a recipe for how to reproduce this behaviour easily. I use SuSE 10.2 with the following openssh version: OpenSSH_4.4p1, OpenSSL 0.9.8d 28 Sep 2006 Clients (Linux and Windows (Cygwin)) connect to the server with X-Forwarding enabled ("-X" or "-Y"). The ssh server gives away local ports above 6010 for the X connections of these clients. (default setup) This setup works very stable (for years), BUT sometimes (every few weeks) I receive "can't connect" errors, after opening a ssh connection (successfully) and trying to run a remote X.program (e.g. xev). For example: after connecting to the server (ssh -X ...), the DISPLAY environment setting is "localhost:18". See the following output: jackdaw:~ # netstat -lpn| grep 60 tcp 0 0 127.0.0.1:6016 0.0.0.0:* LISTEN 24607/sshd: jens at no tcp 0 0 127.0.0.1:6017 0.0.0.0:* LISTEN 25900/sshd: michael tcp 0 0 127.0.0.1:6019 0.0.0.0:* LISTEN 18030/sshd: lars at no tcp 0 0 127.0.0.1:6010 0.0.0.0:* LISTEN 519/sshd: steffen at n tcp 0 0 127.0.0.1:6011 0.0.0.0:* LISTEN 12190/sshd: ansgar@ tcp 0 0 127.0.0.1:6012 0.0.0.0:* LISTEN 25795/sshd: norbert tcp 0 0 127.0.0.1:6013 0.0.0.0:* LISTEN 13587/sshd: henning tcp 0 0 127.0.0.1:6014 0.0.0.0:* LISTEN 14594/sshd: diana at n tcp 0 0 127.0.0.1:6015 0.0.0.0:* LISTEN 15447/sshd: axel at no tcp 0 0 ::1:6016 :::* LISTEN 24607/sshd: jens at no tcp 0 0 ::1:6017 :::* LISTEN 25900/sshd: michael tcp 0 0 ::1:6018 :::* LISTEN 26589/sshd: lars at no tcp 0 0 ::1:6019 :::* LISTEN 18030/sshd: lars at no tcp 0 0 ::1:6010 :::* LISTEN 519/sshd: steffen at n tcp 0 0 ::1:6011 :::* LISTEN 12190/sshd: ansgar@ tcp 0 0 ::1:6012 :::* LISTEN 25795/sshd: norbert tcp 0 0 ::1:6013 :::* LISTEN 13587/sshd: henning tcp 0 0 ::1:6014 :::* LISTEN 14594/sshd: diana at n tcp 0 0 ::1:6015 :::* LISTEN 15447/sshd: axel at no Out of some reason, port 6018 on 127.0.0.1 is not used by sshd (but it should: see "::1:6018" below). Further investigations lead to the following: jackdaw:~ # netstat -pn | grep ":6016" tcp 0 0 127.0.0.1:6016 127.0.0.1:6039 ESTABLISHED 14279/sshd: jens at no tcp 0 0 127.0.0.1:6016 127.0.0.1:6038 ESTABLISHED 14279/sshd: jens at no tcp 0 0 127.0.0.1:6016 127.0.0.1:6037 ESTABLISHED 14279/sshd: jens at no tcp 0 0 127.0.0.1:6016 127.0.0.1:6047 ESTABLISHED 14279/sshd: jens at no tcp 0 0 127.0.0.1:6016 127.0.0.1:24990 ESTABLISHED 14279/sshd: jens at no tcp 0 0 127.0.0.1:6016 127.0.0.1:6045 ESTABLISHED 14279/sshd: jens at no tcp 0 0 127.0.0.1:6016 127.0.0.1:6044 ESTABLISHED 14279/sshd: jens at no tcp 0 0 127.0.0.1:6016 127.0.0.1:6040 ESTABLISHED 14279/sshd: jens at no tcp 0 0 127.0.0.1:6016 127.0.0.1:6023 ESTABLISHED 14279/sshd: jens at no tcp 0 0 127.0.0.1:6016 127.0.0.1:6022 ESTABLISHED 14279/sshd: jens at no tcp 0 0 127.0.0.1:6016 127.0.0.1:6018 ESTABLISHED 14279/sshd: jens at no tcp 0 0 127.0.0.1:6016 127.0.0.1:6017 ESTABLISHED 14279/sshd: jens at no tcp 0 0 127.0.0.1:6017 127.0.0.1:6016 ESTABLISHED 14353/kdeinit Runni tcp 0 0 127.0.0.1:6018 127.0.0.1:6016 ESTABLISHED 14360/kded [kdeinit tcp 0 0 127.0.0.1:6022 127.0.0.1:6016 ESTABLISHED 14367/ksmserver [kd tcp 0 0 127.0.0.1:6023 127.0.0.1:6016 ESTABLISHED 14368/kwin [kdeinit tcp 0 0 127.0.0.1:6024 127.0.0.1:6016 ESTABLISHED 14370/kdesktop [kde tcp 0 0 127.0.0.1:6025 127.0.0.1:6016 ESTABLISHED 14372/kicker [kdein tcp 0 0 127.0.0.1:6037 127.0.0.1:6016 ESTABLISHED 14380/amarokapp tcp 0 0 127.0.0.1:6038 127.0.0.1:6016 ESTABLISHED 14382/kerry [kdeini tcp 0 0 127.0.0.1:6039 127.0.0.1:6016 ESTABLISHED 14360/kded [kdeinit tcp 0 0 127.0.0.1:6040 127.0.0.1:6016 ESTABLISHED 14358/klauncher [kd tcp 0 0 127.0.0.1:6044 127.0.0.1:6016 ESTABLISHED 14392/knotify [kdei tcp 0 0 127.0.0.1:6045 127.0.0.1:6016 ESTABLISHED 14396/konqueror [kd tcp 0 0 127.0.0.1:6047 127.0.0.1:6016 ESTABLISHED 14407/klipper [kdei tcp 0 0 127.0.0.1:6058 127.0.0.1:6016 ESTABLISHED 14436/beagled tcp 0 0 127.0.0.1:6068 127.0.0.1:6016 ESTABLISHED 14450/firefox-bin tcp 0 0 127.0.0.1:6016 127.0.0.1:6025 ESTABLISHED 14279/sshd: jens at no tcp 0 0 127.0.0.1:6016 127.0.0.1:6024 ESTABLISHED 14279/sshd: jens at no tcp 0 0 127.0.0.1:6016 127.0.0.1:6068 ESTABLISHED 14279/sshd: jens at no tcp 0 0 127.0.0.1:6016 127.0.0.1:6058 ESTABLISHED 14279/sshd: jens at no tcp 0 0 127.0.0.1:17119 127.0.0.1:6016 ESTABLISHED 14487/beagled-helpe tcp 0 0 127.0.0.1:17103 127.0.0.1:6016 ESTABLISHED 14450/firefox-bin tcp 0 0 127.0.0.1:6016 127.0.0.1:17119 ESTABLISHED 14279/sshd: jens at no tcp 0 0 127.0.0.1:6016 127.0.0.1:17103 ESTABLISHED 14279/sshd: jens at no tcp 0 0 127.0.0.1:24990 127.0.0.1:6016 ESTABLISHED 16717/sunbird-bin It seems like the user (in this example: "jens") was connected to localhost:16 via "ssh -X ...". This X forwarding opened a port for every X program within the session, Now comes the problem: The ports that were used, are within the range of the ports that are used for new X forwarding connections as well. This leads to problems for users trying to connect to the server, later. After the user on port 6016 disconnected and reconnected again, the problem was gone - his programs used a different (random?) port range for connections. There was no problem to create new sessions, anymore. Maybe the real root of the problem is, that the ssh server does not check, if a port is already in use, when it creates the DISPLAY setting for a new connection. In this case, it should have noticed, that the ports 6017 and 6018 are already in use and should announce a "localhost:19" DISPLAY setting to the next new X forwarding session (skipping the unusable "localhost:17" and "..:18"). How to reproduce the problem (using netcat): 1) setup an ssh server with X forwarding enabled 2) check open X forwarded sessions with "netstat -lpn | grep ':60'" 3) run "netcat -l -p 6010" (use the lowest free port number greater or equal to 6010) - this blocks the specific port 4) connect to the server and run a X program, e.g.: "ssh -X $HOST xeyes" Result: sshd cannot use the (blocked) port - so the client cannot run X programs. Is there a possible workaround how to tell the server, that it may not forward local X connections to ports that are within a specific range (in this case maybe 6000-6100)? Maybe it would be good, only to use dynamic port numbers for new processes that are far away from the port range needed by the ssh daemon for new connections? Or are there any other solutions? thanks for your hard work, Lars From dmprantz at yahoo.com Fri Feb 2 06:49:50 2007 From: dmprantz at yahoo.com (Pomerantz Daniel) Date: Thu, 1 Feb 2007 11:49:50 -0800 (PST) Subject: OpenSSH port to the .Net Platform In-Reply-To: <45C24096.1050708@anl.gov> Message-ID: <892951.16587.qm@web56304.mail.re3.yahoo.com> Thanks for the reply, I'm actually using PuTTY on the computer hosting this eMail right now. PuTTY is fine, but it is a C program. As far as I can tell, it is no more callable from .Net than OpenSSH is already. I have a need to customize OpenSSH, particularly sftp. Sometimes I may be wanting to send/receive a file directly from code, but other times I need to mess with the individual bytes that are being sent or received. I have done that in C, but C# would be much easier for *me* to integrate with other projects and debug. After I wrote the intiial eMail, I thought about the issue some more. I came the the conclusion that porting OpenSSH would likely not be too difficult. No offense to the hard work that the OpenSSH developers have put into the product, but because of how wonderful the code is, porting it to C#, making calls more .Net based in stead of C API based, creating classes to do the work in stead of procedures would probably be quite simple. The more difficult part (to me at first glance) would be to do it in a way that allow future versions of OpenSSH to be integrated in. I would like to avoid a pure fork, but I'm not sure how possible that is. Any further advice would be appreciated. dmp --- "Douglas E. Engert" wrote: > Any reason you don't start with PuTTY? Its already a Windows > based ssh client. Goolge for PuTTY and for PuTTY gssapi > > http://www.chiark.greenend.org.uk/~sgtatham/putty/ > > http://www.sweb.cz/v_t_m/ > > > A C# based program might be interesting, as long as it follows > all the SSH protocols. > > > Pomerantz Daniel wrote: > > I am interested in starting a project to port stable versions of > > OpenSSH to C#, compilable as a stable .Net Library. I was > wondering > > what the list's feelings would be on such a port, if any one else > would > > be interested in such a port, and for any suggestions on raising > > interest from others to perform such a port. I have nothing > against > > Java and would welcome a similar effort from that arena. I am > tempted > > to suggest Java / J# only, but I feel that would alienate many c# > > users. Any information or advice would be appreciated. Please > bcc: > > this eMail address in any replies. Thanks! > > > > dmp ____________________________________________________________________________________ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com From jochen.kirn at gmail.com Fri Feb 2 01:35:47 2007 From: jochen.kirn at gmail.com (Jochen Kirn) Date: Thu, 1 Feb 2007 15:35:47 +0100 Subject: unexpected error message ( ...[auth.error] error: channel 0: chan_read_failed for istate 3) Message-ID: <4bd05a460702010635p524b1ff8m41df5e7182629b36@mail.gmail.com> Hi, when scp'ing a file from hostA to hostB I receive following error message on the server side. Message in authlog: Jan 9 15:01:32 zapphod sshd[3229]: [ID 800047 auth.error] error: channel 0: chan_read_failed for istate 3 The file itself is transfered correctly, so I'm wondering why this error is being logged and what this error message means It seems that the occurance of this message is not platform specific, as I have tested it on following systems platform: SuSE SLES 9, Solaris 8 & 9 SSH version: OpenSSH 4.5p1 + OpenSSL 0.98d does anybody have an idea, what's the reason for this error message ? thanks Jochen From deengert at anl.gov Fri Feb 2 09:49:26 2007 From: deengert at anl.gov (Douglas E. Engert) Date: Thu, 01 Feb 2007 16:49:26 -0600 Subject: OpenSSH port to the .Net Platform In-Reply-To: <892951.16587.qm@web56304.mail.re3.yahoo.com> References: <892951.16587.qm@web56304.mail.re3.yahoo.com> Message-ID: <45C26E76.30700@anl.gov> Pomerantz Daniel wrote: > Thanks for the reply, > > I'm actually using PuTTY on the computer hosting this eMail right now. > PuTTY is fine, but it is a C program. As far as I can tell, it is no > more callable from .Net than OpenSSH is already. I have a need to > customize OpenSSH, particularly sftp. Sometimes I may be wanting to > send/receive a file directly from code, but other times I need to mess > with the individual bytes that are being sent or received. I have done > that in C, but C# would be much easier for *me* to integrate with other > projects and debug. > > After I wrote the intiial eMail, I thought about the issue some more. > I came the the conclusion that porting OpenSSH would likely not be too > difficult. No offense to the hard work that the OpenSSH developers > have put into the product, but because of how wonderful the code is, > porting it to C#, making calls more .Net based in stead of C API based, > creating classes to do the work in stead of procedures would probably > be quite simple. The more difficult part (to me at first glance) would > be to do it in a way that allow future versions of OpenSSH to be > integrated in. I would like to avoid a pure fork, but I'm not sure how > possible that is. Any further advice would be appreciated. > > dmp Did you Google for C# SSH There appears to be some some implementations, both comercial and open source. http://csharp-source.net/open-source/network-clients http://www.codeproject.com/cs/internet/sharpssh.asp > > > --- "Douglas E. Engert" wrote: > >> Any reason you don't start with PuTTY? Its already a Windows >> based ssh client. Goolge for PuTTY and for PuTTY gssapi >> >> http://www.chiark.greenend.org.uk/~sgtatham/putty/ >> >> http://www.sweb.cz/v_t_m/ >> >> >> A C# based program might be interesting, as long as it follows >> all the SSH protocols. >> >> >> Pomerantz Daniel wrote: >>> I am interested in starting a project to port stable versions of >>> OpenSSH to C#, compilable as a stable .Net Library. I was >> wondering >>> what the list's feelings would be on such a port, if any one else >> would >>> be interested in such a port, and for any suggestions on raising >>> interest from others to perform such a port. I have nothing >> against >>> Java and would welcome a similar effort from that arena. I am >> tempted >>> to suggest Java / J# only, but I feel that would alienate many c# >>> users. Any information or advice would be appreciated. Please >> bcc: >>> this eMail address in any replies. Thanks! >>> >>> dmp > > > > > ____________________________________________________________________________________ > Do you Yahoo!? > Everyone is raving about the all-new Yahoo! Mail beta. > http://new.mail.yahoo.com > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From dmprantz at yahoo.com Fri Feb 2 09:54:05 2007 From: dmprantz at yahoo.com (Pomerantz Daniel) Date: Thu, 1 Feb 2007 14:54:05 -0800 (PST) Subject: OpenSSH port to the .Net Platform In-Reply-To: <45C26E76.30700@anl.gov> Message-ID: <20070201225405.41778.qmail@web56303.mail.re3.yahoo.com> I did search, apparently not very well. I found three commercial libraries, but no Free ones. Interestingly enough, SharpSSH was what I envisioned calling a project, and it already exists. Thanks for the links. I shall research. dmp --- "Douglas E. Engert" wrote: > > > Pomerantz Daniel wrote: > > Thanks for the reply, > > > > I'm actually using PuTTY on the computer hosting this eMail right > now. > > PuTTY is fine, but it is a C program. As far as I can tell, it is > no > > more callable from .Net than OpenSSH is already. I have a need to > > customize OpenSSH, particularly sftp. Sometimes I may be wanting > to > > send/receive a file directly from code, but other times I need to > mess > > with the individual bytes that are being sent or received. I have > done > > that in C, but C# would be much easier for *me* to integrate with > other > > projects and debug. > > > > After I wrote the intiial eMail, I thought about the issue some > more. > > I came the the conclusion that porting OpenSSH would likely not be > too > > difficult. No offense to the hard work that the OpenSSH developers > > have put into the product, but because of how wonderful the code > is, > > porting it to C#, making calls more .Net based in stead of C API > based, > > creating classes to do the work in stead of procedures would > probably > > be quite simple. The more difficult part (to me at first glance) > would > > be to do it in a way that allow future versions of OpenSSH to be > > integrated in. I would like to avoid a pure fork, but I'm not sure > how > > possible that is. Any further advice would be appreciated. > > > > dmp > > Did you Google for C# SSH > There appears to be some some implementations, both comercial > and open source. > > http://csharp-source.net/open-source/network-clients > > http://www.codeproject.com/cs/internet/sharpssh.asp > > > > > > > > --- "Douglas E. Engert" wrote: > > > >> Any reason you don't start with PuTTY? Its already a Windows > >> based ssh client. Goolge for PuTTY and for PuTTY gssapi > >> > >> http://www.chiark.greenend.org.uk/~sgtatham/putty/ > >> > >> http://www.sweb.cz/v_t_m/ > >> > >> > >> A C# based program might be interesting, as long as it follows > >> all the SSH protocols. > >> > >> > >> Pomerantz Daniel wrote: > >>> I am interested in starting a project to port stable versions of > >>> OpenSSH to C#, compilable as a stable .Net Library. I was > >> wondering > >>> what the list's feelings would be on such a port, if any one else > >> would > >>> be interested in such a port, and for any suggestions on raising > >>> interest from others to perform such a port. I have nothing > >> against > >>> Java and would welcome a similar effort from that arena. I am > >> tempted > >>> to suggest Java / J# only, but I feel that would alienate many c# > >>> users. Any information or advice would be appreciated. Please > >> bcc: > >>> this eMail address in any replies. Thanks! > >>> > >>> dmp > > > > > > > > > > > ____________________________________________________________________________________ > > Do you Yahoo!? > > Everyone is raving about the all-new Yahoo! Mail beta. > > http://new.mail.yahoo.com > > _______________________________________________ > > openssh-unix-dev mailing list > > openssh-unix-dev at mindrot.org > > http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > > > > > > -- > > Douglas E. Engert > Argonne National Laboratory > 9700 South Cass Avenue > Argonne, Illinois 60439 > (630) 252-5444 > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From arthuro20032004 at yahoo.fr Fri Feb 2 19:57:26 2007 From: arthuro20032004 at yahoo.fr (cyrilparis) Date: Fri, 2 Feb 2007 08:57:26 +0000 (GMT) Subject: Tunnel ssh / modifie http headers Message-ID: <550878.69769.qm@web26512.mail.ukl.yahoo.com> Hi, I m using ssh to make tunnels i would like to know if it is technically possible to modify ssh serveur to modify http header (to put in header a new line containing IP of client using tunnel) Help would be much appreciate Thanks ___________________________________________________________________________ D?couvrez une nouvelle fa?on d'obtenir des r?ponses ? toutes vos questions ! Profitez des connaissances, des opinions et des exp?riences des internautes sur Yahoo! Questions/R?ponses http://fr.answers.yahoo.com From deepakd.82 at gmail.com Fri Feb 2 19:17:05 2007 From: deepakd.82 at gmail.com (Deepak D) Date: Fri, 2 Feb 2007 17:17:05 +0900 Subject: Open SSH : SFTP Query Message-ID: <1135d14b0702020017j2c6a8d61uec208027c8843906@mail.gmail.com> Dear Respected One, I am Deepak. I am currently working on SFTP application. I ve downloaded your opnessh 4.5 (latest ve rsion). I want a simple sftp library which I can link to my test application and perform ftp operati ons. Is it possible to seperate sftp out of ssh and form a sftp library ? And also please provide me the APIs in sftp which are similar to login, connect, get, put etc APIs in the normal FTP libraries . Since I am very new to this SFTP, i am not able to find out the similar APIs in this SFTP package. Please help me in this regard. Thank You & Regards, Deepak D. From stuge-openssh-unix-dev at cdy.org Sat Feb 3 11:40:18 2007 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Sat, 3 Feb 2007 01:40:18 +0100 Subject: Tunnel ssh / modifie http headers In-Reply-To: <550878.69769.qm@web26512.mail.ukl.yahoo.com> References: <550878.69769.qm@web26512.mail.ukl.yahoo.com> Message-ID: <20070203004018.5209.qmail@cdy.org> On Fri, Feb 02, 2007 at 08:57:26AM +0000, cyrilparis wrote: > Hi, > > I m using ssh to make tunnels > i would like to know if it is technically possible to modify ssh > serveur to modify http header (to put in header a new line > containing IP of client using tunnel) > > Help would be much appreciate I'm not sure what you want to accomplish, but perhaps the ProxyCommand option can be used for it? //Peter From stuge-openssh-unix-dev at cdy.org Sat Feb 3 11:49:40 2007 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Sat, 3 Feb 2007 01:49:40 +0100 Subject: Open SSH : SFTP Query In-Reply-To: <1135d14b0702020017j2c6a8d61uec208027c8843906@mail.gmail.com> References: <1135d14b0702020017j2c6a8d61uec208027c8843906@mail.gmail.com> Message-ID: <20070203004940.6499.qmail@cdy.org> Hello Deepak, On Fri, Feb 02, 2007 at 05:17:05PM +0900, Deepak D wrote: > I want a simple sftp library which I can link to my test > application and perform ftp operations. Is it possible to seperate > sftp out of ssh and form a sftp library ? It is certainly possible, but.. > And also please provide me the APIs in sftp which are similar to > login, connect, get, put etc APIs in the normal FTP libraries. > Since I am very new to this SFTP, i am not able to find out the > similar APIs in this SFTP package. > Please help me in this regard. OpenSSH sftp is not intended to be a library, and that means it would require a lot of work to transform it into one. The recommended way to interface with the sftp program in OpenSSH is through sftp batch files and/or popen(). //Peter From matt.anderson at malloc.org Sat Feb 3 16:51:24 2007 From: matt.anderson at malloc.org (Matt Anderson) Date: Sat, 3 Feb 2007 00:51:24 -0500 Subject: Verbose messaging about why public key auth was rejected In-Reply-To: <3109E259-4D89-4A8D-A218-A10A5D16CD92@neomindstudio.com> References: <3109E259-4D89-4A8D-A218-A10A5D16CD92@neomindstudio.com> Message-ID: <20070203055124.GA26390@eris.discordians.net> On Tue, Jan 30, 2007 at 01:24:30PM -0500, Ryan Findley wrote: > My question: is there a way to have ssh and/or sshd tell you WHY a > public key is being rejected (specifically the permissions thing)? > If so, can someone point me at a good document? I'm using OpenSSH > 3.9p1 under RHEL4 (at the moment) and can upgrade if it's in a newer > version. With RHEL another area you could have run into problems is with SELinux contexts on the various files or directories. With some errors (such as those related to SSH's own paranoia) the cause might be more obvious than with others, such as EACCES. I think you find that giving good hints to the user will be difficult, and giving bad hints is more likely to send them off in the wrong direction. -matt From dan at ns15.lightwave.net.ru Sat Feb 3 06:25:23 2007 From: dan at ns15.lightwave.net.ru (Dan Yefimov) Date: Fri, 2 Feb 2007 22:25:23 +0300 (MSK) Subject: Tunnel ssh / modifie http headers In-Reply-To: <550878.69769.qm@web26512.mail.ukl.yahoo.com> Message-ID: On Fri, 2 Feb 2007, cyrilparis wrote: > Hi, > > I m using ssh to make tunnels > i would like to know if it is technically possible to modify ssh serveur to > modify http header (to put in header a new line containing IP of client using > tunnel) > Of course it's possible, but don't expect OpenSSH developers integrating such a change into OpenSSH. Cause of this is data stream modification not being the appropriate work of both SSH client and server. The appropriate place for such data stream modification would be some program or script at the head of the tunnel passing the modified data to SSH tunnel. -- Sincerely Your, Dan. From martin at oneiros.de Sun Feb 4 01:55:49 2007 From: martin at oneiros.de (=?ISO-8859-1?Q?Martin_Schr=F6der?=) Date: Sat, 3 Feb 2007 15:55:49 +0100 Subject: Verbose messaging about why public key auth was rejected In-Reply-To: <3109E259-4D89-4A8D-A218-A10A5D16CD92@neomindstudio.com> References: <3109E259-4D89-4A8D-A218-A10A5D16CD92@neomindstudio.com> Message-ID: <68c491a60702030655i259fccefx4a726417fe18fa26@mail.gmail.com> 2007/1/30, Ryan Findley : > My question: is there a way to have ssh and/or sshd tell you WHY a > public key is being rejected (specifically the permissions thing)? > If so, can someone point me at a good document? I'm using OpenSSH > 3.9p1 under RHEL4 (at the moment) and can upgrade if it's in a newer > version. I've had good results with LogLevel VERBOSE. Best Martin From djm at mindrot.org Sun Feb 4 09:22:49 2007 From: djm at mindrot.org (Damien Miller) Date: Sun, 4 Feb 2007 09:22:49 +1100 (EST) Subject: Verbose messaging about why public key auth was rejected In-Reply-To: <3109E259-4D89-4A8D-A218-A10A5D16CD92@neomindstudio.com> References: <3109E259-4D89-4A8D-A218-A10A5D16CD92@neomindstudio.com> Message-ID: On Tue, 30 Jan 2007, Ryan Findley wrote: > My question: is there a way to have ssh and/or sshd tell you WHY a > public key is being rejected (specifically the permissions thing)? > If so, can someone point me at a good document? I'm using OpenSSH > 3.9p1 under RHEL4 (at the moment) and can upgrade if it's in a newer > version. > If not, would the OpenSSH team consider adding this feature? I'm > betting I could probably manage the changes necessary, and submit a > patch... I don't think we want to tell the client exactly what is wrong wrt authorized_keys permissions. How do you know the client is not evil before you tell them that their authorized_keys is word-writable? -d From kruse at silicann.com Mon Feb 5 22:47:11 2007 From: kruse at silicann.com (Lars Kruse) Date: Mon, 5 Feb 2007 12:47:11 +0100 Subject: X forwarding: trying to forward to busy local port In-Reply-To: <20070201162824.6d5f8b77@jackdaw.neusy> References: <20070201162824.6d5f8b77@jackdaw.neusy> Message-ID: <20070205124711.1ba64d02@jackdaw.neusy> Hi to all of you, maybe my previous mail (http://permalink.gmane.org/gmane.network.openssh.devel/13345) was not clear enough, so I will try to summarize it more concisely: If I use X-Frowarding, then the ssh-daemon offers DISPLAY settings, that can not be used. Thus resulting in "cannot connect ..." errors. From my point of view, the ssh-daemon should check, if (for example) port 6014 is available before it offers the DISPLAY "localhost:4". This not-checking is especially ugly, as the ssh-daemon itself occupied the respective port during another X-Forwarding session. Result: for now there is no way for me to use X-Forwarding safely. The only thing, I can do, is to regularly check (by cron), if there is an X-Forwarding session, that occupies crucial ports (between 6000 and 6100). If this happens, then I have to ask the user to log out and start his session again. Otherwise all the other users would complain, that they cannot connect to the X-Server. How could I avoid this ugly situation? Maybe I just do not really get the point? regards, Lars From dtucker at zip.com.au Mon Feb 5 23:34:55 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 5 Feb 2007 23:34:55 +1100 Subject: X forwarding: trying to forward to busy local port In-Reply-To: <20070205124711.1ba64d02@jackdaw.neusy> References: <20070201162824.6d5f8b77@jackdaw.neusy> <20070205124711.1ba64d02@jackdaw.neusy> Message-ID: <20070205123455.GA27701@gate.dtucker.net> On Mon, Feb 05, 2007 at 12:47:11PM +0100, Lars Kruse wrote: > Hi to all of you, > > maybe my previous mail > (http://permalink.gmane.org/gmane.network.openssh.devel/13345) was not > clear enough, so I will try to summarize it more concisely: I missed the original post but just went and reviewed it. > If I use X-Frowarding, then the ssh-daemon offers DISPLAY settings, > that can not be used. Thus resulting in "cannot connect ..." errors. > > >From my point of view, the ssh-daemon should check, if (for example) > port 6014 is available before it offers the DISPLAY "localhost:4". > > This not-checking is especially ugly, as the ssh-daemon itself occupied > the respective port during another X-Forwarding session. It does check that it can bind to the port, though (see x11_create_display_inet()). I suspect the root of your problem is some funkiness with IPv6. Note that some of the listening sockets in your original post are listening on ::1 and some on 127.0.0.1. Do you have X11UseLocalhost set in sshd_config? If so, what does "localhost" resolve to? If you can afford to do so you could try running without the ipv6 stack loaded. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From kruse at silicann.com Tue Feb 6 00:38:50 2007 From: kruse at silicann.com (Lars Kruse) Date: Mon, 5 Feb 2007 14:38:50 +0100 Subject: X forwarding: trying to forward to busy local port In-Reply-To: <20070205123455.GA27701@gate.dtucker.net> References: <20070201162824.6d5f8b77@jackdaw.neusy> <20070205124711.1ba64d02@jackdaw.neusy> <20070205123455.GA27701@gate.dtucker.net> Message-ID: <20070205143850.7e0dd8c4@jackdaw.neusy> Hi, > Do you have X11UseLocalhost set in sshd_config? If so, what does > "localhost" resolve to? the setting "X11UseLocalhost" is not defined in our sshd_config - so it should be the default value "yes". jackdaw:~ # grep localhost /etc/hosts 127.0.0.1 localhost ::1 ip6-localhost ip6-loopback So "localhost" should resolve to the ipv4 address. > If you can afford to do so you could try running without the ipv6 > stack loaded. good idea! I tried it ("AddressFamily inet") successfully: now busy ports are skipped (as expected). Maybe the ipv4 port should be checked in x11_create_display_inet, too? (if "AddressFamily" is "any") As I do not speak "C" fluently, I am unable to suggest something - sorry ... thanks a lot for your suggestion! regards, Lars From rapier at psc.edu Tue Feb 6 02:37:41 2007 From: rapier at psc.edu (Chris Rapier) Date: Mon, 05 Feb 2007 10:37:41 -0500 Subject: Open SSH : SFTP Query In-Reply-To: <20070203004940.6499.qmail@cdy.org> References: <1135d14b0702020017j2c6a8d61uec208027c8843906@mail.gmail.com> <20070203004940.6499.qmail@cdy.org> Message-ID: <45C74F45.3040108@psc.edu> Peter Stuge wrote: > Hello Deepak, > > On Fri, Feb 02, 2007 at 05:17:05PM +0900, Deepak D wrote: >> I want a simple sftp library which I can link to my test >> application and perform ftp operations. Is it possible to seperate >> sftp out of ssh and form a sftp library ? > > It is certainly possible, but.. But as it has been pointed out OpenSSH really is an application and not a library. A coworker and I did turn it in to a library at one point but it was a mess and we abandoned it pretty quickly. However, there are *other* ssh implementations out there that may be able to do what you need. libssh is one, I'm not sure if its ready for production yet but as a basis for further development it may be worth exploring. http://0xbadc0de.be/wiki/doku.php?id=libssh:libssh Please note, this library has nothing to do with OpenSSH and it doesn't seem to provide listen capability. From openssh-unix-dev at topisoft.fi Tue Feb 6 02:47:19 2007 From: openssh-unix-dev at topisoft.fi (Topi Rinkinen) Date: Mon, 05 Feb 2007 17:47:19 +0200 Subject: tunneling support for PF_UNIX sockets Message-ID: <1170690439.7008.23.camel@topisoft.dyndns.org> Hi, I've been planning to develop a support for tunneling between "local_tcp => server_AF_UNIX". This way, every user of server machine, can have: 1. personal address space (if socket is located on personal directory). Currently one must check assigned local port every time starting a server (e.g. vncserver), and redirect a local port to "random" remote port. 2. Added security. If server application in remote machine supports AF_UNIX sockets, socket can be made accissible to the user only (by locating it to 700 directory). Questions: 3. Is there a way to achieve same goals with current ssh version? 4. Is there a reason not to do this? 5. Is there a already available naming convention to support different address families? Quick_n_dirty way would be prefixing host_address with some predefined "illegal" character (e.g. '#'), to signal the AF_UNIX address. But I see that general, expandable naming convention would give more. One could e.g. define an address space of "AF_EXEC", which would execute program on remote host every time new tunnel is initiated. I was thinking something like: "AF_UNIX::/home/user/dir/sock_file" for UNIX sockets (ssh -newflag 8080:AF_UNIX::/home/user/dir/sock_file hostname.com) "AF_INET::localhost:80" for tcp redirection, this should be default, if no AF_* is specified. "AF_EXEC::/home/user/server_executable -p param" for executable redirection. 6. Local port support for new address families can gain some new usage. Any ideas for this? Any further ideas ? -- Topi From william at 25thandClement.com Tue Feb 6 08:00:44 2007 From: william at 25thandClement.com (William Ahern) Date: Mon, 5 Feb 2007 13:00:44 -0800 Subject: tunneling support for PF_UNIX sockets In-Reply-To: <1170690439.7008.23.camel@topisoft.dyndns.org> References: <1170690439.7008.23.camel@topisoft.dyndns.org> Message-ID: <20070205210044.GB14359@wilbur.25thandClement.com> On Mon, Feb 05, 2007 at 05:47:19PM +0200, Topi Rinkinen wrote: > Hi, > > I've been planning to develop a support for tunneling between "local_tcp > => server_AF_UNIX". http://www.25thandclement.com/~william/projects/streamlocal.html > Questions: > > 3. Is there a way to achieve same goals with current ssh version? No. And extensive patching to OpenSSH is required for AF_UNIX because the codebase assumes AF_INET or AF_INET6 at every single point, and it assumes in such a way that precludes easy integration of AF_UNIX. > 4. Is there a reason not to do this? 1) It took a ton of work. 2) So much work the OpenSSH folks haven't even cared to look into it my patch, let alone hold out the chance for integration into the trunk. > 5. Is there a already available naming convention to support different > address families? No. I used a square brace ('[') convention, and re-wrote the option parser for addresses. > Quick_n_dirty way would be prefixing host_address with some predefined Nope. The addresses are sent across the wire in a fixed format which precludes use of the relatively free-form AF_UNIX paths. - Bill From james.davis at lmco.com Tue Feb 6 05:51:04 2007 From: james.davis at lmco.com (Davis, James (N-TEK Systems)) Date: Mon, 05 Feb 2007 13:51:04 -0500 Subject: OpenSSH 4.5p1problem with LynxOS v3. Message-ID: <7F14F1DB7329674E8AA0D101A07421D70F914A@emss04m03.us.lmco.com> Hello everyone, Thank you for producing the portable version of OpenSSH. I have a small problem that I hope someone on here has perhaps seen before. I am running OpenSSH 4.5p1 under a PowerPC build of LynxOS v3. Everything builds and runs except there is a strange behavior that occurs in a particular situation. If you SSH to the system and then exit by typing "logout" then it works as expected. However, if you type "exit" then you see that logout is being called but you are never returned to your original prompt on the source system. The child SSHD that is forked to service the client does not exit when you exit via "exit" but it does when you exit via "logout" or simply closing the terminal. The problem seems to be in the server loop. When you reproduce the problem the forked SSHD sits in wait_until_can_do_something() and does not exit. Any help would be appreciated, Thank you. James Davis Lockheed Martin. From dtucker at zip.com.au Thu Feb 8 14:18:37 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 08 Feb 2007 14:18:37 +1100 Subject: X forwarding: trying to forward to busy local port In-Reply-To: <20070205143850.7e0dd8c4@jackdaw.neusy> References: <20070201162824.6d5f8b77@jackdaw.neusy> <20070205124711.1ba64d02@jackdaw.neusy> <20070205123455.GA27701@gate.dtucker.net> <20070205143850.7e0dd8c4@jackdaw.neusy> Message-ID: <45CA968D.1000500@zip.com.au> Lars Kruse wrote: > Hi, > >> Do you have X11UseLocalhost set in sshd_config? If so, what does >> "localhost" resolve to? > the setting "X11UseLocalhost" is not defined in our sshd_config - so it > should be the default value "yes". > > jackdaw:~ # grep localhost /etc/hosts > 127.0.0.1 localhost > ::1 ip6-localhost ip6-loopback > > So "localhost" should resolve to the ipv4 address. Not necessarily: if nsswitch.conf goes to DNS first you might resolve "localhost" to an AAAA record for ::1 (or alternate between IP4 and IP6, which might explain what you're seeing). >> If you can afford to do so you could try running without the ipv6 >> stack loaded. > good idea! > I tried it ("AddressFamily inet") successfully: now busy ports are > skipped (as expected). > > > Maybe the ipv4 port should be checked in x11_create_display_inet, too? > (if "AddressFamily" is "any") I don't think that should be necessary: the system should return the sockets of the same AF when asked for the same thing (but glancing briefly at the code, sshd just passes a NULL address to getaddrinfo, so unless libc does a lookup for "localhost" I'm not sure what's really going on here.) -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From enrique.moliner at aragon.catastro.meh.es Thu Feb 8 18:23:59 2007 From: enrique.moliner at aragon.catastro.meh.es (enrique moliner) Date: Thu, 8 Feb 2007 08:23:59 +0100 Subject: priotc text hp-ux renicer program (version 1.5a) Message-ID: <008001c74b52$1a05aed0$b9d5390a@zaragoza.catastro.minhac.es> PRIOTC Author: Enrique Moliner Martinez, from Zaragoza (Spain) version 1.5a (1/2/2007) with FREE_ENDUSER license Bugs fixed and changes. Soon version 1.6 also with patterns for cmd parameters. Automatic HP-UX pid renicer and serializer For use in HP-9000 (others?) unix systems with 'HP-UX' B.10.20 or higher This is an 'automatic renicer' program: Get variable CPU time to pids depending on defined nice-value and names or patterns in configuration file, by once renice if matching: -At startup, priotc renice all pids to defined nice. .When priotc is already running, watch ONLY for renice NEW pids or equal pid if a change in command-name or program-name is detected (like occurs in an exec command). Then, at any time, any nice value or serialize is valid by manually 'renicer', 'serialize' user commands and the hp-ux restrictions. This is also an 'automatic serializer program: Serialize a pid with nice >= that defined in configuration file if actually low free pages in the system. -For system performance, all serialized pids run together in a sequential no timeshare cpu use, only if hp-ux detect low free pages. If enough pages, serialized pids run also timeshare. Priotc serialize pids with high nice value (run slow) >=that defined nice for serialize in the configuration file. ---------------------------------------------------------------------------- ------------ This FREE ENDUSER license: -Is free unloaded with the source program -This program (source/executable) can be distributed ONLY in original form and ever completely free. .This program only can be modified for internal use, and in this case can not be distributed. The modified program ever must show the program author name (initial credits). -The documentation can be modified and distributed, ever free and with the reference of the program author name. FILES priotc.c source code rutinas.h include file priotc.cfg.example configuration file example priotc.comp for compiling priotc priotc.doc documentation file priotcv.log log example priotc.ver versions (read before installing) Download if you accept free_enduser license: Backup your old version before load this version. priotc15a.zip Report bugs to cmolimar at hotmail.com ********************************************************************************************** PAntes de imprimir este e-mail piense bien si es necesario hacerlo: El medioambiente es cosa de todos Before printing this email, assess if it is really needed. ********************* Aviso Legal ********************* Este mensaje y cualquier fichero adjunto est? dirigido ?nicamente a sus destinatarios y contiene informaci?n confidencial. Si usted considera que ha recibido este correo electr?nico por error (por el asunto, por el remitente o por cualquier otra causa), le informamos que cualquier revisi?n, alteraci?n, impresi?n, copia o transmisi?n de este mensaje o de cualquier fichero adjunto est? prohibida y puede constituir un acto ilegal. Por favor, notif?quele el error al remitente respondiendo a este e-mail y elimine el mensaje y su contenido inmediatamente. El Ministerio de Econom?a y Hacienda se reserva las acciones legales que le correspondan contra todo tercero que acceda de forma ileg?tima al contenido de cualquier mensaje externo procedente del mismo. ********************* Disclaimer ********************* This e-mail and any files transmitted with it are intended solely for the use of the intended recipients and may contain confidential information. If it appears (from the subject matter or address information or otherwise) that you received this email in error, please note that any review, dissemination, disclosure, alteration, printing, copying or transmission of this e-mail or any file transmitted with it is prohibited and may be unlawful. Please notify us by return email and delete this email and its contents immediately. Spanish Ministry of Finances may take any legal action, according with the illegal access to the content of any external message from the Ministry. ********************************************************************************************** From kruse at silicann.com Thu Feb 8 21:59:48 2007 From: kruse at silicann.com (Lars Kruse) Date: Thu, 8 Feb 2007 11:59:48 +0100 Subject: X forwarding: trying to forward to busy local port In-Reply-To: <45CA968D.1000500@zip.com.au> References: <20070201162824.6d5f8b77@jackdaw.neusy> <20070205124711.1ba64d02@jackdaw.neusy> <20070205123455.GA27701@gate.dtucker.net> <20070205143850.7e0dd8c4@jackdaw.neusy> <45CA968D.1000500@zip.com.au> Message-ID: <20070208115948.568584ba@jackdaw.neusy> Hi, thanks for your time (and your replies), Darren! > >> Do you have X11UseLocalhost set in sshd_config? If so, what does > >> "localhost" resolve to? > > the setting "X11UseLocalhost" is not defined in our sshd_config - so it > > should be the default value "yes". > > > > jackdaw:~ # grep localhost /etc/hosts > > 127.0.0.1 localhost > > ::1 ip6-localhost ip6-loopback > > > > So "localhost" should resolve to the ipv4 address. > > Not necessarily: if nsswitch.conf goes to DNS first you might resolve > "localhost" to an AAAA record for ::1 (or alternate between IP4 and IP6, > which might explain what you're seeing). ok - you want all the details :) localhost resolves to 127.0.0.1: jackdaw:~ # getent hosts localhost 127.0.0.1 localhost content of nsswitch.conf: jackdaw:~ # grep "^[^#]" /etc/nsswitch.conf | grep -v "^$" passwd: compat group: compat hosts: files dns networks: files dns services: files protocols: files rpc: files ethers: files netmasks: files netgroup: files publickey: files bootparams: files automount: files nis aliases: files > > Maybe the ipv4 port should be checked in x11_create_display_inet, too? > > (if "AddressFamily" is "any") > > I don't think that should be necessary: the system should return the > sockets of the same AF when asked for the same thing (but glancing > briefly at the code, sshd just passes a NULL address to getaddrinfo, so > unless libc does a lookup for "localhost" I'm not sure what's really > going on here.) I am not too familiar with networking on this level ... But somehow the output of the following commands looks like as if the AF is not used consistently for X-forwarded connections. incoming ssh connections with opened X-Forwarding listening ports for both ipv4 and ipv6: jackdaw:~ # netstat -lpn | grep :60[0-9][0-9] tcp 0 0 127.0.0.1:6016 0.0.0.0:* LISTEN 4336/sshd: lars at not tcp 0 0 127.0.0.1:6010 0.0.0.0:* LISTEN 14734/sshd:steffen tcp 0 0 127.0.0.1:6013 0.0.0.0:* LISTEN 2390/sshd: jens at not tcp 0 0 127.0.0.1:6014 0.0.0.0:* LISTEN 2652/sshd: michael@ tcp 0 0 127.0.0.1:6015 0.0.0.0:* LISTEN 3341/sshd: axel at not tcp 0 0 ::1:6016 :::* LISTEN 4336/sshd: lars at not tcp 0 0 ::1:6010 :::* LISTEN 14734/sshd: steffen tcp 0 0 ::1:6013 :::* LISTEN 2390/sshd: jens at not tcp 0 0 ::1:6014 :::* LISTEN 2652/sshd: michael@ tcp 0 0 ::1:6015 :::* LISTEN 3341/sshd: axel at not clients connected to the displays via their ipv4 ports: jackdaw:~ # netstat -pn | grep :60[0-9][0-9] tcp 0 0 127.0.0.1:6013 127.0.0.1:29975 ESTABLISHED 2390/sshd: jens at not tcp 0 0 127.0.0.1:6014 127.0.0.1:2068 ESTABLISHED 2652/sshd: michael@ tcp 0 0 127.0.0.1:29975 127.0.0.1:6013 ESTABLISHED 2978/firefox-bin tcp 0 0 127.0.0.1:6016 127.0.0.1:26911 ESTABLISHED 4336/sshd: lars at not tcp 0 0 127.0.0.1:6016 127.0.0.1:26910 ESTABLISHED 4336/sshd: lars at not tcp 0 0 127.0.0.1:29220 127.0.0.1:6013 ESTABLISHED 5075/sunbird-bin tcp 0 0 127.0.0.1:6016 127.0.0.1:26887 ESTABLISHED 4336/sshd: lars at not tcp 0 0 127.0.0.1:28349 127.0.0.1:6015 ESTABLISHED 3589/kwalletmanager tcp 0 0 127.0.0.1:6016 127.0.0.1:26885 ESTABLISHED 4336/sshd: lars at not tcp 0 0 127.0.0.1:27147 127.0.0.1:6015 ESTABLISHED 3627/opera [many more lines - only ipv4 ports] As I wrote in the first mail of this thread: if the ipv4 port is already used by another process then the clients only try to connect to the ipv4 port (and fail) - they never use the (existing and working) ipv6 port. (sorry, if I am mixing up "ports" and "sockets") I do not really know, how ssh should behave. But the current state of the ipv4/ipv6 implementation seems to be very likely to suffer pseudo-random connection failures for X-forwarded sessions. This feels like a very ugly situation for me. Or do I misunderstand something? thanks for your time, Lars From svallet at genoscope.cns.fr Thu Feb 8 21:21:31 2007 From: svallet at genoscope.cns.fr (Simon Vallet) Date: Thu, 8 Feb 2007 11:21:31 +0100 Subject: "Out of memory" error looking up SSHFP records Message-ID: <20070208112131.1a858b91.svallet@genoscope.cns.fr> Hi, we're currently considering making use of RFC4255 SSHFP records, but are hitting a problem with a 4.4p1 client running on Tru64 5.1A: [...] debug3: verify_host_key_dns DNS lookup error: out of memory [...] No matching host key fingerprint found in DNS. A 4.3p2 linux client gives the following : [...] debug3: verify_host_key_dns debug1: found 1 insecure fingerprints in DNS debug1: matching host key fingerprint found in DNS [...] Matching host key fingerprint found in DNS. Any idea on the cause of the "out of memory error" ? Simon -- Simon Vallet Ing?nieur Syst?mes/R?seaux Genoscope / CNRG T?l. : 01 60 87 36 06 E-mail : svallet at genoscope.cns.fr From dtucker at zip.com.au Fri Feb 9 13:40:34 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 09 Feb 2007 13:40:34 +1100 Subject: "Out of memory" error looking up SSHFP records In-Reply-To: <20070208112131.1a858b91.svallet@genoscope.cns.fr> References: <20070208112131.1a858b91.svallet@genoscope.cns.fr> Message-ID: <45CBDF22.4000609@zip.com.au> Simon Vallet wrote: > we're currently considering making use of RFC4255 SSHFP records, > but are hitting a problem with a 4.4p1 client running on Tru64 5.1A: > > [...] > debug3: verify_host_key_dns > DNS lookup error: out of memory > [...] > No matching host key fingerprint found in DNS. > > A 4.3p2 linux client gives the following : > [...] > debug3: verify_host_key_dns > debug1: found 1 insecure fingerprints in DNS > debug1: matching host key fingerprint found in DNS > [...] > Matching host key fingerprint found in DNS. > > Any idea on the cause of the "out of memory error" ? A brief look at the code shows that error as occurring when getrrsetbyname fails. Does Tru64 have its own or is it using the one in openbsd-compat? (grep GETRRSET config.h) Also, are ERRSET_SUCCESS and/or ERRSET_NOMEMORY defined in the system headers? -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From downtime at slagheap.net Fri Feb 9 06:17:24 2007 From: downtime at slagheap.net (downtime at slagheap.net) Date: Thu, 8 Feb 2007 11:17:24 -0800 Subject: bug(?) with OpenSSH 4.4+ and large DSA ID keys Message-ID: <97E17E29-15F4-4E17-B0EA-21E7A419CF84@slagheap.net> Please pardon me if this is the wrong place, or operator error/ retardation is involved. Any help is sincerely appreciated. fatal: mm_request_receive_expect: read: rtype 12 != type 24 For some reason, three (two OpenBSD/i386 and one OpenBSD/sparc64) of my four identically-configured SSH daemons cough up the above error when I try to authenticate using a big (4096-bit) DSA key from the same OpenSSH 4.2 client. Note that I said three out of four - strangely one works, and this would ordinarily make me suspect my own incompetence, but I haven't done anything funny and all of them have default, vanilla configuration files. One of them (i386), for some unbeknownst reason, works just fine. This was working just fine before I changed to a 4096 bit key. Upgrading the server to OpenSSH 4.5 allows for fallback to password authentication to work; upgrading the client produces no change whatsoever. Other OpenSSH 4.2 and 4.3 servers I have seem not to be affected. Going back to a 2048-bit DSA key fixes it. Shell transcript follows, including debug output. The key parsing errors are especially weird, but these seem to happen with the working client and a 2048-bit DSA key, too. aurora65% ssh northstar Connection closed by 192.168.99.2 aurora66% ssh root at northstar root at northstar's password: Last login: Thu Nov 2 00:31:48 2006 OpenBSD 4.0 (GENERIC) #2: Tue Jan 16 12:33:34 PST 2007 /usr/X11R6/bin/xauth: creating new authority file /root/.Xauthority Terminal type? [xterm] # tail /var/log/authlog Feb 6 03:00:01 northstar newsyslog[18751]: logfile turned over Feb 7 14:54:26 northstar sshd[30539]: fatal: mm_request_receive_expect: read: rtype 12 != type 24 Feb 7 15:22:49 northstar sshd[10863]: fatal: mm_request_receive_expect: read: rtype 12 != type 24 Feb 7 16:34:03 northstar sshd[21238]: fatal: mm_request_receive_expect: read: rtype 12 != type 24 Feb 7 16:34:12 northstar sshd[24866]: Accepted password for root from 192.168.69.34 port 49715 ssh2 # exit aurora69% ssh -vvv northstar OpenSSH_4.2p1, OpenSSL 0.9.7l 28 Sep 2006 debug1: Reading configuration data /etc/ssh_config debug2: ssh_connect: needpriv 0 debug1: Connecting to northstar [192.168.99.2] port 22. debug1: Connection established. debug1: identity file /Users/peter/.ssh/identity type 0 debug3: Not a RSA1 key file /Users/peter/.ssh/id_rsa. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: missing keytype debug2: key_type_from_name: unknown key type 'Proc-Type:' debug3: key_read: missing keytype debug2: key_type_from_name: unknown key type 'DEK-Info:' debug3: key_read: missing keytype debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: missing keytype debug1: identity file /Users/peter/.ssh/id_rsa type 1 debug3: Not a RSA1 key file /Users/peter/.ssh/id_dsa. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: missing keytype debug2: key_type_from_name: unknown key type 'Proc-Type:' debug3: key_read: missing keytype debug2: key_type_from_name: unknown key type 'DEK-Info:' debug3: key_read: missing keytype debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: missing keytype debug1: identity file /Users/peter/.ssh/id_dsa type 2 debug1: Remote protocol version 1.99, remote software version OpenSSH_4.4 debug1: match: OpenSSH_4.4 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.2 debug2: fd 3 setting O_NONBLOCK debug1: An invalid name was supplied Configuration file does not specify default realm debug1: An invalid name was supplied A parameter was malformed Validation error debug1: An invalid name was supplied Configuration file does not specify default realm debug1: An invalid name was supplied A parameter was malformed Validation error debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie- hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128- cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael- cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128- cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael- cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac- ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac- ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange- sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14- sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128- cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael- cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128- cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael- cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac- ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac- ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib at openssh.com debug2: kex_parse_kexinit: none,zlib at openssh.com debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_init: found hmac-md5 debug1: kex: server->client aes128-cbc hmac-md5 none debug2: mac_init: found hmac-md5 debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug2: dh_gen_key: priv key bits set: 121/256 debug2: bits set: 502/1024 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: check_host_in_hostfile: filename /Users/peter/.ssh/known_hosts debug3: check_host_in_hostfile: match line 148 debug3: check_host_in_hostfile: filename /Users/peter/.ssh/known_hosts debug3: check_host_in_hostfile: match line 148 debug1: Host 'northstar' is known and matches the RSA host key. debug1: Found key in /Users/peter/.ssh/known_hosts:148 debug2: bits set: 511/1024 debug1: ssh_rsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /Users/peter/.ssh/id_rsa (0x307930) debug2: key: /Users/peter/.ssh/id_dsa (0x3078a0) debug1: Authentications that can continue: publickey,password,keyboard-interactive debug3: start over, passed a different list publickey,password,keyboard-interactive debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard- interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Offering public key: /Users/peter/.ssh/id_rsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,password,keyboard-interactive debug1: Offering public key: /Users/peter/.ssh/id_dsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Server accepts key: pkalg ssh-dss blen 1587 debug2: input_userauth_pk_ok: fp blah:blah:blah debug3: sign_and_send_pubkey debug1: Authentications that can continue: publickey,password,keyboard-interactive debug2: we did not send a packet, disable method debug3: authmethod_lookup keyboard-interactive debug3: remaining preferred: password debug3: authmethod_is_enabled keyboard-interactive debug1: Next authentication method: keyboard-interactive debug2: userauth_kbdint debug2: we sent a keyboard-interactive packet, wait for reply Connection closed by 192.168.99.2 From dtucker at zip.com.au Fri Feb 9 14:19:25 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 09 Feb 2007 14:19:25 +1100 Subject: bug(?) with OpenSSH 4.4+ and large DSA ID keys In-Reply-To: <97E17E29-15F4-4E17-B0EA-21E7A419CF84@slagheap.net> References: <97E17E29-15F4-4E17-B0EA-21E7A419CF84@slagheap.net> Message-ID: <45CBE83D.6010906@zip.com.au> downtime at slagheap.net wrote: > Please pardon me if this is the wrong place, or operator error/ > retardation is involved. Any help is sincerely appreciated. > > fatal: mm_request_receive_expect: read: rtype 12 != type 24 That's a symptom of the bug fixed just before the release of OpenSSH 4.5 (where the monitor and slave get out of sync). I suggest that you upgrade the (other) servers. The reason for the different behaviour on some hosts is that it's dependent on the OpenSSL library version (newer versions will refuse to process DSA keys > ~3k). This means that your big keys still won't work, but the server won't kill the connections either. Big DSA keys don't really make sense for SSH so if you want big keys I suggest you use RSA. The "unknown key type" client debug messages are normal. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From Varaprasad_Kota at Dell.com Thu Feb 8 22:08:02 2007 From: Varaprasad_Kota at Dell.com (Varaprasad_Kota at Dell.com) Date: Thu, 8 Feb 2007 16:38:02 +0530 Subject: Authentication Message-ID: Hi, We are sending documents from webMethods using SSH.When the certificates are enabled it is authenticating only the user name but not the valid password which was an expected behaviour. After disabling the certificates even then the SFTP server is allowing the user with with an invalid password.Can any please tell me what need to be done on this to authenticate both user name and password when the certificates are disabled...?.When I use any sftp client and try to login then its not allowing n saying invalid password.But its allowing when we are posting a document via webmethods. Best Regards, Varaprasad Kota. From svallet at genoscope.cns.fr Fri Feb 9 21:03:49 2007 From: svallet at genoscope.cns.fr (Simon Vallet) Date: Fri, 9 Feb 2007 11:03:49 +0100 Subject: "Out of memory" error looking up SSHFP records In-Reply-To: <45CBDF22.4000609@zip.com.au> References: <20070208112131.1a858b91.svallet@genoscope.cns.fr> <45CBDF22.4000609@zip.com.au> Message-ID: <20070209110349.15bb9492@tx174.tx.local> On Fri, 09 Feb 2007 13:40:34 +1100 Darren Tucker wrote: > A brief look at the code shows that error as occurring when > getrrsetbyname fails. Does Tru64 have its own or is it using the one in > openbsd-compat? (grep GETRRSET config.h) It seems it is using the bundled one: $ grep GETRRSET config.h /* #undef HAVE_GETRRSETBYNAME */ $ > Also, are ERRSET_SUCCESS and/or ERRSET_NOMEMORY defined in the system > headers? It doesn't seem so. Both the query and reply can be seen on the wire ; tracing the client doesn't reveal much more info : it fails after a successful recvfrom (the call to res_query() i guess). So it seems an alloc is failing somewhere... I'll try to confirm this and get back to you. Simon From svallet at genoscope.cns.fr Fri Feb 9 22:10:27 2007 From: svallet at genoscope.cns.fr (Simon Vallet) Date: Fri, 9 Feb 2007 12:10:27 +0100 Subject: "Out of memory" error looking up SSHFP records In-Reply-To: <20070209110349.15bb9492@tx174.tx.local> References: <20070208112131.1a858b91.svallet@genoscope.cns.fr> <45CBDF22.4000609@zip.com.au> <20070209110349.15bb9492@tx174.tx.local> Message-ID: <20070209121027.440e61e6@tx174.tx.local> On Fri, 9 Feb 2007 11:03:49 +0100 Simon Vallet wrote: > So it seems an alloc is failing somewhere... I'll try to confirm this > and get back to you. Yup -- the following returns a null pointer due to rrset->rri_nsigs being 0 : rrset->rri_sigs = calloc(rrset->rri_nsigs, sizeof(struct rdatainfo)); This is what POSIX has to say on the subject: "If the size of the space requested is 0, the behavior is implementation-defined: the value returned shall be either a null pointer or a unique pointer." I don't know how other OSes implement it, but checking for the presence of SIG records somewhere might be good idea. Simon From kri_murari at yahoo.com Sat Feb 10 01:37:38 2007 From: kri_murari at yahoo.com (murari krishnamurthy) Date: Fri, 9 Feb 2007 06:37:38 -0800 (PST) Subject: Package Message-ID: <33335.48806.qm@web33103.mail.mud.yahoo.com> Do you guys know is there any package specific to sftp a free api (source developed in c ) and which can be deployed in uniz/linux regards Murari Regards Murari.P.K ____________________________________________________________________________________ No need to miss a message. Get email on-the-go with Yahoo! Mail for Mobile. Get started. http://mobile.yahoo.com/mail From anandhsrini at gmail.com Tue Feb 13 04:44:10 2007 From: anandhsrini at gmail.com (Anand Srinivasan) Date: Mon, 12 Feb 2007 12:44:10 -0500 Subject: X11 forwarding over SSH - yet another loop-hole ? Message-ID: Hi, I'm not sure if this is the right place to post this but I recently noticed something strange with X11 forwarding over SSH. I was running X11 on my Mac (OS X Server 10.4.8) and had two separate SSH sessions open to two different Linux boxes (I used the -Y flag). I started Firefox on the first box and then subsequently started Firefox on the second box. But instead of starting a new process on the second box a new process was spawned on the first box - I ran top to verify this and there was no Firefox process running on the second box, while there were two on the first ! I tried this a bunch of times and still the same thing happened. I believe this is a security loop-hole in the X11 forwarding over SSH. I've also tested this on a Windows box using putty and Xming(or any other X windows client) and still the same result. I would like to know if this problem has been addressed before and if so what is the solution to this. I have also tried connecting to the Linux boxes using the SSH -X flag and still the same result. Does this mean that -X is not really that secure when compared to -Y ? If this not the right place to post this do let me know and I'll send this question else where. Thanks, Anand From djm at mindrot.org Tue Feb 13 06:46:01 2007 From: djm at mindrot.org (Damien Miller) Date: Tue, 13 Feb 2007 06:46:01 +1100 (EST) Subject: X11 forwarding over SSH - yet another loop-hole ? In-Reply-To: References: Message-ID: On Mon, 12 Feb 2007, Anand Srinivasan wrote: > Hi, > > I'm not sure if this is the right place to post this but I recently > noticed something strange with X11 forwarding over SSH. I was running > X11 on my Mac (OS X Server 10.4.8) and had two separate SSH sessions > open to two different Linux boxes (I used the -Y flag). I started > Firefox on the first box and then subsequently started Firefox on the > second box. But instead of starting a new process on the second box a > new process was spawned on the first box - I ran top to verify this > and there was no Firefox process running on the second box, while > there were two on the first ! I tried this a bunch of times and still > the same thing happened. I believe this is a security loop-hole in the > X11 forwarding over SSH. I've also tested this on a Windows box using > putty and Xming(or any other X windows client) and still the same > result. I would like to know if this problem has been addressed before > and if so what is the solution to this. I have also tried connecting > to the Linux boxes using the SSH -X flag and still the same result. > Does this mean that -X is not really that secure when compared to -Y ? Firefox does some funky X11 messaging to maintain one Firefox client per X11 server. I.e. it will message a running client to open a new window rather than starting a new client. Since this messaging happens via X11, I don't think it matters whether or not the attempt to start the second Firefox happens on the same machine. I'm not seeing the loophole here... -d From kruse at silicann.com Tue Feb 13 21:49:12 2007 From: kruse at silicann.com (Lars Kruse) Date: Tue, 13 Feb 2007 11:49:12 +0100 Subject: X forwarding: trying to forward to busy local port In-Reply-To: <20070201162824.6d5f8b77@jackdaw.neusy> References: <20070201162824.6d5f8b77@jackdaw.neusy> Message-ID: <20070213114912.5d3a76a4@jackdaw.neusy> Hi to all of you, I would like to summarize the current state of the problem as described in http://permalink.gmane.org/gmane.network.openssh.devel/13345. If the openssh server is running in ipv4/ipv6 mode ("AddressFamily Any"), then pseudo-random "unable-to-connect-to-display" errors occour for clients connecting via ssh for X-forwarded remote sessions. For now the only workaround would be, to disable ipv6 support for openssh daemons used for X-forwarding. From my point of view, there are two ways to solve the root of this problem: 1) improved "is this port usable on all interfaces?"-detection ipv4/ipv6 mixed openssh daemons should behave like pure ipv4 daemons: unusable DISPLAY settings may never be offered to clients 2) avoid to randomly allocate critical ports the openssh daemon may never allocate ports for running X-sessions which are in the range, that is used for new X-forwarding connections (maybe 6000..6100). From my point of view, this issue is a highly irritating one, as it is very hard to track down the source of this seemingly random "unable-to-connect-to-display" problem. If the previously described short-term-workaround would not be available, then our current X-session-setup would have to be replaced by a more reliable, but less preferable solution. So I am very glad, that you helped me to find this workaround ... But how can this issue be solved without loosing ipv6 compatibility? thanks and regards, Lars From dtucker at zip.com.au Tue Feb 13 22:35:32 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 13 Feb 2007 22:35:32 +1100 Subject: X forwarding: trying to forward to busy local port In-Reply-To: <20070213114912.5d3a76a4@jackdaw.neusy> References: <20070201162824.6d5f8b77@jackdaw.neusy> <20070213114912.5d3a76a4@jackdaw.neusy> Message-ID: <20070213113532.GA31234@gate.dtucker.net> On Tue, Feb 13, 2007 at 11:49:12AM +0100, Lars Kruse wrote: > Hi to all of you, > > I would like to summarize the current state of the problem as described > in http://permalink.gmane.org/gmane.network.openssh.devel/13345. > > If the openssh server is running in ipv4/ipv6 mode ("AddressFamily > Any"), then pseudo-random "unable-to-connect-to-display" errors occour > for clients connecting via ssh for X-forwarded remote sessions. > > For now the only workaround would be, to disable ipv6 support for > openssh daemons used for X-forwarding. > > >From my point of view, there are two ways to solve the root of this > problem: > > 1) improved "is this port usable on all interfaces?"-detection > ipv4/ipv6 mixed openssh daemons should behave like pure ipv4 daemons: > unusable DISPLAY settings may never be offered to clients I think it's a Linuxism: IPv6 sockets prevent binding to IPv4 sockets on the same port but not vice versa. > 2) avoid to randomly allocate critical ports > the openssh daemon may never allocate ports for running X-sessions which > are in the range, that is used for new X-forwarding connections (maybe > 6000..6100). "X11DisplayOffset 100" in sshd_config? > >From my point of view, this issue is a highly irritating one, as it is > very hard to track down the source of this seemingly random > "unable-to-connect-to-display" problem. If the previously described > short-term-workaround would not be available, then our current > X-session-setup would have to be replaced by a more reliable, but less > preferable solution. > So I am very glad, that you helped me to find this workaround ... > > But how can this issue be solved without loosing ipv6 compatibility? The IP6-only (or IP4 only, I forget) sockets, were they sshd or something else? ie the X forwards in sshd that worked were IPv4 sockets, right? -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From sethi.varun at gmail.com Tue Feb 13 23:01:40 2007 From: sethi.varun at gmail.com (Varun Sethi) Date: Tue, 13 Feb 2007 17:31:40 +0530 Subject: Question regarding X11 forwarding implementation Message-ID: <241b46e60702130401l6c84ee10occ89152b38eff527@mail.gmail.com> Hi, I am using openssh 4.1 on AIX. I have noticed a strange behaviour with openssh X11 forwarding with respect to connection termination. The behaviour is seen during connection termination between the pseudo X11 socket (say 6010) opened by sshd on server which interacts with the X11 client application socket. I have compared the behaviour of two X11 applications 1. xterm 2. wish (tcl/tk application) Let's start with xterm. Now when xterm appication wants to terminate the connection, it starts with sending "Fin" to the pseudo X11 socket. Now although this Fin get's ack'd but I don't think that the sshd polls this socket for the eof (end of conection request from the X11 client application). Even after receiving a Fin and ack'ing it, it sends data with ack to the X11 application socket which is expecting a Fin. On receiving this ack, it responds by sending a RST, thus ending the connection. Now in case of the wish application, the application sends a Fin to the pseudo scoket. The pseudo socket ack's it but then there is response at all from the pseudo socket . Thus the sshd socket remains in the close_wait condition and the X11 application socket remains in fin_wait_2 state for ever. As a result when we try to end the ssh session, it hangs in the end waiting for the X11 connection to terminate. So am I looking at some sort of a bug in the wish applicaton or the ssh x11 forwarding needs to be modified to handle this situation. I would appreciate if some one can respond to my mail Regards From kruse at silicann.com Wed Feb 14 21:43:22 2007 From: kruse at silicann.com (Lars Kruse) Date: Wed, 14 Feb 2007 11:43:22 +0100 Subject: X forwarding: trying to forward to busy local port In-Reply-To: <20070213113532.GA31234@gate.dtucker.net> References: <20070201162824.6d5f8b77@jackdaw.neusy> <20070213114912.5d3a76a4@jackdaw.neusy> <20070213113532.GA31234@gate.dtucker.net> Message-ID: <20070214114322.32877003@jackdaw.neusy> Hi, > > 1) improved "is this port usable on all interfaces?"-detection > > ipv4/ipv6 mixed openssh daemons should behave like pure ipv4 daemons: > > unusable DISPLAY settings may never be offered to clients > > I think it's a Linuxism: IPv6 sockets prevent binding to IPv4 sockets > on the same port but not vice versa. hm - I do not know any details regarding this behaviour ... To make sure, that you understand me right, I was studying the source code of "x11_create_display_inet" in "channel.c" again. If I am not mistaken, then the loop for (ai = aitop; ai; ai = ai->ai_next) tries to connect to all available ports according to the given restrictions (especially: address family). If at least one port is usable, then this one is used for the X session. Case 1: both ipv4 and ipv6 socket of a given port are available no problem - both sockets are bound for the X session. Case 2: only the ipv4 socket of the port is available no problem - as the display "localhost:???" (ipv4 address) is returned, clients will only connect to the ipv4 port, anyway. Case 3: only the ipv6 socket of the port is available this seems to be a problem: an ipv6 port is bound, but an ipv4 address is returned as the display setting (DISPLAY=localhost:??? instead of DISPLAY=ip6-localhost:???). Could it be, that the return value of the DISPLAY setting does not depend on the acquired sockets for now? (always returning an ip4 address) Or did I misunderstand something? regards, Lars From dtucker at zip.com.au Wed Feb 14 23:18:58 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 14 Feb 2007 23:18:58 +1100 Subject: X forwarding: trying to forward to busy local port In-Reply-To: <20070214114322.32877003@jackdaw.neusy> References: <20070201162824.6d5f8b77@jackdaw.neusy> <20070213114912.5d3a76a4@jackdaw.neusy> <20070213113532.GA31234@gate.dtucker.net> <20070214114322.32877003@jackdaw.neusy> Message-ID: <45D2FE32.2050900@zip.com.au> Lars Kruse wrote: > Hi, > >>> 1) improved "is this port usable on all interfaces?"-detection >>> ipv4/ipv6 mixed openssh daemons should behave like pure ipv4 daemons: >>> unusable DISPLAY settings may never be offered to clients >> I think it's a Linuxism: IPv6 sockets prevent binding to IPv4 sockets >> on the same port but not vice versa. > hm - I do not know any details regarding this behaviour ... > > To make sure, that you understand me right, I was studying the source > code of "x11_create_display_inet" in "channel.c" again. > If I am not mistaken, then the loop > for (ai = aitop; ai; ai = ai->ai_next) > tries to connect to all available ports according to the given > restrictions (especially: address family). If at least one port is > usable, then this one is used for the X session. > > > Case 1: both ipv4 and ipv6 socket of a given port are available > no problem - both sockets are bound for the X session. > > Case 2: only the ipv4 socket of the port is available > no problem - as the display "localhost:???" (ipv4 address) is returned, > clients will only connect to the ipv4 port, anyway. > > Case 3: only the ipv6 socket of the port is available > this seems to be a problem: an ipv6 port is bound, but an ipv4 address > is returned as the display setting (DISPLAY=localhost:??? instead of > DISPLAY=ip6-localhost:???). > > > Could it be, that the return value of the DISPLAY setting does not > depend on the acquired sockets for now? (always returning an ip4 > address) For X11UseLocalhost=yes it always uses a string of "localhost" (session_setup_x11fwd in session.c). Potentially it could either get the address family from x11_create_display_inet, or maybe call getsockname on the socket and use that (provided "::1:0" is a valid display name, I have no idea if X would choke on that). The wrinkle is that some xlibs (or xauths?) do special things with the string "localhost", eg map it to a Unix domain socket. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From kruse at silicann.com Wed Feb 14 23:54:05 2007 From: kruse at silicann.com (Lars Kruse) Date: Wed, 14 Feb 2007 13:54:05 +0100 Subject: X forwarding: trying to forward to busy local port In-Reply-To: <45D2FE32.2050900@zip.com.au> References: <20070201162824.6d5f8b77@jackdaw.neusy> <20070213114912.5d3a76a4@jackdaw.neusy> <20070213113532.GA31234@gate.dtucker.net> <20070214114322.32877003@jackdaw.neusy> <45D2FE32.2050900@zip.com.au> Message-ID: <20070214135405.747d28d0@jackdaw.neusy> Hi, > > Could it be, that the return value of the DISPLAY setting does not > > depend on the acquired sockets for now? (always returning an ip4 > > address) > > For X11UseLocalhost=yes it always uses a string of "localhost" > (session_setup_x11fwd in session.c). uh - that sounds ugly for a future transition to ipv6, right? > Potentially it could either get the address family from > x11_create_display_inet, or maybe call getsockname on the socket and use > that (provided "::1:0" is a valid display name, I have no idea if X > would choke on that). I just tried the following: DISPLAY=:::30.0 xterm This works for me - the original DISPLAY setting was "localhost:30.0". > The wrinkle is that some xlibs (or xauths?) do special things with the > string "localhost", eg map it to a Unix domain socket. Do you know where this should get fixed? From my point of view, the current situation can be very frustrating for administrators of ssh-X-tunneling remote desktop servers, due to these seemingly randomly occurring failures. I went through the bug database, but I could not find a related report. Should I file a bug report for this behaviour? regards and thanks for your time, Lars From tsi at ualberta.ca Thu Feb 15 01:58:56 2007 From: tsi at ualberta.ca (Marc Aurele La France) Date: Wed, 14 Feb 2007 07:58:56 -0700 (Mountain Standard Time) Subject: X forwarding: trying to forward to busy local port In-Reply-To: <45D2FE32.2050900@zip.com.au> References: <20070201162824.6d5f8b77@jackdaw.neusy> <20070213114912.5d3a76a4@jackdaw.neusy> <20070213113532.GA31234@gate.dtucker.net> <20070214114322.32877003@jackdaw.neusy> <45D2FE32.2050900@zip.com.au> Message-ID: On Wed, 14 Feb 2007, Darren Tucker wrote: > The wrinkle is that some xlibs (or xauths?) do special things with the > string "localhost", eg map it to a Unix domain socket. This isn't so, except perhaps for some proprietary X implementations. In fact, display names of "localhost:", instead of ":" force the use of TCP/IP. This is so for both XFree86 and X.Org. Marc. +----------------------------------+----------------------------------+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and | fax: 1-780-492-1729 | | Communications Technologies | email: tsi at ualberta.ca | | 352 General Services Building +----------------------------------+ | University of Alberta | | | Edmonton, Alberta | Standard disclaimers apply | | T6G 2H1 | | | CANADA | | +----------------------------------+----------------------------------+ XFree86 developer and VP. ATI driver and X server internals. From dtucker at zip.com.au Thu Feb 15 07:23:32 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 15 Feb 2007 07:23:32 +1100 Subject: X forwarding: trying to forward to busy local port In-Reply-To: References: <20070201162824.6d5f8b77@jackdaw.neusy> <20070213114912.5d3a76a4@jackdaw.neusy> <20070213113532.GA31234@gate.dtucker.net> <20070214114322.32877003@jackdaw.neusy> <45D2FE32.2050900@zip.com.au> Message-ID: <45D36FC4.7040708@zip.com.au> Marc Aurele La France wrote: > On Wed, 14 Feb 2007, Darren Tucker wrote: > >> The wrinkle is that some xlibs (or xauths?) do special things with the >> string "localhost", eg map it to a Unix domain socket. > > This isn't so, except perhaps for some proprietary X implementations. In > fact, display names of "localhost:", instead of ":" force the use of > TCP/IP. This is so for both XFree86 and X.Org. That's interesting, because it means there's something going on here that I don't understand. When X11UseLocalhost=yes, sshd adds a unix: cookie and sets DISPLAY to "localhost:n.0" So for example, on OpenBSD-current, when I logged in sshd ran this: xauth add unix:10.0 MIT-MAGIC-COOKIE-1 f270ce6e3b353e5ad8070b4ecab4c604 and after I logged in I see this: $ echo $DISPLAY localhost:10.0 $ xauth list quoll.dtucker.net/unix:10 MIT-MAGIC-COOKIE-1 f270ce6e3b353e5ad8070b4ecab4c604 So when I run "xterm" how does it find the right cookie given that $DISPLAY and the xauth data are not identical? -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From michael.allen at novartis.com Thu Feb 15 12:02:17 2007 From: michael.allen at novartis.com (michael.allen at novartis.com) Date: Wed, 14 Feb 2007 20:02:17 -0500 Subject: LIBEAY32.DLL Ordinal 968 Message-ID: Hello, What version of LIBEAY32.DLL has Ordinal 968 defined? I have searched many versions of this dll and see that this ordinal has been deprecated. Where can I find the latest version of this dll that has this ordinal defined? Thanks, Michael Allen Novartis Pharmaceuticals Corporation Senior Technologist Novartis Pharmaceuticals Corporation One Health Plaza East Hanover, NJ 07936-1080 USA Phone: +1 862 7783177 Email : michael.allen at novartis.com From tsi at ualberta.ca Fri Feb 16 03:06:22 2007 From: tsi at ualberta.ca (Marc Aurele La France) Date: Thu, 15 Feb 2007 09:06:22 -0700 (Mountain Standard Time) Subject: X forwarding: trying to forward to busy local port In-Reply-To: <45D36FC4.7040708@zip.com.au> References: <20070201162824.6d5f8b77@jackdaw.neusy> <20070213114912.5d3a76a4@jackdaw.neusy> <20070213113532.GA31234@gate.dtucker.net> <20070214114322.32877003@jackdaw.neusy> <45D2FE32.2050900@zip.com.au> <45D36FC4.7040708@zip.com.au> Message-ID: On Thu, 15 Feb 2007, Darren Tucker wrote: > Marc Aurele La France wrote: >> On Wed, 14 Feb 2007, Darren Tucker wrote: >>> The wrinkle is that some xlibs (or xauths?) do special things with the >>> string "localhost", eg map it to a Unix domain socket. >> This isn't so, except perhaps for some proprietary X implementations. In >> fact, display names of "localhost:", instead of ":" force the use of >> TCP/IP. This is so for both XFree86 and X.Org. > That's interesting, because it means there's something going on here > that I don't understand. > When X11UseLocalhost=yes, sshd adds a unix: cookie and sets DISPLAY to > "localhost:n.0" > So for example, on OpenBSD-current, when I logged in sshd ran this: > xauth add unix:10.0 MIT-MAGIC-COOKIE-1 f270ce6e3b353e5ad8070b4ecab4c604 > and after I logged in I see this: > $ echo $DISPLAY > localhost:10.0 > $ xauth list > quoll.dtucker.net/unix:10 MIT-MAGIC-COOKIE-1 > f270ce6e3b353e5ad8070b4ecab4c604 > So when I run "xterm" how does it find the right cookie given that > $DISPLAY and the xauth data are not identical? xauth data is used to authenticate with the server, and, as such, how the connection with that server is made is irrelevant. Thus, the `xauth add` told the server at localhost:10.0 to add an authorisation for unix:10.0, which that server knows is itself. Marc. +----------------------------------+----------------------------------+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and | fax: 1-780-492-1729 | | Communications Technologies | email: tsi at ualberta.ca | | 352 General Services Building +----------------------------------+ | University of Alberta | | | Edmonton, Alberta | Standard disclaimers apply | | T6G 2H1 | | | CANADA | | +----------------------------------+----------------------------------+ XFree86 developer and VP. ATI driver and X server internals. From deepakd.82 at gmail.com Fri Feb 16 19:33:28 2007 From: deepakd.82 at gmail.com (Deepak D) Date: Fri, 16 Feb 2007 17:33:28 +0900 Subject: SFTP Library : IPv6 Address Message-ID: <1135d14b0702160033n6b905230t8a889b23834c06bf@mail.gmail.com> Dear Respected one, Does the SFTP client/server, provided as the part of the libssh, support IPv6 addresses ? I have downloaded the libssh and still working on the seperation of sftp out of libssh. If any body has information about SFTP supporting IPv6 addresses, please inform me. Thanks & Regards, Deepak D From jason at mobarak.name Sat Feb 17 08:26:41 2007 From: jason at mobarak.name (Jason Mobarak) Date: Fri, 16 Feb 2007 14:26:41 -0700 Subject: SFTP Library : IPv6 Address In-Reply-To: <1135d14b0702160033n6b905230t8a889b23834c06bf@mail.gmail.com> References: <1135d14b0702160033n6b905230t8a889b23834c06bf@mail.gmail.com> Message-ID: Deepak D wrote: > Dear Respected one, > > Does the SFTP client/server, provided as the part of the libssh, > support IPv6 addresses ? I have downloaded the libssh and still > working on the seperation of sftp out of libssh. The libssh project is not related to the OpenSSH project, they are separated implementations of the same protocol. You'll have better luck asking/searching the libssh mailing list at http://www.cerkinfo.be/cgi-bin/mailman/listinfo/libssh > > If any body has information about SFTP supporting IPv6 addresses, > please inform me. > > Thanks & Regards, > > Deepak D From thuejk at gmail.com Mon Feb 19 05:48:20 2007 From: thuejk at gmail.com (Thue Janus Kristensen) Date: Sun, 18 Feb 2007 19:48:20 +0100 Subject: SFTP: a new command to get filesystem size/free space Message-ID: <2fa647f60702181048h2cbaf171h9e4796f2a6d57c7d@mail.gmail.com> I am using sshfs with FUSE to mount a remote directory over ssh/sftp (on linux). It would be nice if df could be able to show the total size/free space of the mounted directory. I am aware that returning size/free space would have some limitations. For example, if a subdir of the mounted directory has another filesystem mounted on the remote server, this can not be represented simply. However, I still think that a simple implementation could be useful. My idea is to simply return the total size and free space of the current working directory. Would you accept patches implementing this? Please CC me, I am not on this list. Regards, Thue PS: does the openssh sftp implementation conform to http://www.openssh.org/txt/draft-ietf-secsh-filexfer-02.txt ? If not, is the protocol described elsewhere? From michael at prochas.net Mon Feb 19 18:52:29 2007 From: michael at prochas.net (Michael Prochaska) Date: Mon, 19 Feb 2007 08:52:29 +0100 Subject: sftp logging Message-ID: <45D9573D.4060507@prochas.net> hello! i want to use the new options for sftp logging (openshh version 4.5, solaris 10), but sshd doesn't know the options (LogSftp, Sftpxxxxx) from the release notes 4.4: " * Add optional logging of transactions to sftp-server(8). " 4.5 is only a bug fix version. from http://sftplogging.sourceforge.net/ " NOTICE: 1/31/2007. This patch is superseded by the sftpfilecontrol patch (http://sftpfilecontrol.sourceforge.net). The sftpfilecontrol patch is the same patch, without the logging functions. This is due to that openssh is now including sftp logging in their code. The sftpfilecontrol patch continues to provide server-side control over umask, chown and chmod; this control is not included in openssh. " i haven't found any specific compile options for sftp logging. i've tried the original openssh sources and the precompiled sunfreeware version. whats wrong here? does openssh support sftp logging? is it bug? best regards, michael From dtucker at zip.com.au Mon Feb 19 19:57:34 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 19 Feb 2007 19:57:34 +1100 Subject: sftp logging In-Reply-To: <45D9573D.4060507@prochas.net> References: <45D9573D.4060507@prochas.net> Message-ID: <45D9667E.9080707@zip.com.au> Michael Prochaska wrote: > i want to use the new options for sftp logging (openshh version 4.5, > solaris 10), but sshd doesn't know the options (LogSftp, Sftpxxxxx) [...] > whats wrong here? does openssh support sftp logging? is it bug? OpenSSH's sftp logging is turned on on by specifying "-l" to sftp-server. Trying making the "Subsystem sftp" line in sshd_config look something like the following and then restart sshd. Subsystem sftp /usr/libexec/sftp-server -l VERBOSE -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From michael at prochas.net Mon Feb 19 20:06:24 2007 From: michael at prochas.net (Michael Prochaska) Date: Mon, 19 Feb 2007 10:06:24 +0100 Subject: sftp logging In-Reply-To: <45D9667E.9080707@zip.com.au> References: <45D9573D.4060507@prochas.net> <45D9667E.9080707@zip.com.au> Message-ID: <45D96890.2050501@prochas.net> Darren Tucker schrieb: > Michael Prochaska wrote: > >> i want to use the new options for sftp logging (openshh version 4.5, >> solaris 10), but sshd doesn't know the options (LogSftp, Sftpxxxxx) >> > [...] > >> whats wrong here? does openssh support sftp logging? is it bug? >> > > OpenSSH's sftp logging is turned on on by specifying "-l" to sftp-server. > > Trying making the "Subsystem sftp" line in sshd_config look something > like the following and then restart sshd. > > Subsystem sftp /usr/libexec/sftp-server -l VERBOSE > > i've tried, no change. # override default of no subsystems Subsystem sftp /usr/local/libexec/sftp-server -l VERBOSE /usr/local/etc/sshd_config: line 113: Bad configuration option: LogSftp any ideas? best regards, michael From stuge-openssh-unix-dev at cdy.org Mon Feb 19 20:22:56 2007 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Mon, 19 Feb 2007 10:22:56 +0100 Subject: sftp logging In-Reply-To: <45D96890.2050501@prochas.net> References: <45D9573D.4060507@prochas.net> <45D9667E.9080707@zip.com.au> <45D96890.2050501@prochas.net> Message-ID: <20070219092256.8331.qmail@cdy.org> On Mon, Feb 19, 2007 at 10:06:24AM +0100, Michael Prochaska wrote: > > OpenSSH's sftp logging is turned on on by specifying "-l" to sftp-server. > > Subsystem sftp /usr/local/libexec/sftp-server -l VERBOSE > > /usr/local/etc/sshd_config: line 113: Bad configuration option: LogSftp > > any ideas? What do you expect the configuration directive LogSftp to do? Note that just because the functionality of the patch is now included in OpenSSH the interface is not neccessarily exactly the same. I don't know about this particular case, but I believe the -l option to sftp-server is all you need. Try to just remove the config options you added to sshd_config. //Peter From dtucker at zip.com.au Mon Feb 19 20:39:46 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 19 Feb 2007 20:39:46 +1100 Subject: sftp logging In-Reply-To: <45D96890.2050501@prochas.net> References: <45D9573D.4060507@prochas.net> <45D9667E.9080707@zip.com.au> <45D96890.2050501@prochas.net> Message-ID: <20070219093946.GA16277@gate.dtucker.net> On Mon, Feb 19, 2007 at 10:06:24AM +0100, Michael Prochaska wrote: > Darren Tucker schrieb: [..] > >Subsystem sftp /usr/libexec/sftp-server -l VERBOSE > > i've tried, no change. > > # override default of no subsystems > Subsystem sftp /usr/local/libexec/sftp-server -l VERBOSE > > /usr/local/etc/sshd_config: line 113: Bad configuration option: LogSftp > > any ideas? Stop using options for a piece of software other that what you're using. OpenSSH doesn't support a "LogSftp" option, logging is controlled entirely via the options to sftp-server. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Mon Feb 19 20:43:10 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 19 Feb 2007 20:43:10 +1100 Subject: sftp logging In-Reply-To: <45D96D2F.5010907@adaptive-enterprises.com.au> References: <45D9573D.4060507@prochas.net> <45D9667E.9080707@zip.com.au> <45D96D2F.5010907@adaptive-enterprises.com.au> Message-ID: <20070219094310.GB16277@gate.dtucker.net> On Mon, Feb 19, 2007 at 07:26:07PM +1000, David Leonard wrote: > note that users can bypass your sftp-server log levels. e.g. by > supplying the -s option to sftp with the full path to the sftp-server > executable. However, they can supply their own logging levels, which > can be handy, eg > > $ sftp -s '/usr/libexec/sftp-server -lDEBUG -fDAEMON' remote-host That's a good point. If it matters and they only need sftp access you can use something like Match Group sftpusers ForceCommand /usr/libexec/sftp-server -l [...] Once a user has shell access they can transfer files using pretty much anything (tar, cat, grep, or anything they can install if they have a writable directory). -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From michael at prochas.net Mon Feb 19 20:43:33 2007 From: michael at prochas.net (Michael Prochaska) Date: Mon, 19 Feb 2007 10:43:33 +0100 Subject: sftp logging In-Reply-To: <20070219093946.GA16277@gate.dtucker.net> References: <45D9573D.4060507@prochas.net> <45D9667E.9080707@zip.com.au> <45D96890.2050501@prochas.net> <20070219093946.GA16277@gate.dtucker.net> Message-ID: <45D97145.1020800@prochas.net> Darren Tucker schrieb: > On Mon, Feb 19, 2007 at 10:06:24AM +0100, Michael Prochaska wrote: > >> Darren Tucker schrieb: >> > [..] > >>> Subsystem sftp /usr/libexec/sftp-server -l VERBOSE >>> >> i've tried, no change. >> >> # override default of no subsystems >> Subsystem sftp /usr/local/libexec/sftp-server -l VERBOSE >> >> /usr/local/etc/sshd_config: line 113: Bad configuration option: LogSftp >> >> any ideas? >> > > Stop using options for a piece of software other that what you're using. > OpenSSH doesn't support a "LogSftp" option, logging is controlled entirely > via the options to sftp-server. > > i used a config file which was maintained by sunfreeware.org with this package. therefore i used this options. thanks very much, michael From dtucker at zip.com.au Mon Feb 19 20:59:48 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 19 Feb 2007 20:59:48 +1100 Subject: sftp logging In-Reply-To: <45D97145.1020800@prochas.net> References: <45D9573D.4060507@prochas.net> <45D9667E.9080707@zip.com.au> <45D96890.2050501@prochas.net> <20070219093946.GA16277@gate.dtucker.net> <45D97145.1020800@prochas.net> Message-ID: <20070219095948.GA16634@gate.dtucker.net> On Mon, Feb 19, 2007 at 10:43:33AM +0100, Michael Prochaska wrote: > Darren Tucker schrieb: [...] > > Stop using options for a piece of software other that what you're using. > > OpenSSH doesn't support a "LogSftp" option, logging is controlled entirely > > via the options to sftp-server. > > i used a config file which was maintained by sunfreeware.org with this > package. therefore i used this options. I suspect that they used to apply the sftp logging patch and failed to update their config files when they dropped it in favour of the native logging support. You would have to ask them. Anyway, both I and the software itself are telling you that it's not supported, so you might want to try removing it from the config. OpenSSH's sftp logging support is enabled entirely by the options to sftp-server (see the sftp-server(8) man page for details). -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From michael at prochas.net Mon Feb 19 21:26:12 2007 From: michael at prochas.net (Michael Prochaska) Date: Mon, 19 Feb 2007 11:26:12 +0100 Subject: sftp logging In-Reply-To: <20070219095948.GA16634@gate.dtucker.net> References: <45D9573D.4060507@prochas.net> <45D9667E.9080707@zip.com.au> <45D96890.2050501@prochas.net> <20070219093946.GA16277@gate.dtucker.net> <45D97145.1020800@prochas.net> <20070219095948.GA16634@gate.dtucker.net> Message-ID: <45D97B44.7050805@prochas.net> Darren Tucker schrieb: > On Mon, Feb 19, 2007 at 10:43:33AM +0100, Michael Prochaska wrote: > >> Darren Tucker schrieb: >> > [...] > >>> Stop using options for a piece of software other that what you're using. >>> OpenSSH doesn't support a "LogSftp" option, logging is controlled entirely >>> via the options to sftp-server. >>> >> i used a config file which was maintained by sunfreeware.org with this >> package. therefore i used this options. >> > > I suspect that they used to apply the sftp logging patch and failed to > update their config files when they dropped it in favour of the native > logging support. You would have to ask them. > > Anyway, both I and the software itself are telling you that it's > not supported, so you might want to try removing it from the config. > OpenSSH's sftp logging support is enabled entirely by the options to > sftp-server (see the sftp-server(8) man page for details). > > ok, i've understood :-) that was only a statement why i had tried this options . it works fine! best regards, michael From kruse at silicann.com Mon Feb 19 22:06:44 2007 From: kruse at silicann.com (Lars Kruse) Date: Mon, 19 Feb 2007 12:06:44 +0100 Subject: X forwarding: trying to forward to busy local port In-Reply-To: <45D2FE32.2050900@zip.com.au> References: <20070201162824.6d5f8b77@jackdaw.neusy> <20070213114912.5d3a76a4@jackdaw.neusy> <20070213113532.GA31234@gate.dtucker.net> <20070214114322.32877003@jackdaw.neusy> <45D2FE32.2050900@zip.com.au> Message-ID: <20070219120644.35e9f357@jackdaw.neusy> Hi, > > Could it be, that the return value of the DISPLAY setting does not > > depend on the acquired sockets for now? (always returning an ip4 > > address) > > For X11UseLocalhost=yes it always uses a string of "localhost" > (session_setup_x11fwd in session.c). > > Potentially it could either get the address family from > x11_create_display_inet, or maybe call getsockname on the socket and use > that (provided "::1:0" is a valid display name, I have no idea if X > would choke on that). the ipv6 address does not seem to be a problem for DISPLAY - see http://permalink.gmane.org/gmane.network.openssh.devel/13384 > The wrinkle is that some xlibs (or xauths?) do special things with the > string "localhost", eg map it to a Unix domain socket. According to Marc Aurele La France (http://permalink.gmane.org/gmane.network.openssh.devel/13385) this does not seem to a problem for xorg/xfree86, too. Maybe I get something wrong, but for now the setting "AdressFamily any" seems to severely degrade the reliability of X-forwarding setups. Did someone already file a bug report for this behaviour? I could not find any. Otherwise I would like to do create one. regards, Lars From d at adaptive-enterprises.com.au Mon Feb 19 20:26:07 2007 From: d at adaptive-enterprises.com.au (David Leonard) Date: Mon, 19 Feb 2007 19:26:07 +1000 Subject: sftp logging In-Reply-To: <45D9667E.9080707@zip.com.au> References: <45D9573D.4060507@prochas.net> <45D9667E.9080707@zip.com.au> Message-ID: <45D96D2F.5010907@adaptive-enterprises.com.au> Darren Tucker wrote: > OpenSSH's sftp logging is turned on on by specifying "-l" to sftp-server. > > Trying making the "Subsystem sftp" line in sshd_config look something > like the following and then restart sshd. > > Subsystem sftp /usr/libexec/sftp-server -l VERBOSE > note that users can bypass your sftp-server log levels. e.g. by supplying the -s option to sftp with the full path to the sftp-server executable. However, they can supply their own logging levels, which can be handy, eg $ sftp -s '/usr/libexec/sftp-server -lDEBUG -fDAEMON' remote-host d -- David Leonard d at adaptive-enterprises.com.au Ph:+61 404 844 850 From deadbeefbabe at gmail.com Tue Feb 20 03:10:44 2007 From: deadbeefbabe at gmail.com (Jason Mobarak) Date: Mon, 19 Feb 2007 09:10:44 -0700 Subject: SFTP: a new command to get filesystem size/free space In-Reply-To: <2fa647f60702181048h2cbaf171h9e4796f2a6d57c7d@mail.gmail.com> References: <2fa647f60702181048h2cbaf171h9e4796f2a6d57c7d@mail.gmail.com> Message-ID: <45D9CC04.1020807@gmail.com> Thue Janus Kristensen wrote: > I am using sshfs with FUSE to mount a remote directory over ssh/sftp (on linux). > > It would be nice if df could be able to show the total size/free space > of the mounted directory. > > I am aware that returning size/free space would have some limitations. > For example, if a subdir of the mounted directory has another > filesystem mounted on the remote server, this can not be represented > simply. > > However, I still think that a simple implementation could be useful. > My idea is to simply return the total size and free space of the > current working directory. > > Would you accept patches implementing this? I don't speak for the OpenSSH team but given the history of previous random patches I doubt it will be accepted in any fashion. > > Please CC me, I am not on this list. > > Regards, Thue > > PS: does the openssh sftp implementation conform to > http://www.openssh.org/txt/draft-ietf-secsh-filexfer-02.txt ? If not, > is the protocol described elsewhere? Afaik, yes, OpenSSH supports SFTP version 3, and probably won't support anything else anytime soon. Your feature can probably be easily implemented via the SSH_FXP_EXTENDED message. Though an SSH subsystem for drive metrics might be interesting. -- Jason From jmknoble at pobox.com Tue Feb 20 04:40:25 2007 From: jmknoble at pobox.com (Jim Knoble) Date: Mon, 19 Feb 2007 12:40:25 -0500 Subject: X forwarding: trying to forward to busy local port In-Reply-To: <20070219120644.35e9f357@jackdaw.neusy> References: <20070201162824.6d5f8b77@jackdaw.neusy> <20070213114912.5d3a76a4@jackdaw.neusy> <20070213113532.GA31234@gate.dtucker.net> <20070214114322.32877003@jackdaw.neusy> <45D2FE32.2050900@zip.com.au> <20070219120644.35e9f357@jackdaw.neusy> Message-ID: <20070219174025.GA21020@crawfish.ais.com> Circa 2007-02-19 06:06 dixit Lars Kruse: : Maybe I get something wrong, but for now the setting "AdressFamily any" : seems to severely degrade the reliability of X-forwarding setups. : Did someone already file a bug report for this behaviour? I could not : find any. Otherwise I would like to do create one. Anyone know if there's an IPv6 equivalent to Linux's /proc/sys/net/ipv4/ip_local_port_range (equivalent to the 'net.ipv4.ip_local_port_range' sysctl)? Under IPv4, this twiddles the port range available when connect(2)-ing without specifying the local endpoint's TCP port number. If there is such a twiddle for IPv6, you might be able to use it to work around this problem. For example, with the IPv4 setting: su root -c sysctl -w 'net.ipv4.ip_local_port_range=7000 65535' Best, jim -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ (GnuPG key ID: 6F39C2CC >>>>>> http://www.pobox.com/~jmknoble/keys/ ) (GnuPG fingerprint: 5024:D578:7CF4:5660:7269::F6F3:B919:9307:6F39:C2CC) +----------------------------------------------------------------------+ |[L]iberty, as we all know, cannot flourish in a country that is perma-| | nently on a war footing, or even a near-war footing. --Aldous Huxley| +----------------------------------------------------------------------+ From djm at mindrot.org Tue Feb 20 09:20:31 2007 From: djm at mindrot.org (Damien Miller) Date: Tue, 20 Feb 2007 09:20:31 +1100 (EST) Subject: SFTP: a new command to get filesystem size/free space In-Reply-To: <2fa647f60702181048h2cbaf171h9e4796f2a6d57c7d@mail.gmail.com> References: <2fa647f60702181048h2cbaf171h9e4796f2a6d57c7d@mail.gmail.com> Message-ID: On Sun, 18 Feb 2007, Thue Janus Kristensen wrote: > I am using sshfs with FUSE to mount a remote directory over ssh/sftp > (on linux). > > It would be nice if df could be able to show the total size/free space > of the mounted directory. > > I am aware that returning size/free space would have some limitations. > For example, if a subdir of the mounted directory has another > filesystem mounted on the remote server, this can not be represented > simply. > > However, I still think that a simple implementation could be useful. > My idea is to simply return the total size and free space of the > current working directory. > > Would you accept patches implementing this? We would consider them, sure - but we can't promise we will like them enough to accept them before we see them :) The patch would have the best chance of being accepted if it used the SSH2_FXP_EXTENDED protocol message and followed the message format of later filexfer drafts for the encoding of filesystem information (IIRC recent filexfer drafts have a statvfs-like method). The patch would also need to implement support for it in the sftp client, so we can have a way to test the method in our regress tests. > PS: does the openssh sftp implementation conform to > http://www.openssh.org/txt/draft-ietf-secsh-filexfer-02.txt ? If not, > is the protocol described elsewhere? IIRC we actually implement filexfer-03, but the draft for it seems to have fallen off the net. -d From thuejk at gmail.com Tue Feb 20 10:37:54 2007 From: thuejk at gmail.com (Thue Janus Kristensen) Date: Tue, 20 Feb 2007 00:37:54 +0100 Subject: SFTP: a new command to get filesystem size/free space In-Reply-To: References: <2fa647f60702181048h2cbaf171h9e4796f2a6d57c7d@mail.gmail.com> Message-ID: <2fa647f60702191537u6935be31vdd04ebe9eb28b644@mail.gmail.com> On 2/19/07, Damien Miller wrote: > On Sun, 18 Feb 2007, Thue Janus Kristensen wrote: > > > I am using sshfs with FUSE to mount a remote directory over ssh/sftp > > (on linux). > > > > It would be nice if df could be able to show the total size/free space > > of the mounted directory. > > > > I am aware that returning size/free space would have some limitations. > > For example, if a subdir of the mounted directory has another > > filesystem mounted on the remote server, this can not be represented > > simply. > > > > However, I still think that a simple implementation could be useful. > > My idea is to simply return the total size and free space of the > > current working directory. > > > > Would you accept patches implementing this? > > We would consider them, sure - but we can't promise we will like > them enough to accept them before we see them :) Of course :) > The patch would have the best chance of being accepted if it used the > SSH2_FXP_EXTENDED protocol message and followed the message format of > later filexfer drafts for the encoding of filesystem information (IIRC > recent filexfer drafts have a statvfs-like method). I skimmed http://tools.ietf.org/html/draft-ietf-secsh-filexfer-13 , the latest version available at http://tools.ietf.org/wg/secsh/draft-ietf-secsh-filexfer/ , but I didn't notice any reference to this. > The patch would also need to implement support for it in the sftp > client, so we can have a way to test the method in our regress tests. Of course. > > PS: does the openssh sftp implementation conform to > > http://www.openssh.org/txt/draft-ietf-secsh-filexfer-02.txt ? If not, > > is the protocol described elsewhere? > > IIRC we actually implement filexfer-03, but the draft for it seems to > have fallen off the net. > > -d It is available at http://tools.ietf.org/wg/secsh/draft-ietf-secsh-filexfer/ Regards, Thue From kruse at silicann.com Tue Feb 20 22:05:59 2007 From: kruse at silicann.com (Lars Kruse) Date: Tue, 20 Feb 2007 12:05:59 +0100 Subject: X forwarding: trying to forward to busy local port In-Reply-To: <20070219174025.GA21020@crawfish.ais.com> References: <20070201162824.6d5f8b77@jackdaw.neusy> <20070213114912.5d3a76a4@jackdaw.neusy> <20070213113532.GA31234@gate.dtucker.net> <20070214114322.32877003@jackdaw.neusy> <45D2FE32.2050900@zip.com.au> <20070219120644.35e9f357@jackdaw.neusy> <20070219174025.GA21020@crawfish.ais.com> Message-ID: <20070220120559.5dfd9151@jackdaw.neusy> Hi, >> Maybe I get something wrong, but for now the setting "AdressFamily any" >> seems to severely degrade the reliability of X-forwarding setups. >> Did someone already file a bug report for this behaviour? I could not >> find any. Otherwise I would like to do create one. > > Anyone know if there's an IPv6 equivalent to Linux's > /proc/sys/net/ipv4/ip_local_port_range (equivalent to the > 'net.ipv4.ip_local_port_range' sysctl)? Under IPv4, this twiddles the > port range available when connect(2)-ing without specifying the local > endpoint's TCP port number. that is a good hint - this workaround would help to avoid the use of the critical poprts around 6000. I applied it here. Thanks! But still the ipv6 support of openssh seems to be broken, as the DISPLAY setting always returns the hardcoded ipv4 address "localhost". This makes it impossible to use a pure ipv6 setup, right? regards, Lars From andrew at gaul.org Wed Feb 21 17:45:44 2007 From: andrew at gaul.org (Andrew Gaul) Date: Wed, 21 Feb 2007 01:45:44 -0500 Subject: sshd unhandled SIGALRM (resend) Message-ID: <20070221064544.GA6090@paat.pair.com> sshd will die from an unhandled SIGALRM if you allow SSH1 connections, ssh in, HUP sshd, and don't ssh in again for KeyRegenerationInterval. The HUP handler calls exec which resets signal handlers but persists alarm timers. Chapter and verse: http://www.opengroup.org/onlinepubs/000095399/functions/alarm.html -- Andrew Gaul http://gaul.org/ -------------- next part -------------- Index: sshd.c =================================================================== RCS file: /cvs/openssh/sshd.c,v retrieving revision 1.361 diff -u -p -r1.361 sshd.c --- sshd.c 7 Nov 2006 12:14:42 -0000 1.361 +++ sshd.c 21 Feb 2007 06:37:18 -0000 @@ -305,6 +305,7 @@ sighup_restart(void) logit("Received SIGHUP; restarting."); close_listen_socks(); close_startup_pipes(); + alarm(0); /* alarm timer persists across exec */ execv(saved_argv[0], saved_argv); logit("RESTART FAILED: av[0]='%.100s', error: %.100s.", saved_argv[0], strerror(errno)); From BenWillis at anderson5.net Fri Feb 23 07:53:54 2007 From: BenWillis at anderson5.net (Willis, Ben) Date: Thu, 22 Feb 2007 15:53:54 -0500 Subject: OpenSSH and pam_ncp_auth.so Message-ID: <098B90F26175B74DB1F74126AEFC9C770411BC18@a5do-mail.acsd5.local> I have seen in the archives that several people have tried to use this module with OpenSSH. Now that the LTSP project has moved to LDM with SSH tunnels in Edubuntu I wondered if the issue with ssh requiring a local account to already exist could be revisited? Even though I know that the opinion has been that the module is 'broken' because some people believe that PAM should be used purely for authentication this limitation is making it VERY hard for those of us in the Education IT field. Would it be possible to have a fix for this that could be applied if one wished? Petr, I have copied you on this email for reference to the pam_ncp_auth modules maintainer. Thanks! Ben Willis Anderson School District Five Anderson, SC From dtucker at zip.com.au Fri Feb 23 09:38:38 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 23 Feb 2007 09:38:38 +1100 Subject: OpenSSH and pam_ncp_auth.so In-Reply-To: <098B90F26175B74DB1F74126AEFC9C770411BC18@a5do-mail.acsd5.local> References: <098B90F26175B74DB1F74126AEFC9C770411BC18@a5do-mail.acsd5.local> Message-ID: <45DE1B6E.20109@zip.com.au> Willis, Ben wrote: > I have seen in the archives that several people have tried to use > this module with OpenSSH. Now that the LTSP project has moved to LDM > with SSH tunnels in Edubuntu I wondered if the issue with ssh > requiring a local account to already exist could be revisited? Even > though I know that the opinion has been that the module is 'broken' > because some people believe that PAM should be used purely for > authentication this limitation is making it VERY hard for those of us > in the Education IT field. > > Would it be possible to have a fix for this that could be applied if > one wished? See: http://bugzilla.mindrot.org/show_bug.cgi?id=1215 There's a patch for sshd and also some pointers to alternate solutions. If you test the patch then please report your experiences (good or bad), preferably by adding a comment to the bug. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From openssh at p23q.org Sat Feb 24 05:10:32 2007 From: openssh at p23q.org (openssh at p23q.org) Date: Fri, 23 Feb 2007 18:10:32 +0000 Subject: ssh-agent does not immediately clean timeouted keys from memory Message-ID: <20070223181032.GA13124@ganymede> during my seminar of advanced exploitation techniques (SEAT, [1]) i developed some methods to crack into system via DMA (e.g. via firewire). as part of this i developed a program that steals loaded ssh private keys from ssh-agents. i was astonished to find that the keys are not immediately removed from the agent when a timeout occurs, but only the next time the agent is queried via its socket. i have written a __rough__ patch that should fix the problem (a timer checks every 10 seconds). please take a look at it and, if you like it, incorporate it. the patch can be found at [2], more information on other things i developed during SEAT can be found at [3] - once i release the stuff (in a few days, i think). so far losTrace a.k.a. David R. Piegdon [1] seminar of advanced exploitation techniques http://www-i4.informatik.rwth-aachen.de/content/teaching/seminars/sub/2006_2007_seat_seminar.html [2] rough patch that fixes ssh-agent timeout problem http://david.piegdon.de/SEAT/ssh-agent.patch [3] more information on my stuff http://david.piegdon.de/products.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20070223/e7730d88/attachment-0001.bin From dtucker at zip.com.au Sat Feb 24 10:18:38 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 24 Feb 2007 10:18:38 +1100 Subject: ssh-agent does not immediately clean timeouted keys from memory In-Reply-To: <20070223181032.GA13124@ganymede> References: <20070223181032.GA13124@ganymede> Message-ID: <20070223231838.GA15726@gate.dtucker.net> On Fri, Feb 23, 2007 at 06:10:32PM +0000, openssh at p23q.org wrote: > during my seminar of advanced exploitation techniques (SEAT, [1]) i > developed some methods to crack into system via DMA (e.g. via firewire). > as part of this i developed a program that steals loaded ssh private > keys from ssh-agents. i was astonished to find that the keys are not > immediately removed from the agent when a timeout occurs, but only the > next time the agent is queried via its socket. i have written a > __rough__ patch that should fix the problem (a timer checks every 10 > seconds). please take a look at it and, if you like it, incorporate it. Overloading the sigalrm handler seems unnecessarily complex when select(2) has a perfectly good timeout parameter :-) -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. -------------- next part -------------- Index: ssh-agent.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh/ssh-agent.c,v retrieving revision 1.169 diff -u -p -r1.169 ssh-agent.c --- ssh-agent.c 23 Oct 2006 17:01:16 -0000 1.169 +++ ssh-agent.c 23 Feb 2007 23:01:21 -0000 @@ -434,6 +434,7 @@ reaper(void) for (id = TAILQ_FIRST(&tab->idlist); id; id = nxt) { nxt = TAILQ_NEXT(id, next); if (id->death != 0 && now >= id->death) { + debug("expiring '%s'", id->comment); TAILQ_REMOVE(&tab->idlist, id, next); free_identity(id); tab->nentries--; @@ -698,9 +699,6 @@ process_message(SocketEntry *e) u_int msg_len, type; u_char *cp; - /* kill dead keys */ - reaper(); - if (buffer_len(&e->input) < 5) return; /* Incomplete message. */ cp = buffer_ptr(&e->input); @@ -828,10 +826,14 @@ new_socket(sock_type type, int fd) } static int -prepare_select(fd_set **fdrp, fd_set **fdwp, int *fdl, u_int *nallocp) +prepare_select(fd_set **fdrp, fd_set **fdwp, int *fdl, u_int *nallocp, + struct timeval **tvpp) { - u_int i, sz; - int n = 0; + u_int i, sz, deadline = 0; + int n = 0, version, timeout; + Identity *id, *nxt; + Idtab *tab; + time_t now = time(NULL); for (i = 0; i < sockets_alloc; i++) { switch (sockets[i].type) { @@ -875,6 +877,26 @@ prepare_select(fd_set **fdrp, fd_set **f break; } } + + for (version = 1; version < 3; version++) { + tab = idtab_lookup(version); + for (id = TAILQ_FIRST(&tab->idlist); id; id = nxt) { + nxt = TAILQ_NEXT(id, next); + if (id->death != 0) { + if (deadline == 0) + deadline = id->death; + else + deadline = MIN(deadline, id->death); + } + } + } + if (deadline == 0) { + *tvpp = NULL; + } else { + timeout = deadline - now; + (*tvpp)->tv_sec = timeout < 0 ? 0 : timeout; + (*tvpp)->tv_usec = 0; + } return (1); } @@ -1016,7 +1038,7 @@ int main(int ac, char **av) { int c_flag = 0, d_flag = 0, k_flag = 0, s_flag = 0; - int sock, fd, ch; + int sock, fd, ch, result; u_int nalloc; char *shell, *format, *pidstr, *agentsocket = NULL; fd_set *readsetp = NULL, *writesetp = NULL; @@ -1029,6 +1051,7 @@ main(int ac, char **av) extern char *optarg; pid_t pid; char pidstrbuf[1 + 3 * sizeof pid]; + struct timeval tv, *tvp; /* Ensure that fds 0, 1 and 2 are open or directed to /dev/null */ sanitise_stdfd(); @@ -1242,13 +1265,16 @@ skip: nalloc = 0; while (1) { - prepare_select(&readsetp, &writesetp, &max_fd, &nalloc); - if (select(max_fd + 1, readsetp, writesetp, NULL, NULL) < 0) { + tvp = &tv; + prepare_select(&readsetp, &writesetp, &max_fd, &nalloc, &tvp); + result = select(max_fd + 1, readsetp, writesetp, NULL, tvp); + reaper(); /* remove expired keys */ + if (result < 0) { if (errno == EINTR) continue; fatal("select: %s", strerror(errno)); - } - after_select(readsetp, writesetp); + } else if (result > 0) + after_select(readsetp, writesetp); } /* NOTREACHED */ } From dtucker at zip.com.au Sat Feb 24 11:47:40 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 24 Feb 2007 11:47:40 +1100 Subject: ssh-agent does not immediately clean timeouted keys from memory In-Reply-To: <20070223231838.GA15726@gate.dtucker.net> References: <20070223181032.GA13124@ganymede> <20070223231838.GA15726@gate.dtucker.net> Message-ID: <20070224004740.GA26960@gate.dtucker.net> On Sat, Feb 24, 2007 at 10:18:38AM +1100, Darren Tucker wrote: > On Fri, Feb 23, 2007 at 06:10:32PM +0000, openssh at p23q.org wrote: > > during my seminar of advanced exploitation techniques (SEAT, [1]) i > > developed some methods to crack into system via DMA (e.g. via firewire). > > as part of this i developed a program that steals loaded ssh private > > keys from ssh-agents. i was astonished to find that the keys are not > > immediately removed from the agent when a timeout occurs, but only the > > next time the agent is queried via its socket. i have written a > > __rough__ patch that should fix the problem (a timer checks every 10 > > seconds). please take a look at it and, if you like it, incorporate it. > > Overloading the sigalrm handler seems unnecessarily complex when select(2) > has a perfectly good timeout parameter :-) A slightly smaller patch that uses the existing loop in the reaper() function to compute the next timeout. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. -------------- next part -------------- Index: ssh-agent.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh/ssh-agent.c,v retrieving revision 1.169 diff -u -p -r1.169 ssh-agent.c --- ssh-agent.c 23 Oct 2006 17:01:16 -0000 1.169 +++ ssh-agent.c 24 Feb 2007 00:21:24 -0000 @@ -421,10 +421,10 @@ process_remove_all_identities(SocketEntr buffer_put_char(&e->output, SSH_AGENT_SUCCESS); } -static void +static u_int reaper(void) { - u_int now = time(NULL); + u_int deadline = 0, now = time(NULL); Identity *id, *nxt; int version; Idtab *tab; @@ -433,13 +433,23 @@ reaper(void) tab = idtab_lookup(version); for (id = TAILQ_FIRST(&tab->idlist); id; id = nxt) { nxt = TAILQ_NEXT(id, next); - if (id->death != 0 && now >= id->death) { - TAILQ_REMOVE(&tab->idlist, id, next); - free_identity(id); - tab->nentries--; + if (id->death != 0) { + if (now >= id->death) { + debug("expiring key '%s'", id->comment); + TAILQ_REMOVE(&tab->idlist, id, next); + free_identity(id); + tab->nentries--; + } else { + if (deadline == 0) + deadline = id->death; + else + deadline = + MIN(deadline, id->death); + } } } } + return deadline; } static void @@ -698,9 +708,6 @@ process_message(SocketEntry *e) u_int msg_len, type; u_char *cp; - /* kill dead keys */ - reaper(); - if (buffer_len(&e->input) < 5) return; /* Incomplete message. */ cp = buffer_ptr(&e->input); @@ -828,10 +835,11 @@ new_socket(sock_type type, int fd) } static int -prepare_select(fd_set **fdrp, fd_set **fdwp, int *fdl, u_int *nallocp) +prepare_select(fd_set **fdrp, fd_set **fdwp, int *fdl, u_int *nallocp, + struct timeval **tvpp) { - u_int i, sz; - int n = 0; + u_int i, sz, deadline; + int n = 0, timeout; for (i = 0; i < sockets_alloc; i++) { switch (sockets[i].type) { @@ -875,6 +883,14 @@ prepare_select(fd_set **fdrp, fd_set **f break; } } + + if ((deadline = reaper()) == 0) { + *tvpp = NULL; + } else { + timeout = deadline - time(NULL); + (*tvpp)->tv_sec = timeout < 0 ? 0 : timeout; + (*tvpp)->tv_usec = 0; + } return (1); } @@ -1016,7 +1032,7 @@ int main(int ac, char **av) { int c_flag = 0, d_flag = 0, k_flag = 0, s_flag = 0; - int sock, fd, ch; + int sock, fd, ch, result; u_int nalloc; char *shell, *format, *pidstr, *agentsocket = NULL; fd_set *readsetp = NULL, *writesetp = NULL; @@ -1029,6 +1045,7 @@ main(int ac, char **av) extern char *optarg; pid_t pid; char pidstrbuf[1 + 3 * sizeof pid]; + struct timeval tv, *tvp; /* Ensure that fds 0, 1 and 2 are open or directed to /dev/null */ sanitise_stdfd(); @@ -1242,13 +1259,16 @@ skip: nalloc = 0; while (1) { - prepare_select(&readsetp, &writesetp, &max_fd, &nalloc); - if (select(max_fd + 1, readsetp, writesetp, NULL, NULL) < 0) { + tvp = &tv; + prepare_select(&readsetp, &writesetp, &max_fd, &nalloc, &tvp); + result = select(max_fd + 1, readsetp, writesetp, NULL, tvp); + reaper(); /* remove expired keys */ + if (result < 0) { if (errno == EINTR) continue; fatal("select: %s", strerror(errno)); - } - after_select(readsetp, writesetp); + } else if (result > 0) + after_select(readsetp, writesetp); } /* NOTREACHED */ } From Sathidevi_Raj at syntelinc.com Sun Feb 25 00:43:05 2007 From: Sathidevi_Raj at syntelinc.com (Raj, Sathidevi) Date: Sat, 24 Feb 2007 08:43:05 -0500 Subject: Unable to establish SSH connection Message-ID: <0CDCA80D2C309C42958E5D983B9B58444B7BFC@chennaiexch4.synchen03.com> Hello, We are having the HPUX 11i as our OS platform. We are trying to establish SSH connection in the same machine to the other user. The idrsa.pub is generated using ssh-keygen and the same is copied to the remote user to the file authorized_keys. Also restarted the server. Now when I issue the command, ssh loginname at ipaddress, the expected result is it should not prompt for the password and connect to the remote user. Instead it is again prompting for the password. May I expect the response immediately? Thanks & Regards Sathidevi P. Syntel Inc. > Consider IT Done N 3243 D +91-44-4392(7312) M +91 98-4089(1143) E sathidevi_raj at syntelinc.com W http://www.syntelinc.com ____________________________________________ Confidential: This electronic message and all contents contain information from Syntel, Inc. which may be privileged, confidential or otherwise protected from disclosure. The information is intended to be for the addressee only. If you are not the addressee, any disclosure, copy, distribution or use of the contents of this message is prohibited. If you have received this electronic message in error, please notify the sender immediately and destroy the original message and all copies. From stuge-openssh-unix-dev at cdy.org Mon Feb 26 19:03:11 2007 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Mon, 26 Feb 2007 09:03:11 +0100 Subject: Unable to establish SSH connection In-Reply-To: <0CDCA80D2C309C42958E5D983B9B58444B7BFC@chennaiexch4.synchen03.com> References: <0CDCA80D2C309C42958E5D983B9B58444B7BFC@chennaiexch4.synchen03.com> Message-ID: <20070226080311.3624.qmail@cdy.org> On Sat, Feb 24, 2007 at 08:43:05AM -0500, Raj, Sathidevi wrote: > Hello, Hi, > We are having the HPUX 11i as our OS platform. We are trying to > establish SSH connection in the same machine to the other user. > The idrsa.pub Please check the filename of your private key against what ssh(1) says is the default filename it will look for. Hint: It's not idrsa > is generated using ssh-keygen and the same is copied > to the remote user to the file authorized_keys. Also restarted the > server. > > Now when I issue the command, ssh loginname at ipaddress, the expected > result is it should not prompt for the password and connect to the > remote user. > Instead it is again prompting for the password. There are several possible problems. I made one suggestion about checking the filenames against the documentation to see if that's the problem. ssh and sshd also perform several checks for permissions and ownership of files and directories before they are used. Please verify that this is not the problem. One way to avoid these two problems (filename and permissions) at least on the client is to use ssh-agent and then ssh-add the private key to the agent before trying to connect to the server. Please see ssh-agent(1) for more information. ssh automatically tries to use keys that it finds in an ssh-agent running in the current session. > May I expect the response immediately? No. As you know all open source software comes with no warranty of any kind. Please take a minute to read the LICENCE file in the OpenSSH source distribution for full details. > Confidential: This electronic message and all contents contain > information from Syntel, Inc. which may be privileged, confidential > or otherwise protected from disclosure. Please don't send confidential messages to public mailing lists. Further, a notice such as this can not change the security of internet mail. If your company requires email security I suggest using encryption and electronic signatures rather than requests such as these. It's like writing "Plese don't read this" on a postcard. //Peter From ml at t-b-o-h.net Tue Feb 27 13:33:54 2007 From: ml at t-b-o-h.net (Tuc at T-B-O-H.NET) Date: Mon, 26 Feb 2007 21:33:54 -0500 (EST) Subject: What would cause keyboard-interactive packet connection close Message-ID: <200702270233.l1R2Xs4x033173@himinbjorg.tucs-beachin-obx-house.com> Hi, I've got a remote system that was down and came back up. I'm trying to get into the system, but when I do I get timed out. I forced it to a keyboard interactive to speed things up: ssh -o PreferredAuthentications=keyboard-interactive -vvv tuc at 10.2.0.2 but I get : debug1: waiting for SSH2_MSG_NEWKEYS debug1: newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: done: ssh_kex2. debug1: send SSH2_MSG_SERVICE_REQUEST debug1: service_accept: ssh-userauth debug1: got SSH2_MSG_SERVICE_ACCEPT debug1: authentications that can continue: publickey,keyboard-interactive debug3: start over, passed a different list publickey,keyboard-interactive debug3: preferred keyboard-interactive debug3: authmethod_lookup keyboard-interactive debug3: remaining preferred: debug3: authmethod_is_enabled keyboard-interactive debug1: next auth method to try is keyboard-interactive debug2: userauth_kbdint debug2: we sent a keyboard-interactive packet, wait for reply Connection closed by 10.2.0.2 debug1: Calling cleanup 0x804c158(0x0) What would make it close at that point? Thanks, Tuc From dtucker at zip.com.au Tue Feb 27 15:04:03 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 27 Feb 2007 15:04:03 +1100 Subject: What would cause keyboard-interactive packet connection close In-Reply-To: <200702270233.l1R2Xs4x033173@himinbjorg.tucs-beachin-obx-house.com> References: <200702270233.l1R2Xs4x033173@himinbjorg.tucs-beachin-obx-house.com> Message-ID: <45E3ADB3.8080008@zip.com.au> Tuc at T-B-O-H.NET wrote: > I've got a remote system that was down and came back up. I'm > trying to get into the system, but when I do I get timed out. I > forced it to a keyboard interactive to speed things up: > > ssh -o PreferredAuthentications=keyboard-interactive -vvv tuc at 10.2.0.2 [...] > debug2: we sent a keyboard-interactive packet, wait for reply > Connection closed by 10.2.0.2 > debug1: Calling cleanup 0x804c158(0x0) > > > What would make it close at that point? If the server is a Linux box with a somewhat dated glibc, possibly a bug in that: http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=111045930530623&w=2 Failing that, mentioning what kind of system the server is and what version of OpenSSH it's running is more likely to get some help. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From ml at t-b-o-h.net Wed Feb 28 01:38:42 2007 From: ml at t-b-o-h.net (Tuc at T-B-O-H.NET) Date: Tue, 27 Feb 2007 09:38:42 -0500 (EST) Subject: What would cause keyboard-interactive packet connection close In-Reply-To: <45E3ADB3.8080008@zip.com.au> Message-ID: <200702271438.l1REcgbK043047@himinbjorg.tucs-beachin-obx-house.com> > > Tuc at T-B-O-H.NET wrote: > > > I've got a remote system that was down and came back up. I'm > > trying to get into the system, but when I do I get timed out. I > > forced it to a keyboard interactive to speed things up: > > > > ssh -o PreferredAuthentications=keyboard-interactive -vvv tuc at 10.2.0.2 > [...] > > debug2: we sent a keyboard-interactive packet, wait for reply > > Connection closed by 10.2.0.2 > > debug1: Calling cleanup 0x804c158(0x0) > > > > > > What would make it close at that point? > > If the server is a Linux box with a somewhat dated glibc, possibly a bug > in that: > > http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=111045930530623&w=2 > > Failing that, mentioning what kind of system the server is and what > version of OpenSSH it's running is more likely to get some help. > FreeBSD 5.X (I don't remember off hand) and it identifies as : OpenSSH_3.5p1 FreeBSD-20030924, SSH protocols 1.5/2.0, OpenSSL 0x0090704f The server either locked up, crashed, or something and was unresponsive for quite some time. A power failure rebooted it and it seems to be running, running MRTG, Apache, and sendmail (Though, I haven't gotten its daily emails for some reason). I get SSH to answer and all the way to it sending the packet for keyboard interactive and then the connection closes. It *DOES* pause for a bit at debug1: service_accept: ssh-userauth debug1: got SSH2_MSG_SERVICE_ACCEPT before continuing..... Thanks, Tuc