From H.Koenig at science-computing.de Tue Aug 4 02:21:41 2009 From: H.Koenig at science-computing.de (Harald Koenig) Date: Mon, 3 Aug 2009 18:21:41 +0200 Subject: scp: wrong error message Message-ID: <20090803162141.GA9723@atuin.science-computing.de> Hi, I'm using scp from openssh-5.1p1 on opensuse 11.1. trying to copy a file to a nonexisting directory with scp gives the wrong error message: harald > scp /etc/passwd remote:nodir/ scp: nodir/: Is a directory harald > ssh remote ls -ld nodir ls: cannot access nodir: No such file or directory IMHO the error message should read e.g. "directory does not exist" and not "is a directory". Harald Koenig -- "I hope to die ___ _____ before I *have* to use Microsoft Word.", 0--,| /OOOOOOO\ Donald E. Knuth, 02-Oct-2001 in Tuebingen. <_/ / /OOOOOOOOOOO\ \ \/OOOOOOOOOOOOOOO\ \ OOOOOOOOOOOOOOOOO|// Harald Koenig \/\/\/\/\/\/\/\/\/ science+computing ag // / \\ \ koenig at science-computing.de ^^^^^ ^^^^^ -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Michel Lepert Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 From scott_n at xypro.com Tue Aug 4 03:16:16 2009 From: scott_n at xypro.com (Scott Neugroschl) Date: Mon, 3 Aug 2009 10:16:16 -0700 Subject: wrong error message In-Reply-To: <20090803162141.GA9723@atuin.science-computing.de> References: <20090803162141.GA9723@atuin.science-computing.de> Message-ID: <78DD71C304F38B41885A242996B96F7301E6FD2F@xyservd.XYPRO-23.LOCAL> > I'm using scp from openssh-5.1p1 on opensuse 11.1. > > trying to copy a file to a nonexisting directory with scp gives the > wrong error message: > > harald > scp /etc/passwd remote:nodir/ > scp: nodir/: Is a directory > > harald > ssh remote ls -ld nodir > ls: cannot access nodir: No such file or directory > > > IMHO the error message should read e.g. "directory does not exist" and > not "is a directory". > I suspect that the host is generating EISDIR (cygwin generates that for a local copy like that). As such, I wouldn't think it's wise for sshd to put special handling in there for this case. From H.Koenig at science-computing.de Tue Aug 4 03:51:13 2009 From: H.Koenig at science-computing.de (Harald Koenig) Date: Mon, 3 Aug 2009 19:51:13 +0200 Subject: wrong error message In-Reply-To: <78DD71C304F38B41885A242996B96F7301E6FD2F@xyservd.XYPRO-23.LOCAL> References: <20090803162141.GA9723@atuin.science-computing.de> <78DD71C304F38B41885A242996B96F7301E6FD2F@xyservd.XYPRO-23.LOCAL> Message-ID: <20090803175113.GA12012@atuin.science-computing.de> On Aug 03, Scott Neugroschl wrote: > I suspect that the host is generating EISDIR (cygwin generates that for > a local copy like that). > As such, I wouldn't think it's wise for sshd to put special handling in > there for this case. indeed, you're right: harald > cp /etc/passwd foo/ cp: cannot create regular file `foo/': Is a directory harald > strace -e open cp /etc/passwd foo/ [...] open("/etc/passwd", O_RDONLY) = 3 open("foo/", O_WRONLY|O_CREAT|O_EXCL, 0644) = -1 EISDIR (Is a directory) cp: cannot create regular file `foo/': Is a directory :-( Harald Koenig -- "I hope to die ___ _____ before I *have* to use Microsoft Word.", 0--,| /OOOOOOO\ Donald E. Knuth, 02-Oct-2001 in Tuebingen. <_/ / /OOOOOOOOOOO\ \ \/OOOOOOOOOOOOOOO\ \ OOOOOOOOOOOOOOOOO|// Harald Koenig \/\/\/\/\/\/\/\/\/ science+computing ag // / \\ \ koenig at science-computing.de ^^^^^ ^^^^^ -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Michel Lepert Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 From fv at linuxvar.it Tue Aug 4 22:11:33 2009 From: fv at linuxvar.it (Fernando Vezzosi) Date: Tue, 4 Aug 2009 14:11:33 +0200 Subject: [PATCH] Log ~/.ssh/authorized_keys comments when using LogLevel=VERBOSE Message-ID: <20090804121133.GA5707@lothlorien.passione> Hi, Attached is a patch to log key comments upon successful login. It just adds them to the already existing verbose() call. I find it useful e.g. on shared accounts where it's sometimes not enough to have the key fingerprint in the log file. Can this be applied? -- Fernando Vezzosi qw(MDAx MTAw MDEw MDEx MDAw _5 MTEw _6 _1 _5 _5 _4 _2 _2 _6 MTEx _1 _5 _5 _4 _5 _2 _6 _1 _1 _2 _2 _3 _5 _5 _6 _1 _1 _2 _5 _4 _3 _5 _2 _5 _1 _2 _3 _4 _5 MA==) -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenSSH_log_key_comment.diff Type: text/x-diff Size: 1384 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From techohead at hotmail.com Thu Aug 6 01:43:01 2009 From: techohead at hotmail.com (Toby Ireland) Date: Thu, 6 Aug 2009 02:13:01 +1030 Subject: Strontium Nitrate Message-ID: Hello, my name is Toby, and i live in Sydney Australia. i would like to buy a 25Kg bag of strontium nitrate and have it delivered to an address in sydney. i understand that long distance postage can sometimes be very costly, so can you please give a a quote for the 25Kg bag, plus the postage cost to my address in sydney. thankyou for your time _________________________________________________________________ What goes online, stays online Check the daily blob for the latest on what's happening around the web http://windowslive.ninemsn.com.au/blog.aspx From dirTdogE at Gmail.com Sun Aug 9 12:31:00 2009 From: dirTdogE at Gmail.com (dawg) Date: Sat, 08 Aug 2009 22:31:00 -0400 Subject: Feature request for SSH FTP Message-ID: <4A7E34E4.60806@Gmail.com> While uploading a file via SFTP, the file which is being overwritten is done so in real-time rather than waiting until the transfer has finished. In other words, if it takes you 60 seconds to upload the new file, the old file is unusable for a period of 60 seconds. This is a major problem if the file you are overwriting, for example, is a server script which is accessed hundreds or thousands of times per minute. Of course, it's an even bigger problem if the connection is interrupted mid-transfer. I suggest that files transferred via SSH should be saved to a temp folder until the transfer is complete, then only would the original file be overwritten. From dkg at fifthhorseman.net Sun Aug 9 13:17:41 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 08 Aug 2009 23:17:41 -0400 Subject: Feature request for SSH FTP In-Reply-To: <4A7E34E4.60806@Gmail.com> References: <4A7E34E4.60806@Gmail.com> Message-ID: <4A7E3FD5.10002@fifthhorseman.net> On 08/08/2009 10:31 PM, dawg wrote: > I suggest that files transferred via SSH should be saved to a temp > folder until the transfer is complete, then only would the original file > be overwritten. I believe this is already possible with sftp: put important-file important-file.XXXX rename important-file.XXXX important-file Would this workflow solve your problem? The only primitive i see missing for a complete/robust implementation would be a mktemp equivalent as an sftp primitive (to avoid collisions in the choice of temporary filenames), but that seems like a very different feature request. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature URL: From dirTdogE at Gmail.com Sun Aug 9 13:46:40 2009 From: dirTdogE at Gmail.com (dawg) Date: Sat, 08 Aug 2009 23:46:40 -0400 Subject: Feature request for SSH FTP In-Reply-To: <4A7E3FD5.10002@fifthhorseman.net> References: <4A7E34E4.60806@Gmail.com> <4A7E3FD5.10002@fifthhorseman.net> Message-ID: <4A7E46A0.10900@Gmail.com> I suppose that is true -- I don't know the specifics since I do not use SFTP via command line but rather via an SFTP client, FileZilla, in my particular case. I had actually earlier tonight suggested the functionality you noted below as a workaround (on the client end) to what I believed would be optimally solved automatically on the server side. Do you disagree that the best possible implementation should solve the problem automatically on the server side? In my mind, this seems half way between a feature request and a bug report. Regards, Nate On 08/08/2009 11:17 PM, Daniel Kahn Gillmor wrote: > On 08/08/2009 10:31 PM, dawg wrote: > >> I suggest that files transferred via SSH should be saved to a temp >> folder until the transfer is complete, then only would the original file >> be overwritten. >> > > I believe this is already possible with sftp: > > put important-file important-file.XXXX > rename important-file.XXXX important-file > > Would this workflow solve your problem? > > The only primitive i see missing for a complete/robust implementation > would be a mktemp equivalent as an sftp primitive (to avoid collisions > in the choice of temporary filenames), but that seems like a very > different feature request. > > --dkg > > From mouring at eviladmin.org Sun Aug 9 14:57:11 2009 From: mouring at eviladmin.org (Ben Lindstrom) Date: Sat, 8 Aug 2009 23:57:11 -0500 Subject: Feature request for SSH FTP In-Reply-To: <4A7E46A0.10900@Gmail.com> References: <4A7E34E4.60806@Gmail.com> <4A7E3FD5.10002@fifthhorseman.net> <4A7E46A0.10900@Gmail.com> Message-ID: <9442F117-4082-46CB-AE2C-F633ACBE5824@eviladmin.org> On Aug 8, 2009, at 10:46 PM, dawg wrote: > I suppose that is true -- I don't know the specifics since I do not > use SFTP via command line but rather via an SFTP client, FileZilla, > in my particular case. I had actually earlier tonight suggested the > functionality you noted below as a workaround (on the client end) to > what I believed would be optimally solved automatically on the > server side. Do you disagree that the best possible implementation > should solve the problem automatically on the server side? I very much disagree. Making "put" hold two copies of a file by default would cause people transferring large files to have failures. > In my mind, this seems half way between a feature request and a bug > report. It isn't a bug. There is no defect to report. You are requesting a new feature. And I can see making a request for a mktemp(3) feature. However, this would be specialized to OpenSSH's servers, and FileZilla may prefer a more universal feature set. This is definitely a client-side problem and not a server side. - Ben From peter at stuge.se Sun Aug 9 18:46:51 2009 From: peter at stuge.se (Peter Stuge) Date: Sun, 9 Aug 2009 10:46:51 +0200 Subject: Feature request for SSH FTP In-Reply-To: <4A7E34E4.60806@Gmail.com> References: <4A7E34E4.60806@Gmail.com> Message-ID: <20090809084651.2026.qmail@stuge.se> dawg wrote: > This is a major problem if the file you are overwriting, for > example, is a server script which is accessed hundreds or thousands > of times per minute. I would suggest that you investigate a more robust routine than using SFTP for updating your production services. You want to find an atomic system feature which allows you to switch between two files, or two sets of files. I suggest that you look into the application server (httpd if this is a web server) for this. With Apache, one way would be: Create new site folder Upload new contents Change virtualhost configuration to point to new site folder apachectl graceful # will not abort any current connections If you do not have permission to do this on your current server, either look for another server, look at other alternatives (rsync can do what you request, and can run over ssh) or simply use the suggested workaround of manually renaming the file two times. Maybe you can even script some SFTP clients to do it automatically. //Peter From dirTdogE at Gmail.com Mon Aug 10 00:27:11 2009 From: dirTdogE at Gmail.com (dawg) Date: Sun, 09 Aug 2009 10:27:11 -0400 Subject: Feature request for SSH FTP In-Reply-To: <4A7ED8FF.60207@Gmail.com> References: <4A7E34E4.60806@Gmail.com> <4A7E3FD5.10002@fifthhorseman.net> <4A7E46A0.10900@Gmail.com> <9442F117-4082-46CB-AE2C-F633ACBE5824@eviladmin.org> <4A7ED8FF.60207@Gmail.com> Message-ID: <4A7EDCBF.4080302@Gmail.com> Actually, the sshd could check whether there is enough disk space while uploading the files and make the choice automatically. On 08/09/2009 10:11 AM, dawg wrote: > On 08/09/2009 12:57 AM, Ben Lindstrom wrote: >> >> I very much disagree. Making "put" hold two copies of a file by >> default would cause people transferring large files to have failures. > That's ridiculous. The one in a million case versus the 999,999 in a > million cases? Disk space is rarely an issue that would affect this. > It could be made an option to be toggled via config in any case. >> >> It isn't a bug. There is no defect to report. You are requesting a >> new feature. And I can see making a request for a mktemp(3) >> feature. However, this would be specialized to OpenSSH's servers, >> and FileZilla may prefer a more universal feature set. > Sure it is. The current implementation corrupts the existing file for > a period of time. > > Anyway, I will waste no more breath on this. Thanks for taking the > time to reply. >> >> This is definitely a client-side problem and not a server side. >> >> - Ben >> From dirTdogE at Gmail.com Mon Aug 10 01:41:34 2009 From: dirTdogE at Gmail.com (dawg) Date: Sun, 09 Aug 2009 11:41:34 -0400 Subject: Feature request for SSH FTP In-Reply-To: <597e7edb0908090802j1b971183h327904d418484fa9@mail.gmail.com> References: <4A7E34E4.60806@Gmail.com> <4A7E3FD5.10002@fifthhorseman.net> <4A7E46A0.10900@Gmail.com> <9442F117-4082-46CB-AE2C-F633ACBE5824@eviladmin.org> <4A7ED8FF.60207@Gmail.com> <4A7EDCBF.4080302@Gmail.com> <597e7edb0908090802j1b971183h327904d418484fa9@mail.gmail.com> Message-ID: <4A7EEE2E.8040800@Gmail.com> On 08/09/2009 11:02 AM, Hamish Allan wrote: >> Actually, the sshd could check whether there is enough disk space while >> uploading the files and make the choice automatically. >> > > As could the client. > ..Or the user could manually check and calculate this all himself for every transfer. That doesn't mean that's the best solution or the only one which could be applied. There is also the practicality matter of communicating to every client developer versus fixing the problem on the server end, the end which is the source of the (perhaps unexpected (and definitely sub-optimal)) behavior. It doesn't matter how you intend the software to be used, it matters how it is used and how the end user or developer expects it to behave. The bottom line is that you can ensure quality by addressing the issue, or you can blame the rest of the world for not reading either your mind or the documentation, whichever happens to be applicable, and allow the end user to suffer the consequences, whether they are aware of those consequences or not. >> That's ridiculous. The one in a million case versus the 999,999 in a >> million cases? Disk space is rarely an issue that would affect this. It >> could be made an option to be toggled via config in any case. >> > > Disk space may be rarely an issue for you, but get some perspective. > You are only one user; what about the other 999,999? > > >> Sure it is. The current implementation corrupts the existing file for a >> period of time. >> > > Which is what the client asks it to do. If the client wants something > else to happen, why not just ask for it? > Ah, yes, the infamous 'corrupt file' command. Give me a break. From peter at stuge.se Mon Aug 10 01:59:48 2009 From: peter at stuge.se (Peter Stuge) Date: Sun, 9 Aug 2009 17:59:48 +0200 Subject: Feature request for SSH FTP In-Reply-To: <4A7EEE2E.8040800@Gmail.com> References: <4A7E34E4.60806@Gmail.com> <4A7E3FD5.10002@fifthhorseman.net> <4A7E46A0.10900@Gmail.com> <9442F117-4082-46CB-AE2C-F633ACBE5824@eviladmin.org> <4A7ED8FF.60207@Gmail.com> <4A7EDCBF.4080302@Gmail.com> <597e7edb0908090802j1b971183h327904d418484fa9@mail.gmail.com> <4A7EEE2E.8040800@Gmail.com> Message-ID: <20090809155948.3637.qmail@stuge.se> dawg wrote: >>> Sure it is. The current implementation corrupts the existing file >>> for a period of time. > > Ah, yes, the infamous 'corrupt file' command. Give me a break. Please understand that none of FTP, SFTP, UNIX cp, mv, scp, tar and almost every other utility does not provide atomic file level updates - and this is by design! If you need atomic updates, YOU have to create them. There are vendors and applications that do it for you. Please use them, instead of criticizing tools that were explicitly not designed to support your use case. //Peter From peter at stuge.se Mon Aug 10 02:01:52 2009 From: peter at stuge.se (Peter Stuge) Date: Sun, 9 Aug 2009 18:01:52 +0200 Subject: Feature request for SSH FTP In-Reply-To: <20090809155948.3637.qmail@stuge.se> References: <4A7E34E4.60806@Gmail.com> <4A7E3FD5.10002@fifthhorseman.net> <4A7E46A0.10900@Gmail.com> <9442F117-4082-46CB-AE2C-F633ACBE5824@eviladmin.org> <4A7ED8FF.60207@Gmail.com> <4A7EDCBF.4080302@Gmail.com> <597e7edb0908090802j1b971183h327904d418484fa9@mail.gmail.com> <4A7EEE2E.8040800@Gmail.com> <20090809155948.3637.qmail@stuge.se> Message-ID: <20090809160152.4105.qmail@stuge.se> Peter Stuge wrote: > > Ah, yes, the infamous 'corrupt file' command. Give me a break. > > Please understand that none of FTP, SFTP, UNIX cp, mv, scp, tar and > almost every other utility does not provide atomic file level updates > - and this is by design! My english is not great today :) but I hope you get the point anyway. //Peter From luis.mgarc at gmail.com Mon Aug 10 02:20:29 2009 From: luis.mgarc at gmail.com (Luis M.) Date: Sun, 09 Aug 2009 17:20:29 +0100 Subject: Feature request for SSH FTP In-Reply-To: <4A7EEE2E.8040800@Gmail.com> References: <4A7E34E4.60806@Gmail.com> <4A7E3FD5.10002@fifthhorseman.net> <4A7E46A0.10900@Gmail.com> <9442F117-4082-46CB-AE2C-F633ACBE5824@eviladmin.org> <4A7ED8FF.60207@Gmail.com> <4A7EDCBF.4080302@Gmail.com> <597e7edb0908090802j1b971183h327904d418484fa9@mail.gmail.com> <4A7EEE2E.8040800@Gmail.com> Message-ID: <4A7EF74D.4030408@gmail.com> dawg wrote: > >>> Sure it is. The current implementation corrupts the existing file for a >>> period of time. >>> >> Well, I totally agree with Dawg here. I think SFTP should provide a native atomic file upload operation. Maybe we shouldn't "overwrite" the traditional "put" behaviour but It would certainly be great to have something like "safeput" that lets users upload a file and only when the file has been transferred correctly, replace the old version with the new one. It may not strictly be a bug but I think it is a very reasonable and nice feature that would be nice to have. Luis. From hamish at gmail.com Mon Aug 10 01:02:04 2009 From: hamish at gmail.com (Hamish Allan) Date: Sun, 9 Aug 2009 16:02:04 +0100 Subject: Feature request for SSH FTP In-Reply-To: <4A7EDCBF.4080302@Gmail.com> References: <4A7E34E4.60806@Gmail.com> <4A7E3FD5.10002@fifthhorseman.net> <4A7E46A0.10900@Gmail.com> <9442F117-4082-46CB-AE2C-F633ACBE5824@eviladmin.org> <4A7ED8FF.60207@Gmail.com> <4A7EDCBF.4080302@Gmail.com> Message-ID: <597e7edb0908090802j1b971183h327904d418484fa9@mail.gmail.com> On Sun, Aug 9, 2009 at 3:27 PM, dawg wrote: > Actually, the sshd could check whether there is enough disk space while > uploading the files and make the choice automatically. As could the client. > That's ridiculous. The one in a million case versus the 999,999 in a > million cases? Disk space is rarely an issue that would affect this. It > could be made an option to be toggled via config in any case. Disk space may be rarely an issue for you, but get some perspective. You are only one user; what about the other 999,999? > Sure it is. The current implementation corrupts the existing file for a > period of time. Which is what the client asks it to do. If the client wants something else to happen, why not just ask for it? H From hamish at gmail.com Mon Aug 10 02:34:53 2009 From: hamish at gmail.com (Hamish Allan) Date: Sun, 9 Aug 2009 17:34:53 +0100 Subject: Feature request for SSH FTP In-Reply-To: <4A7EF74D.4030408@gmail.com> References: <4A7E34E4.60806@Gmail.com> <4A7E3FD5.10002@fifthhorseman.net> <4A7E46A0.10900@Gmail.com> <9442F117-4082-46CB-AE2C-F633ACBE5824@eviladmin.org> <4A7ED8FF.60207@Gmail.com> <4A7EDCBF.4080302@Gmail.com> <597e7edb0908090802j1b971183h327904d418484fa9@mail.gmail.com> <4A7EEE2E.8040800@Gmail.com> <4A7EF74D.4030408@gmail.com> Message-ID: <597e7edb0908090934k5371279ew5d5b16f08576ad5b@mail.gmail.com> On Sun, Aug 9, 2009 at 5:20 PM, Luis M. wrote: > Well, I totally agree with Dawg here. I think SFTP should provide a > native atomic file upload operation. Apparently, it already does (SSH_FXF_RENAME_ATOMIC). Hamish From luis.mgarc at gmail.com Mon Aug 10 02:57:06 2009 From: luis.mgarc at gmail.com (Luis M.) Date: Sun, 09 Aug 2009 17:57:06 +0100 Subject: Feature request for SSH FTP In-Reply-To: <597e7edb0908090934k5371279ew5d5b16f08576ad5b@mail.gmail.com> References: <4A7E34E4.60806@Gmail.com> <4A7E3FD5.10002@fifthhorseman.net> <4A7E46A0.10900@Gmail.com> <9442F117-4082-46CB-AE2C-F633ACBE5824@eviladmin.org> <4A7ED8FF.60207@Gmail.com> <4A7EDCBF.4080302@Gmail.com> <597e7edb0908090802j1b971183h327904d418484fa9@mail.gmail.com> <4A7EEE2E.8040800@Gmail.com> <4A7EF74D.4030408@gmail.com> <597e7edb0908090934k5371279ew5d5b16f08576ad5b@mail.gmail.com> Message-ID: <4A7EFFE2.7080201@gmail.com> Hamish Allan wrote: > On Sun, Aug 9, 2009 at 5:20 PM, Luis M. wrote: > > >> Well, I totally agree with Dawg here. I think SFTP should provide a >> native atomic file upload operation. >> > > Apparently, it already does (SSH_FXF_RENAME_ATOMIC). > > Hamish > > Correct me if I'm wrong but an atomic rename operation is not the same as an atomic file upload operation, is it? Luis. From jamie.beverly at yahoo.com Mon Aug 10 02:00:28 2009 From: jamie.beverly at yahoo.com (Jamie Beverly) Date: Sun, 9 Aug 2009 09:00:28 -0700 (PDT) Subject: Feature request for SSH FTP Message-ID: <555585.11244.qm@web31809.mail.mud.yahoo.com> It doesn't matter how you intend the software to be used, it matters how it is used and how the end user or developer expects it to behave. I couldn't be bothered with reading the documentation, and hence, I expect the software to give me a pony... However, and much to my dismay, I have transfered several thousand files, and still no pony!!! This is clearly a bug! From hamish at gmail.com Mon Aug 10 05:15:17 2009 From: hamish at gmail.com (Hamish Allan) Date: Sun, 9 Aug 2009 20:15:17 +0100 Subject: Feature request for SSH FTP In-Reply-To: <4A7EFFE2.7080201@gmail.com> References: <4A7E34E4.60806@Gmail.com> <4A7E46A0.10900@Gmail.com> <9442F117-4082-46CB-AE2C-F633ACBE5824@eviladmin.org> <4A7ED8FF.60207@Gmail.com> <4A7EDCBF.4080302@Gmail.com> <597e7edb0908090802j1b971183h327904d418484fa9@mail.gmail.com> <4A7EEE2E.8040800@Gmail.com> <4A7EF74D.4030408@gmail.com> <597e7edb0908090934k5371279ew5d5b16f08576ad5b@mail.gmail.com> <4A7EFFE2.7080201@gmail.com> Message-ID: <597e7edb0908091215k70b9f972l59f6b46dda45f22e@mail.gmail.com> On Sun, Aug 9, 2009 at 5:57 PM, Luis M. wrote: > Correct me if I'm wrong but an atomic rename operation is not the same > as an atomic file upload operation, is it? Ah, sorry, no. It would probably be useful in implementing atomic file upload, though. I did just think of something which would be difficult to achieve by implementing this client-side: removal of the temporary file if the connection is lost. Also, perhaps some people have SFTP setups in which users have write-only permissions? Hamish From djm at mindrot.org Mon Aug 10 10:52:31 2009 From: djm at mindrot.org (Damien Miller) Date: Mon, 10 Aug 2009 10:52:31 +1000 (EST) Subject: Feature request for SSH FTP In-Reply-To: <4A7EFFE2.7080201@gmail.com> References: <4A7E34E4.60806@Gmail.com> <4A7E3FD5.10002@fifthhorseman.net> <4A7E46A0.10900@Gmail.com> <9442F117-4082-46CB-AE2C-F633ACBE5824@eviladmin.org> <4A7ED8FF.60207@Gmail.com> <4A7EDCBF.4080302@Gmail.com> <597e7edb0908090802j1b971183h327904d418484fa9@mail.gmail.com> <4A7EEE2E.8040800@Gmail.com> <4A7EF74D.4030408@gmail.com> <597e7edb0908090934k5371279ew5d5b16f08576ad5b@mail.gmail.com> <4A7EFFE2.7080201@gmail.com> Message-ID: On Sun, 9 Aug 2009, Luis M. wrote: > Correct me if I'm wrong but an atomic rename operation is not the same > as an atomic file upload operation, is it? The sftp server and protocol don't provide any upload operation at all. They provide very basic block operations that the client uses to upload files. If you want atomic file upload, then you should start by asking the author of your client. OpenSSH can implement it only for our sftp client, which I suspect many people aren't using. -d From cus at fazekas.hu Tue Aug 11 23:43:19 2009 From: cus at fazekas.hu (Marton Balint) Date: Tue, 11 Aug 2009 15:43:19 +0200 (CEST) Subject: [PATCH][RESEND] UTF8 and sftp-server Message-ID: Hi, Currently the openssh sftp-server only supports sftp protocol version 3, and unless I am mistaken there are no plans to support newer versions of this protocol. The encoding of the filenames for this protocol version is unspecified, so there is no reliable way for an sftp client to detect the encoding of the filenames. To solve this problem, I am proposing here a new sftp extension to allow the sftp server to give a hint to the clients whether or not they should interpret the filenames as utf-8. I tried to keep the patch as simple as possible (introduced a new command line parameter to sftp-server, when specified, the server would send this extension) I also made contact with Martin Prikryl, the developer of WinSCP, he wrote that if the extension got in to openSSH, he would be happy to add support for it: http://winscp.net/forum/viewtopic.php?t=7108 Regards, Marton -------------- next part -------------- A non-text attachment was scrubbed... Name: openssh-utf8.patch Type: text/x-patch Size: 2078 bytes Desc: URL: From ghudson at MIT.EDU Wed Aug 12 05:51:38 2009 From: ghudson at MIT.EDU (ghudson at MIT.EDU) Date: Tue, 11 Aug 2009 15:51:38 -0400 (EDT) Subject: Another request for gss-keyex inclusion Message-ID: <200908111951.n7BJpcTM027904@outgoing.mit.edu> I would like to request additional consideration for inclusion of the gss-keyex patch (https://bugzilla.mindrot.org/show_bug.cgi?id=1242) into mainline OpenSSH. I know this comes up every few months, and I know that the current answer is "no" (as stated in November 2007), so I'll get straight to the new information and possibly-new arguments. 1. I conducted a careful, line-by-line audit of the gss-keyex patch, looking carefully at cases of pointer arithmetic, array operations, integer arithmetic which could overflow, interactions between GSSAPI support and the privsep architecture, anything which could lead to improper authorization based on what happens during keyex, failures to check return codes, and consistency between gss-keyex and the other DH keyex implementations. I didn't find anything exploitable. I did find some minor issues which Simon has corrected in the latest version of the patch. With those corrections, I believe the patch to be very solidly written and to carry minimal risk beyond what is already present in the userauth code. 2. The risk from the additional code is borne pretty much exclusively by hosts whose administrators have consciously chosen to place their security in the care of a GSSAPI implementation. Any relevant security holes in the GSSAPI library implementation are likely to be exploitable by other paths--the existing userauth code, other GSSAPI-enabled daemons, the system's PAM code, etc.. 3. The risk of *not* having this functionality in a large GSSAPI-using environment is that key exchange is, in most scenarios, vulnerable to a man-in-the-middle attack. This is because there are usually too many hosts to manually manage the known-hosts files, and because hosts are re-keyed often enough that any DH signature failure will typically be chalked up to a reinstall. 4. I'm aware of OS packaging deployments of the patch in OSX, Solaris, and Debian/Ubuntu, and site deployments of the patch at Google, Stanford, MIT, Sun, Apple, NASA JPL, and DoD HPC. I don't think that necessarily speaks to the code-level security of the patch, but it does speak to its protocol-level desirability. We collected some testimony from some of the above sites; here's a snippet from Google which typifies what is attractive about gss-keyex support to the people who deploy it: > We have an extraordinarily dynamic environment which makes this patch > particularly useful. It's so dynamic in fact that we have a script to > make removing host keys from ~/.ssh/known_hosts easy and the default > response to a host key mismatch was to remove the keys from your > known_hosts (yes, this is horrible from a security point of view, but > security just got in the way of usability too often due to the nature > of the environment and given the likelihood of the key being replaced > was high and the likelihood of it being compromised was low, it was a > fair trade off at the time). As such, this patch provides a > significant improvement in security for us (and is likely to do so for > anyone who has a GSS-API based infrastructure). Thank you for your consideration. Regardless of your conclusion, thank you very much for your work on an excellent tool which I use every day. Greg Hudson MIT Kerberos Consortium From adrya1984 at gmail.com Thu Aug 13 02:23:30 2009 From: adrya1984 at gmail.com (Adriana Rodean) Date: Wed, 12 Aug 2009 19:23:30 +0300 Subject: Restrict a client port-forward to 1 port Message-ID: <496c8fcc0908120923p77cbb70di3d0d1055076ccda0@mail.gmail.com> Hi, Is it possible to restrict a client port-forwarding to one port? For example i want client X to open only port 1037 on server through port-forwarding, client Y only port 1038 and so on... How can this be possible? I use private/public keys authentication. Client version is openssh3.8p1, is windows client, and server version is latest openssh on a linux machine. Can anyone help please? Thank you so much, Adriana From joseph85750 at yahoo.com Thu Aug 13 04:58:49 2009 From: joseph85750 at yahoo.com (Joseph Spenner) Date: Wed, 12 Aug 2009 11:58:49 -0700 (PDT) Subject: Restrict a client port-forward to 1 port In-Reply-To: <496c8fcc0908120923p77cbb70di3d0d1055076ccda0@mail.gmail.com> Message-ID: <47056.25263.qm@web30304.mail.mud.yahoo.com> --- On Wed, 8/12/09, Adriana Rodean wrote: > Hi, > > Is it possible to restrict a client port-forwarding to one > port? Yes, but you must force key authentication. Then, in the authorized keys, the 2 entries should look like this: permitopen="10.16.0.211:1037" ssh-dss AAAAB3NzaC1k...hyHN/a7BHblrelqwejrjqw..first.client.key...etc..elrjwerwer permitopen="10.16.0.211:1038" ssh-dss weafasdfds..second.client.key..werwerewerwe....etc.. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From mouring at eviladmin.org Thu Aug 13 07:27:20 2009 From: mouring at eviladmin.org (Ben Lindstrom) Date: Wed, 12 Aug 2009 16:27:20 -0500 Subject: Restrict a client port-forward to 1 port In-Reply-To: <496c8fcc0908120923p77cbb70di3d0d1055076ccda0@mail.gmail.com> References: <496c8fcc0908120923p77cbb70di3d0d1055076ccda0@mail.gmail.com> Message-ID: <8274A536-DB75-4E68-B9C0-0918B1617411@eviladmin.org> You can use a "Match" rule and limit the ports by using "PermitOpen". However this is per-user and not per machine/ location. So it depends on what you want. - Ben On Aug 12, 2009, at 11:23 AM, Adriana Rodean wrote: > Hi, > > Is it possible to restrict a client port-forwarding to one port? > For example i want client X to open only port 1037 on server through > port-forwarding, client Y only port 1038 and so on... > How can this be possible? > I use private/public keys authentication. > Client version is openssh3.8p1, is windows client, and server version > is latest openssh on a linux machine. > > Can anyone help please? > > Thank you so much, > Adriana > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From adrya1984 at gmail.com Thu Aug 13 17:06:42 2009 From: adrya1984 at gmail.com (Adriana Rodean) Date: Thu, 13 Aug 2009 10:06:42 +0300 Subject: Restrict a client port-forward to 1 port In-Reply-To: <8274A536-DB75-4E68-B9C0-0918B1617411@eviladmin.org> References: <496c8fcc0908120923p77cbb70di3d0d1055076ccda0@mail.gmail.com> <8274A536-DB75-4E68-B9C0-0918B1617411@eviladmin.org> Message-ID: <496c8fcc0908130006g85b18fep987eca7a06c3d752@mail.gmail.com> Hi again, Maybe i didn't expressed myself right. I want client X to be able to connect with this command: ssh -L 30300:localhost:8080 -R 1037:localhost:55555 Client Y to be able to connect with: ssh -L 30300:localhost:8080 -R 1038:localhost:55555 and so on but client Y should be forbidden to connect with: ssh -L 30300:localhost:8080 -R 1037:localhost:55555 On the server sshd_config file i already have PermitOpen 8080 so from the client side only 8080 is accesible on server. Thank you again, Sorry for the confusion Adriana From joseph85750 at yahoo.com Fri Aug 14 05:00:13 2009 From: joseph85750 at yahoo.com (Joseph Spenner) Date: Thu, 13 Aug 2009 12:00:13 -0700 (PDT) Subject: Restrict a client port-forward to 1 port In-Reply-To: <496c8fcc0908130006g85b18fep987eca7a06c3d752@mail.gmail.com> Message-ID: <222327.59683.qm@web30307.mail.mud.yahoo.com> --- On Thu, 8/13/09, Adriana Rodean wrote: > Hi again, > > Maybe i didn't expressed myself right. > I want client X to be able to connect with this command: > ssh -L > 30300:localhost:8080 -R 1037:localhost:55555 > Client Y to be able to connect with: ssh -L > 30300:localhost:8080 -R > 1038:localhost:55555 > and so on > but client Y should be forbidden to connect with:? ssh > -L > 30300:localhost:8080 -R 1037:localhost:55555 From what I can tell, your goal is to restrict certain REMOTE port forward values. I do not think it is possible to place restrictions on REMOTE port forwards if port forwarding is enabled in sshd_config. In the authorized_keys, you can list 'permitopen' options, but this only applies to LOCAL port forwards. From adrya1984 at gmail.com Fri Aug 14 16:09:31 2009 From: adrya1984 at gmail.com (Adriana Rodean) Date: Fri, 14 Aug 2009 09:09:31 +0300 Subject: Restrict a client port-forward to 1 port In-Reply-To: <222327.59683.qm@web30307.mail.mud.yahoo.com> References: <496c8fcc0908130006g85b18fep987eca7a06c3d752@mail.gmail.com> <222327.59683.qm@web30307.mail.mud.yahoo.com> Message-ID: <496c8fcc0908132309u466c07aam4abed073809cdc7@mail.gmail.com> Hi, Thank you so much for the reply :) Yes that's exactly what i want, restrict certain REMOTE port forward values. If client X has remote port 1037 on the server then client Y should be forbidden to do remote port-forwarding on port 1037 if client X is not connected. Can't it be restricted somehow with iptables or with some Linux commands? If ssh can't i'm thinking maybe Linux can... I mean restrict only client X (which is behind a certain ip address) to listen to port 1037 on the server. I'm not Linux user, and have minimal knowledge about Linux, but maybe someone knows... Thank you again, Adriana On Thu, Aug 13, 2009 at 22:00, Joseph Spenner wrote: > --- On Thu, 8/13/09, Adriana Rodean wrote: > >> Hi again, >> >> Maybe i didn't expressed myself right. >> I want client X to be able to connect with this command: >> ssh -L >> 30300:localhost:8080 -R 1037:localhost:55555 >> Client Y to be able to connect with: ssh -L >> 30300:localhost:8080 -R >> 1038:localhost:55555 >> and so on >> but client Y should be forbidden to connect with:? ssh >> -L >> 30300:localhost:8080 -R 1037:localhost:55555 > > From what I can tell, your goal is to restrict certain REMOTE port forward values. ?I do not think it is possible to place restrictions on REMOTE port forwards if port forwarding is enabled in sshd_config. ?In the authorized_keys, you can list 'permitopen' options, but this only applies to LOCAL port forwards. > > > > > From sf.rique at gmail.com Sat Aug 15 03:31:14 2009 From: sf.rique at gmail.com (Henrique Fernandes) Date: Fri, 14 Aug 2009 14:31:14 -0300 Subject: About sftp chroot dev! Message-ID: I have an question, why you guys do not let chroot be owned by the user ? It would be a good way to chroot the users Cause like I want to chroot user in /chroot/%u But they can not write in this directory... i need to set another dir to them to be able to write, even when /chroot/ is onewd by root i want to be able to do this user1 be able to write in /chroot/user1 but not able to go down into /chroot/ user2 same thing here. In that way, user1 will not be able even know if there is other files there... But with your code i have to do this set chroot dir to /chroot/ and set home in /etc/passwd to /user1 But when uer 1 logs in he see /user1 and if he gos down with cd .. he is hable to see user2 and move around Is there anyway to do what i want ? And can you guys explain to me why the chroot path HAS to be owned by root ? Sorry , i know i am beeing annoying And Thanks anyway! -- []'sf.rique From djm at mindrot.org Sat Aug 15 06:48:47 2009 From: djm at mindrot.org (Damien Miller) Date: Sat, 15 Aug 2009 06:48:47 +1000 (EST) Subject: About sftp chroot dev! In-Reply-To: References: Message-ID: On Fri, 14 Aug 2009, Henrique Fernandes wrote: > I have an question, why you guys do not let chroot be owned by the user ? This has been discussed several times on this mailing list, please check the archives. -d From robert at openbsd.pap.st Sat Aug 15 04:51:52 2009 From: robert at openbsd.pap.st (Robert) Date: Fri, 14 Aug 2009 20:51:52 +0200 Subject: About sftp chroot dev! In-Reply-To: References: Message-ID: <20090814205152.39f26af7@openbsd.pap.st> On Fri, 14 Aug 2009 14:31:14 -0300 Henrique Fernandes wrote: > I have an question, why you guys do not let chroot be owned by the > user ? > > > It would be a good way to chroot the users > > Cause like > > I want to chroot user in /chroot/%u > > But they can not write in this directory... i need to set another dir > to them to be able to write, even when /chroot/ is onewd by root > > i want to be able to do this > > user1 be able to write in /chroot/user1 but not able to go down > into /chroot/ > user2 same thing here. > > In that way, user1 will not be able even know if there is other files > there... > > But with your code i have to do this > > set chroot dir to /chroot/ and set home in /etc/passwd to /user1 > > But when uer 1 logs in he see /user1 and if he gos down with > cd .. he is hable to see user2 and move around > > Is there anyway to do what i want ? > > And can you guys explain to me why the chroot path HAS to be owned by > root ? > > Sorry , i know i am beeing annoying > > And Thanks anyway! > > -- > []'sf.rique > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev Why? Because of security reasons. You might want to check the archives for this and the "general" mailinglist. This topic as been discussed quite a lot. If i remember correctly, also patches have been posted to get the behaviour you'd like. - Robert From sf.rique at gmail.com Sat Aug 15 17:05:12 2009 From: sf.rique at gmail.com (Henrique Fernandes) Date: Sat, 15 Aug 2009 04:05:12 -0300 Subject: About sftp chroot dev! In-Reply-To: References: Message-ID: thanks to all i have looked but i did not find anypatches.. i will look again... and i did not find why is dangers.. they just say.. it is dangers... But Thanks anyway! if anyone knows the patche please let me know! On Fri, Aug 14, 2009 at 5:48 PM, Damien Miller wrote: > On Fri, 14 Aug 2009, Henrique Fernandes wrote: > > > I have an question, why you guys do not let chroot be owned by the user ? > > This has been discussed several times on this mailing list, please check > the archives. > > -d > -- []'sf.rique From joseph85750 at yahoo.com Sun Aug 16 03:44:08 2009 From: joseph85750 at yahoo.com (Joseph Spenner) Date: Sat, 15 Aug 2009 10:44:08 -0700 (PDT) Subject: Restrict a client port-forward to 1 port In-Reply-To: <496c8fcc0908132309u466c07aam4abed073809cdc7@mail.gmail.com> Message-ID: <868639.71220.qm@web30302.mail.mud.yahoo.com> --- On Fri, 8/14/09, Adriana Rodean wrote: > >On Thu, Aug 13, 2009 at 22:00, Joseph Spenner > > wrote: > > From what I can tell, your goal is to restrict certain > > REMOTE port forward values. I do not think it is possible > > to place restrictions on REMOTE port forwards if port > > forwarding is enabled in sshd_config. In the > > authorized_keys, you can list 'permitopen' options, but this > > only applies to LOCAL port forwards. > > Yes that's exactly what i want, restrict certain REMOTE > port forward values. > If client X has remote port 1037 on the server then client > Y should be > forbidden to do remote port-forwarding on port 1037 if > client X is not > connected. > Can't it be restricted somehow with iptables or with some > Linux commands? > If ssh can't i'm thinking maybe Linux can... > I mean restrict only client X (which is behind a certain ip > address) > to listen to port 1037 on the server. > > I'm not Linux user, and have minimal knowledge about Linux, > but maybe > someone knows... > > Thank you again, > Adriana > Another option could be to create a type of 'portmon' script (port monitor). It could run via root cron, and be looking for user port forwards. Here's an example of what it would see on the sshd (remote) server: root at slack182:~# lsof -ni |grep user42 sshd 2565 user42 7u IPv4 146804 TCP 127.0.0.1:12345 (LISTEN) This means user42 has a REMOTE port forward built on port 12345 (notice, it is bound to 127.0.0.1 as remote port forwards always are). Your script could look for such processes, and if unauthorized ports are present kill the PID(s) associated with them (in this case 2565). From peter at stuge.se Sun Aug 16 08:15:54 2009 From: peter at stuge.se (Peter Stuge) Date: Sun, 16 Aug 2009 00:15:54 +0200 Subject: Restrict a client port-forward to 1 port In-Reply-To: <496c8fcc0908132309u466c07aam4abed073809cdc7@mail.gmail.com> References: <496c8fcc0908130006g85b18fep987eca7a06c3d752@mail.gmail.com> <222327.59683.qm@web30307.mail.mud.yahoo.com> <496c8fcc0908132309u466c07aam4abed073809cdc7@mail.gmail.com> Message-ID: <20090815221554.26734.qmail@stuge.se> Hi Adriana, Adriana Rodean wrote: > If ssh can't i'm thinking maybe Linux can... > I mean restrict only client X (which is behind a certain ip > address) to listen to port 1037 on the server. No, if this is going to happen it has to happen in the SSH server. OpenSSH can do this if each client has their own private SSH key, and are using it for authentication. As was suggested you would then disable all other authentication methods than publickey in sshd, disallow generic port forwarding, and include a permitopen directive for each client public key in ~/.ssh/authorized_keys If you wish for it to function differently, keep in mind that one really wonderful property of open source software such as OpenSSH (and Linux) is that you yourself, or a contractor, can implement the functionality you desire, exactly the way you like it. Of course it is appreciated if any changes are made in agreement with developers, and contributed back (posted to this mailing list) once finished. //Peter From jchadima at redhat.com Sun Aug 16 14:23:27 2009 From: jchadima at redhat.com (Jan Chadima) Date: Sun, 16 Aug 2009 00:23:27 -0400 (EDT) Subject: About sftp chroot dev! In-Reply-To: Message-ID: <1537291573.976471250396607253.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hi here is the patch. The main goals is to not require chroot tree and do not touch any file other than required for data transfers so user can not fake any system file. Only internal-sftp is allowed others are aborted before execution. ----- Henrique Fernandes wrote: > thanks to all > > i have looked but i did not find anypatches.. i will look again... > > and i did not find why is dangers.. they just say.. it is dangers... > > But Thanks anyway! > > if anyone knows the patche please let me know! > -- JFCh -------------- next part -------------- A non-text attachment was scrubbed... Name: openssh-5.2p1-homechroot.patch Type: text/x-patch Size: 5892 bytes Desc: not available URL: From djm at mindrot.org Sun Aug 16 15:10:36 2009 From: djm at mindrot.org (Damien Miller) Date: Sun, 16 Aug 2009 15:10:36 +1000 (EST) Subject: About sftp chroot dev! In-Reply-To: <1537291573.976471250396607253.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <1537291573.976471250396607253.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: I think this diff is "not even wrong". -d On Sun, 16 Aug 2009, Jan Chadima wrote: > Hi > here is the patch. > The main goals is to not require chroot tree and do not touch any file other than required for data transfers so user can not fake any system file. Only internal-sftp is allowed others are aborted before execution. > > > > ----- Henrique Fernandes wrote: > > thanks to all > > > > i have looked but i did not find anypatches.. i will look again... > > > > and i did not find why is dangers.. they just say.. it is dangers... > > > > But Thanks anyway! > > > > if anyone knows the patche please let me know! > > > > -- > JFCh From jchadima at redhat.com Mon Aug 17 04:52:03 2009 From: jchadima at redhat.com (Jan Chadima) Date: Sun, 16 Aug 2009 14:52:03 -0400 (EDT) Subject: About sftp chroot dev! In-Reply-To: <1324537701.981301250448506754.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <825128366.981331250448723099.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> ----- "Damien Miller" wrote: > I think this diff is "not even wrong". > > -d > > On Sun, 16 Aug 2009, Jan Chadima wrote: > > > Hi > > here is the patch. > > The main goals is to not require chroot tree and do not touch any > file other than required for data transfers so user can not fake any > system file. Only internal-sftp is allowed others are aborted before > execution. This patch is part of RH patchset, so maybe is need to repair minor changes caused by the previous patches in the chain. See openssh-5.2p1-17.fc12 on fedora/devel -- JFCh From adrya1984 at gmail.com Mon Aug 17 16:29:39 2009 From: adrya1984 at gmail.com (Adriana Rodean) Date: Mon, 17 Aug 2009 09:29:39 +0300 Subject: Restrict a client port-forward to 1 port In-Reply-To: <20090815221554.26734.qmail@stuge.se> References: <496c8fcc0908130006g85b18fep987eca7a06c3d752@mail.gmail.com> <222327.59683.qm@web30307.mail.mud.yahoo.com> <496c8fcc0908132309u466c07aam4abed073809cdc7@mail.gmail.com> <20090815221554.26734.qmail@stuge.se> Message-ID: <496c8fcc0908162329v159f3d8flb5aafc7a57b13eb9@mail.gmail.com> Hi, Thank you so much all for the suggestions :))) Same as Peter i believe that this should be a feature of OpenSSH, restrict not only local port along with a public key, but remote port also. This will solve my problem. So please if someone can implement this would be great... In the meantime i will try handle with Linux suggestions... Problem with this approach is that all my clients connect to server with same user. And from your suggestions i see that i can bind a port to an user to do the restriction. Is there any other way to do this? Like bind ip of the client with a port? Right now only way to identify uniquely a client in my server is by it's public key in authorized_keys, that's why this feature would of been nice in ssh to be implemented ... Thank you so much all, Adriana On Sun, Aug 16, 2009 at 01:15, Peter Stuge wrote: > Hi Adriana, > > Adriana Rodean wrote: >> If ssh can't i'm thinking maybe Linux can... >> I mean restrict only client X (which is behind a certain ip >> address) to listen to port 1037 on the server. > > No, if this is going to happen it has to happen in the SSH server. > > OpenSSH can do this if each client has their own private SSH key, and > are using it for authentication. > > As was suggested you would then disable all other authentication > methods than publickey in sshd, disallow generic port forwarding, and > include a permitopen directive for each client public key in > ~/.ssh/authorized_keys > > If you wish for it to function differently, keep in mind that one > really wonderful property of open source software such as OpenSSH > (and Linux) is that you yourself, or a contractor, can implement the > functionality you desire, exactly the way you like it. Of course it > is appreciated if any changes are made in agreement with developers, > and contributed back (posted to this mailing list) once finished. > > > //Peter > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From ru at easypages.cc Tue Aug 18 18:25:15 2009 From: ru at easypages.cc (internet trade reister) Date: Tue, 18 Aug 2009 10:25:15 +0200 (CEST) Subject: company detail update: openssh-unix-dev(at)mindrot.org Message-ID: <26321789.1250583915723.NGMail.u3499@h108518> The european internet tade register company details for openssh-unix-dev(at)mindrot.org - www.mindrot.org Download latest adobe reader : adobe.com For a chargeless listing complete the attached pdf document and return it via fax which you wil find on the attached form only returned forms will be taken in consideration! From sherri.snyder at eds.com Thu Aug 20 03:10:23 2009 From: sherri.snyder at eds.com (Snyder, Sherri S) Date: Wed, 19 Aug 2009 12:10:23 -0500 Subject: sshd_config file settings Message-ID: <322F4DDF161AA84F8538FD01FBED86710520E5EC@usplm203.amer.corp.eds.com> I have several Linux servers that behave oddly when a user's password has expired... they do not prompt for a new one, just kick the user off. I believe this is being caused by a setting in the sshd_config file, but I cannot determine which one - any suggestions? Thanks in advance! From imorgan at nas.nasa.gov Thu Aug 20 06:39:11 2009 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Wed, 19 Aug 2009 13:39:11 -0700 Subject: sshd_config file settings In-Reply-To: <322F4DDF161AA84F8538FD01FBED86710520E5EC@usplm203.amer.corp.eds.com> References: <322F4DDF161AA84F8538FD01FBED86710520E5EC@usplm203.amer.corp.eds.com> Message-ID: <20090819203911.GA11279@linux55.nas.nasa.gov> On Wed, Aug 19, 2009 at 12:10:23 -0500, Snyder, Sherri S wrote: > I have several Linux servers that behave oddly when a user's password > has expired... they do not prompt for a new one, just kick the user off. > I believe this is being caused by a setting in the sshd_config file, but > I cannot determine which one - any suggestions? > Thanks in advance! A little more information would be helpful. What version of OpenSSH are the servers running? What does the password portion of the PAM stack look like? Is UsePAM enabled or disabled in the sshd_config? Also, does this behaviour depend on how the user authenticates to the server, i.e. password auth vs. pubkey? -- Iain Morgan From cfriesen at nortel.com Thu Aug 20 09:28:48 2009 From: cfriesen at nortel.com (Chris Friesen) Date: Wed, 19 Aug 2009 17:28:48 -0600 Subject: high performance ssh support? Message-ID: <4A8C8AB0.7060303@nortel.com> Hi, I've got a high bandwidth link with fairly high latency. I stumbled over the "High Performance SSH" patch at "http://www.psc.edu/networking/projects/hpn-ssh/", also discussed at "http://www.cyberciti.biz/tips/sshd-server-optimization.html". Why hasn't support for this sort of thing gone into the mainline OpenSSH? Thanks, Chris From dgtlshdw at gmail.com Sat Aug 22 06:46:15 2009 From: dgtlshdw at gmail.com (Kevin Boers) Date: Fri, 21 Aug 2009 15:46:15 -0500 Subject: Your OpenSSL headers do not match your library Message-ID: Hello, I recently installed a newer version of OpenSSL on my system and decided to get the latest of OpenSSH as well. I installed OpenSSL 0.9.8k without any difficulty. When I tried to install OpenSSH, however, I got this message: checking OpenSSL header version... 9080bf (OpenSSL 0.9.8k 25 Mar 2009) checking OpenSSL library version... 90701f (OpenSSL 0.9.7a Feb 19 2003) checking whether OpenSSL's headers match the library... no configure: error: Your OpenSSL headers do not match your library. Check config.log for details. If you are sure your installation is consistent, you can disable the check by running "./configure --without-openssl-header-check". Also see contrib/findssl.sh for help identifying header/library mismatches. So, I ran findssl.sh and got the following: Searching for OpenSSL header files. 0x009080bfL /usr/include/openssl/opensslv.h Searching for OpenSSL shared library files. 0x0090701fL /lib/libcrypto.so.4 0x0090701fL /lib/libcrypto.so.0.9.7a 0x0090802fL /opt/splunk/lib/libcrypto.so 0x0090802fL /opt/splunk/lib/libcrypto.so.0.9.8 0x0090701fL /usr/lib/libcrypto.so 0x0090701fL /var/www/vhosts/chroot/lib/libcrypto.so.4 0x0090701fL /var/www/vhosts//lib/libcrypto.so.4 (and then 20 more of those for each of the domains that Plesk manages) Searching for OpenSSL static library files. 0x0090802fL /opt/splunk/lib/libcrypto.a 0x009080bfL /usr/lib/libcrypto.a 0x009080bfL is the correct, new version of OpenSSL. 0x0090701fL appears to be 0.9.7a. Should findssl.sh have found a shared library for 0.9.8? It only seems to have found the 0.9.7 version and whatever splunk packaged up (0x0090802fL). There is a static version of the 0.9.8 library -- is that enough? I don't really know how to proceed here, so any advice would be greatly appreciated. Thanks! Kevin From mouring at eviladmin.org Sat Aug 22 07:10:31 2009 From: mouring at eviladmin.org (Ben Lindstrom) Date: Fri, 21 Aug 2009 16:10:31 -0500 Subject: Your OpenSSL headers do not match your library In-Reply-To: References: Message-ID: On Aug 21, 2009, at 3:46 PM, Kevin Boers wrote: [..] > Searching for OpenSSL header files. > 0x009080bfL /usr/include/openssl/opensslv.h Header new than > > Searching for OpenSSL shared library files. > 0x0090701fL /lib/libcrypto.so.4 > 0x0090701fL /lib/libcrypto.so.0.9.7a The dynamic linked library it more than likely is trying to use. [..] > 0x009080bfL /usr/lib/libcrypto.a This is only a static one, but it isn't the one the installer will use by default (Unless forced or the dynamic library isn't found). So you have an incomplete OpenSSL install. - Ben From mkm at cs.au.dk Sat Aug 22 23:36:12 2009 From: mkm at cs.au.dk (Michael Madsen) Date: Sat, 22 Aug 2009 15:36:12 +0200 Subject: expansion of %h in HostName field of ssh_config Message-ID: <42a3f3bb0908220636y7e3e8e65u371441218a9ed28f@mail.gmail.com> Hi It seems like a nice idea to expand a %h in the HostName field in ssh_config to the host given as argument to ssh. often one would have a entry in their ssh_config like: camel* User ... It's okay if the system knows that the host camel01 fx points to the right host. But what if the actual host is camel01.daimi.au.dk this is something you wouldn't like to write in your terminal. But if the ssh_config was camel* %h.daimi.au.dk User ... Then I can just write ssh camel01 as i would like. This patch should do the trick. One line of code :) --- openssh-5.1p1/ssh.c 2009-08-21 20:34:40.000000000 +0200 +++ my-openssh-5.1p1/ssh.c 2009-08-21 20:39:53.000000000 +0200 -673,9 +673,11 @@ debug3("expanded LocalCommand: %s", options.local_command); xfree(cp); } - - if (options.hostname != NULL) - host = options.hostname; + + if (options.hostname != NULL) { + options.hostname = percent_expand(options.hostname,"h",host); + host = options.hostname; + } /* force lowercase for hostkey matching */ if (options.host_key_alias != NULL) { // Michael -- Michael Madsen - mkm at cs.au.dk From drallen at cs.uwaterloo.ca Wed Aug 26 05:08:22 2009 From: drallen at cs.uwaterloo.ca (Daniel Allen) Date: Tue, 25 Aug 2009 15:08:22 -0400 Subject: PermitUserEnvironment in sshd match block? Message-ID: Hello, Our campus environment would find it very useful to pass user- environment variables for certain login ssh connections, but of course want to avoid the security problems with LD_PRELOAD and PermitUserEnvironment as described in sshd_config manpages. Would the best answer be a patch that adds PermitUserEnvironment support inside match blocks? Are there technical or other reasons this has already been considered and rejected? Thanks, Daniel Allen Computing Technology Specialist Computer Science Computing Facility (CSCF) David R. Cheriton School of Computer Science University of Waterloo (519) 888-4567 ext. 35448 drallen at uwaterloo.ca From dtucker at zip.com.au Wed Aug 26 11:27:47 2009 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 26 Aug 2009 11:27:47 +1000 Subject: PermitUserEnvironment in sshd match block? In-Reply-To: References: Message-ID: <4A948F93.8010508@zip.com.au> Daniel Allen wrote: > Hello, > > Our campus environment would find it very useful to pass > user-environment variables for certain login ssh connections, but of > course want to avoid the security problems with LD_PRELOAD and > PermitUserEnvironment as described in sshd_config manpages. > > Would the best answer be a patch that adds PermitUserEnvironment support > inside match blocks? That seems like a reasonable thing to do. > Are there technical or other reasons this has > already been considered and rejected? The approach to adding things to Match has been on a case by case basis, checking if the thing is a) useful and b) safe. It's a lot easier to evaluate these thing one at a time than in a large batch of them. -- 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 david.l.knodel at gmail.com Wed Aug 26 12:28:33 2009 From: david.l.knodel at gmail.com (david knodel) Date: Wed, 26 Aug 2009 10:28:33 +0800 Subject: PermitUserEnvironment in sshd match block? Message-ID: <270edf4c0908251928y2beea913hdaed0ce225871525@mail.gmail.com> Hi, I just thought I might propose a mechanism that would decrease the security risks of enabling PermitUserEnvironment: If there were some way in the config file to limit what variables are allowed to be passed, this would let administrators tailor the permitted environment configuration to their O/S and organisation. I thought that this would be the most flexible, and cause the least pollution to the sshd_config namespace, if the PermitUserEnvironment keyword in sshd_config (whether globally or in a match block as proposed by Daniel, which seems like a good idea to me) could accept either the current "no" or "yes", or some sort of list specifying what variables may be passed. Possibilities for the format of the list could be: - an explicit list of environment vailables that are permitted, or - a mix of glob-style patterns of variables to allow, possibly with "sudoers"-style processing where a list element with a leading '!' would deny things matching it. I suspect that the first option would be much simpler to implement, and would provide more security; the more elaborate second format was an attempt to think how to cater for admins who wanted to say something like "deny LD_PRELOAD and LD_LIBRARY_PATH, but let other things through", but that might not be worth catering for. I'm not sure what the implications would/should be for the "environment=" option in authorized_keys. Anyway, I feel a bit guilty for not offering up a patch that implements this, but I thought that, if it seemed like a good idea, that someone more cluey that I might want to consider putting it in if they're concerned about the current security implications of enabling the PermitUserEnvironment setting. Regards, David Knodel From djm at mindrot.org Thu Aug 27 03:10:40 2009 From: djm at mindrot.org (Damien Miller) Date: Thu, 27 Aug 2009 03:10:40 +1000 (EST) Subject: PermitUserEnvironment in sshd match block? In-Reply-To: <270edf4c0908251928y2beea913hdaed0ce225871525@mail.gmail.com> References: <270edf4c0908251928y2beea913hdaed0ce225871525@mail.gmail.com> Message-ID: On Wed, 26 Aug 2009, david knodel wrote: > Hi, I just thought I might propose a mechanism that would decrease the > security risks of enabling PermitUserEnvironment: > > If there were some way in the config file to limit what variables > are allowed to be passed, this would let administrators tailor the > permitted environment configuration to their O/S and organisation. We could make PermitUserEnvironment accept a pattern-list to match environment variables, while retaining "yes", "no", "true" and "false" as their current meanings of allow/deny-all. -d From vargalexb at yahoo.com Thu Aug 27 21:35:33 2009 From: vargalexb at yahoo.com (Alexander Varga) Date: Thu, 27 Aug 2009 04:35:33 -0700 (PDT) Subject: sftp-server "audit" logging In-Reply-To: <20090408102934.25887.qmail@stuge.se> References: <934864.27420.qm@web52203.mail.re2.yahoo.com> <20090408102934.25887.qmail@stuge.se> Message-ID: <320768.91860.qm@web52206.mail.re2.yahoo.com> Hello I figured out why it didn't work to me, even i used sshd v4.4 (nowadays of course using 5.2) I did too much steps, LDAP authentication + logging + retricted shell, and one of those was the reason for sftp logging not working. To have restricted shell, so users are able only to sftp and refused to use ssh, I used "/usr/local/libexec/sftp-server" as shell, which then doesn't use the Subsystem command with wanted options (-f LOCAL7 -l INFO) I ccreated a new file, which then used like shell for that user, and voala, everything works excelent more /usr/local/libexec/sftp-server-shell #!/bin/bash /usr/local/libexec/sftp-server -f LOCAL7 -l INFO Alex ----- Original Message ---- From: Peter Stuge To: openssh-unix-dev at mindrot.org Sent: Wednesday, April 8, 2009 12:29:34 PM Subject: Re: sftp-server "audit" logging Alexander Varga wrote: > Any RTFM hint if the logging granularity listed above is possible? I would try to RTFS, usually that's much more reliable than FMs. :) //Peter _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From blp at cs.stanford.edu Fri Aug 28 02:00:38 2009 From: blp at cs.stanford.edu (Ben Pfaff) Date: Thu, 27 Aug 2009 09:00:38 -0700 Subject: [patch] ssh-copy-id: improve error reporting with -i and documentation Message-ID: <87prahp7q1.fsf@blp.benpfaff.org> The "ssh-copy-id" program requires that the argument to -i end in .pub, by appending that extension itself if it is missing. But if the file with .pub appended does not exist, ssh-copy-id reports the misleading message "ERROR: No identities found". This patch improves the error message by mentioning the name of the actual file that does not exist. Also, document that the argument of -i must end in .pub or that .pub will be appended automatically. Index: contrib/ssh-copy-id =================================================================== RCS file: /cvs/openssh/contrib/ssh-copy-id,v retrieving revision 1.7 diff -u -p -r1.7 ssh-copy-id --- contrib/ssh-copy-id 21 Jan 2009 09:29:21 -0000 1.7 +++ contrib/ssh-copy-id 27 Aug 2009 15:57:49 -0000 @@ -18,6 +18,10 @@ if [ "-i" = "$1" ]; then fi shift # and this should leave $1 as the target name fi + if [ ! -e "$ID_FILE" ]; then + echo "$0: ERROR: $ID_FILE does not exist" >&2 + exit 1 + fi else if [ x$SSH_AUTH_SOCK != x ] ; then GET_ID="$GET_ID ssh-add -L" Index: contrib/ssh-copy-id.1 =================================================================== RCS file: /cvs/openssh/contrib/ssh-copy-id.1,v retrieving revision 1.3 diff -u -p -r1.3 ssh-copy-id.1 --- contrib/ssh-copy-id.1 21 Jan 2009 09:29:21 -0000 1.3 +++ contrib/ssh-copy-id.1 27 Aug 2009 15:57:49 -0000 @@ -45,6 +45,10 @@ option is given then the identity file ( .BR ~/.ssh/id_rsa.pub ) is used, regardless of whether there are any keys in your .BR ssh-agent . +The extension +.B .pub +is automatically appended to the identity file's name if it does not +already end with that extension. Otherwise, if this: .PP .B " ssh-add -L" -- Ben Pfaff http://benpfaff.org From blp at cs.stanford.edu Fri Aug 28 05:54:22 2009 From: blp at cs.stanford.edu (Ben Pfaff) Date: Thu, 27 Aug 2009 12:54:22 -0700 Subject: [patch] ssh-copy-id: improve error reporting with -i and documentation In-Reply-To: <87prahp7q1.fsf@blp.benpfaff.org> (Ben Pfaff's message of "Thu, 27 Aug 2009 09:00:38 -0700") References: <87prahp7q1.fsf@blp.benpfaff.org> Message-ID: <87r5uxnic1.fsf@blp.benpfaff.org> Flavien Lebarbe pointed out in private mail that -r might be a better test. Here's an updated patch and changelog: The "ssh-copy-id" program requires that the argument to -i end in .pub, by appending that extension itself if it is missing. But if the file with .pub appended does not exist, ssh-copy-id reports the misleading message "ERROR: No identities found". This patch improves the error message by mentioning the name of the actual file that does not exist. Also, document that the argument of -i must end in .pub or that .pub will be appended automatically. Index: ssh-copy-id =================================================================== RCS file: /cvs/openssh/contrib/ssh-copy-id,v retrieving revision 1.7 diff -u -p -r1.7 ssh-copy-id --- ssh-copy-id 21 Jan 2009 09:29:21 -0000 1.7 +++ ssh-copy-id 27 Aug 2009 19:53:48 -0000 @@ -18,6 +18,10 @@ if [ "-i" = "$1" ]; then fi shift # and this should leave $1 as the target name fi + if [ ! -r "$ID_FILE" ]; then + echo "$0: ERROR: $ID_FILE cannot be read" >&2 + exit 1 + fi else if [ x$SSH_AUTH_SOCK != x ] ; then GET_ID="$GET_ID ssh-add -L" Index: ssh-copy-id.1 =================================================================== RCS file: /cvs/openssh/contrib/ssh-copy-id.1,v retrieving revision 1.3 diff -u -p -r1.3 ssh-copy-id.1 --- ssh-copy-id.1 21 Jan 2009 09:29:21 -0000 1.3 +++ ssh-copy-id.1 27 Aug 2009 19:53:48 -0000 @@ -45,6 +45,10 @@ option is given then the identity file ( .BR ~/.ssh/id_rsa.pub ) is used, regardless of whether there are any keys in your .BR ssh-agent . +The extension +.B .pub +is automatically appended to the identity file's name if it does not +already end with that extension. Otherwise, if this: .PP .B " ssh-add -L" -- Ben Pfaff http://benpfaff.org From dtucker at zip.com.au Fri Aug 28 11:22:01 2009 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 28 Aug 2009 11:22:01 +1000 Subject: Read buffer size in clientloop.c In-Reply-To: <20090714093955.GE27613@calimero.vinschen.de> References: <20090707105716.GN12258@calimero.vinschen.de> <20090707115337.GA22534@gate.dtucker.net> <20090710093345.GG12258@calimero.vinschen.de> <20090714093955.GE27613@calimero.vinschen.de> Message-ID: <4A973139.6060704@zip.com.au> Corinna Vinschen wrote: > Hi Darren, > > On Jul 10 11:33, Corinna Vinschen wrote: >> On Jul 7 21:53, Darren Tucker wrote: >>> On Tue, Jul 07, 2009 at 12:57:16PM +0200, Corinna Vinschen wrote: >>>> Would it be ok to raise the buffers in client_process_net_input() and >>>> client_process_input() to 64K, maybe only on Cygwin? Or to make the >>>> buffer sizes a configurable option? >>> If there's a measureable performance gain (which it sounds like there is) >>> then I personally have no objection to making it a compile time option. >>> Damien? Maybe something like this? >> I tested this patch and it works fine for Cygwin. > > Will this patch be checked in at one point? Yes, it was just committed and will be in 5.3p1. Thanks. -- 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 Dave at Yost.com Sun Aug 30 18:10:43 2009 From: Dave at Yost.com (Dave Yost) Date: Sun, 30 Aug 2009 01:10:43 -0700 Subject: ssh could have a grace period a la sudo Message-ID: Hi. It would be nice to be able to configure sshd so that the following would work: After a successful password-authenticated connection from client user x on client host y, subsequent connections from client user x on client host y within a (resetting) time limit would succeed without re-authenticating via password. Perhaps this would be achieved by sshd sending the client ssh a key that the client would save in a file in its .ssh folder, to be used for authentication on subsequent connections. After a timeout (which resets on re-use), sshd would no longer accept this key. If the client tries and fails to authenticate with this cached key, the client deletes the stored-key file. Dave From dtucker at zip.com.au Sun Aug 30 23:22:02 2009 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 30 Aug 2009 23:22:02 +1000 Subject: ssh could have a grace period a la sudo In-Reply-To: References: Message-ID: <4A9A7CFA.7020904@zip.com.au> Dave Yost wrote: > Hi. > > It would be nice to be able to configure sshd so that the following > would work: > > After a successful password-authenticated connection from client user x > on client host y, subsequent connections from client user x on client > host y within a (resetting) time limit would succeed without > re-authenticating via password. There's already the capability for doing the first part of this in the client, where an existing connection can be reused without reauthentication. See ControlMaster and ControlPath in ssh_config(5). In fact, if you're willing to write a little program, you can probably (ab)use LocalCommand to get the keepalive/timeout behaviour you want. It just needs to touch the control socket at startup, then wait for the socket to either become older than the timeout (at which point it's deleted) or removed (because another instance deleted it). Consider the following ~/.ssh/config Host foo ControlMaster auto ControlPath ~/.ssh/%r@%h:%p PermitLocalCommand yes LocalCommand ~/bin/timeout_controlpath ~/.ssh/%r@%h:%p 60 & and a ~/bin/timeout_controlpath that looks like: #!/usr/bin/perl ($path, $timeout) = @ARGV; utime undef, undef, $path; # update mtime while (sleep 1) { $age = (stat($path))[9] || exit; # socket removed if ($age + $timeout < time) { unlink $path; exit; } } > Perhaps this would be achieved by sshd sending the client ssh a key that > the client would save in a file in its .ssh folder, to be used for > authentication on subsequent connections. After a timeout (which resets > on re-use), sshd would no longer accept this key. If the client tries > and fails to authenticate with this cached key, the client deletes the > stored-key file. That would require a protocol extension and seems kinda dangerous. It also wouldn't work if the client was configured to only try password authentication. -- 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 apb at cequrux.com Mon Aug 31 01:11:07 2009 From: apb at cequrux.com (Alan Barrett) Date: Sun, 30 Aug 2009 17:11:07 +0200 Subject: ssh could have a grace period a la sudo In-Reply-To: <4A9A7CFA.7020904@zip.com.au> References: <4A9A7CFA.7020904@zip.com.au> Message-ID: <20090830151106.GB2838@apb-laptoy.apb.alt.za> On Sun, 30 Aug 2009, Darren Tucker wrote: > Dave Yost wrote: > >It would be nice to be able to configure sshd so that the > >following would work: > > > >After a successful password-authenticated connection from client > >user x on client host y, subsequent connections from client user x > >on client host y within a (resetting) time limit would succeed > >without re-authenticating via password. > > There's already the capability for doing the first part of this in > the client, where an existing connection can be reused without > reauthentication. See ControlMaster and ControlPath in > ssh_config(5). There are also patches floating around for a ControlPersist option, which is intended to automatically keep the ControlMaster running in the background for a configurable time. --apb (Alan Barrett)