From dkg at fifthhorseman.net Wed Feb 1 01:56:27 2012 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 31 Jan 2012 09:56:27 -0500 Subject: PATCH: Support for encrypted host keys In-Reply-To: <30D9F5B0-59F6-420E-AC97-FF6FD09C0339@gmail.com> References: <30D9F5B0-59F6-420E-AC97-FF6FD09C0339@gmail.com> Message-ID: <4F28011B.2070506@fifthhorseman.net> Hi Zev-- On 01/28/2012 04:25 AM, Zev Weiss wrote: > I recently found myself wanting to run sshd with passphrase-protected host keys rather than the usual unencrypted format, and was somewhat surprised to discover that sshd did not support this. I'm not sure if there's any particular reason for that, but I've developed the below patch (relative to current CVS at time of writing) that implements this. It prompts for the passphrase when the daemon is started, similarly to Apache's behavior with encrypted SSL certificates. Can i ask what threats you hope to mitigate with this approach? What are your concerns about having a cleartext ~/.ssh/known_hosts? Also, you might want to file this at https://bugzilla.mindrot.org/, so that the suggestion and the patch don't get lost in the mailing list archive if they're not immediately accepted or applied. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1030 bytes Desc: OpenPGP digital signature URL: From keisial at gmail.com Wed Feb 1 02:37:54 2012 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Tue, 31 Jan 2012 16:37:54 +0100 Subject: PATCH: Support for encrypted host keys In-Reply-To: <4F28011B.2070506@fifthhorseman.net> References: <30D9F5B0-59F6-420E-AC97-FF6FD09C0339@gmail.com> <4F28011B.2070506@fifthhorseman.net> Message-ID: <4F280AD2.2070600@gmail.com> Daniel Kahn Gillmor wrote: > Hi Zev-- > > On 01/28/2012 04:25 AM, Zev Weiss wrote: >> I recently found myself wanting to run sshd with passphrase-protected host keys rather than the usual unencrypted format, and was somewhat surprised to discover that sshd did not support this. I'm not sure if there's any particular reason for that, but I've developed the below patch (relative to current CVS at time of writing) that implements this. It prompts for the passphrase when the daemon is started, similarly to Apache's behavior with encrypted SSL certificates. > Can i ask what threats you hope to mitigate with this approach? What > are your concerns about having a cleartext ~/.ssh/known_hosts? Daniel, I think he refers to /etc/ssh/ssh_host_*key, not ~/.ssh/known_hosts From zevweiss at gmail.com Wed Feb 1 03:25:54 2012 From: zevweiss at gmail.com (Zev Weiss) Date: Tue, 31 Jan 2012 10:25:54 -0600 Subject: PATCH: Support for encrypted host keys In-Reply-To: <4F28011B.2070506@fifthhorseman.net> References: <30D9F5B0-59F6-420E-AC97-FF6FD09C0339@gmail.com> <4F28011B.2070506@fifthhorseman.net> Message-ID: <807BC19D-FA7B-4C31-A124-1A3CF11DF609@gmail.com> On Jan 31, 2012, at 8:56 AM, Daniel Kahn Gillmor wrote: > Hi Zev-- > > On 01/28/2012 04:25 AM, Zev Weiss wrote: >> I recently found myself wanting to run sshd with passphrase-protected host keys rather than the usual unencrypted format, and was somewhat surprised to discover that sshd did not support this. I'm not sure if there's any particular reason for that, but I've developed the below patch (relative to current CVS at time of writing) that implements this. It prompts for the passphrase when the daemon is started, similarly to Apache's behavior with encrypted SSL certificates. > > Can i ask what threats you hope to mitigate with this approach? What > are your concerns about having a cleartext ~/.ssh/known_hosts? > > Also, you might want to file this at https://bugzilla.mindrot.org/, so > that the suggestion and the patch don't get lost in the mailing list > archive if they're not immediately accepted or applied. > > Regards, > > --dkg > As ?ngel mentioned, this regards server-side /etc/ssh/ssh_host*key files, not ~/.ssh/known_hosts on the client. As for threat mitigation -- an attacker who was able to read the file, e.g. via some sort of permissions bypass or perhaps a compromised system backup, would not be immediately able to impersonate the host. Thanks for the bugzilla tip -- now posted at https://bugzilla.mindrot.org/show_bug.cgi?id=1974. Zev From dkg at fifthhorseman.net Wed Feb 1 03:58:56 2012 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 31 Jan 2012 11:58:56 -0500 Subject: PATCH: Support for encrypted host keys In-Reply-To: <4F280AD2.2070600@gmail.com> References: <30D9F5B0-59F6-420E-AC97-FF6FD09C0339@gmail.com> <4F28011B.2070506@fifthhorseman.net> <4F280AD2.2070600@gmail.com> Message-ID: <4F281DD0.1020705@fifthhorseman.net> On 01/31/2012 10:37 AM, ?ngel Gonz?lez wrote: > Daniel, I think he refers to /etc/ssh/ssh_host_*key, not ~/.ssh/known_hosts Ah, you're right. sorry, i misinterpreted (and clearly didn't read the patch). Thanks for the correction. Zev, am i right in thinking that your approach to this problem seems to make it so that launching sshd might or might not prompt the user for a passphrase when starting up? This might be tricky or cause trouble with many common init systems. What about an approach instead that allows sshd to talk to a running ssh-agent for its keys? Then a system administrator could load the host key to the system ssh-agent at any point, leaving them passphrase-protected on disk. This seems like it might be less code introduced, and it also introduces a nice symmetry with the ssh client. Also, improvements with the agent (e.g. connecting to smartcards) would flow naturally to sshd as well. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1030 bytes Desc: OpenPGP digital signature URL: From nkadel at gmail.com Wed Feb 1 06:39:09 2012 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Tue, 31 Jan 2012 14:39:09 -0500 Subject: PATCH: Support for encrypted host keys In-Reply-To: <4F28011B.2070506@fifthhorseman.net> References: <30D9F5B0-59F6-420E-AC97-FF6FD09C0339@gmail.com> <4F28011B.2070506@fifthhorseman.net> Message-ID: On Tue, Jan 31, 2012 at 9:56 AM, Daniel Kahn Gillmor wrote: > Hi Zev-- > > On 01/28/2012 04:25 AM, Zev Weiss wrote: >> I recently found myself wanting to run sshd with passphrase-protected host keys rather than the usual unencrypted format, and was somewhat surprised to discover that sshd did not support this. ?I'm not sure if there's any particular reason for that, but I've developed the below patch (relative to current CVS at time of writing) that implements this. ?It prompts for the passphrase when the daemon is started, similarly to Apache's behavior with encrypted SSL certificates. > > Can i ask what threats you hope to mitigate with this approach? ?What > are your concerns about having a cleartext ~/.ssh/known_hosts? One concern is pretending to be the designated host with host keys retrieved from backup or from sites that deploy identical hostkeys via a base installation or replicated OS image in virtualization. Since the sshd handles passwords in many environments, and there is no mechanism for revocation or expiration of host keys in $HOME/.ssh/known_hosts, the ability to pretend to be a previously accepted host with stolen keys has presented a functional security issue since SSH was first written. Too many sites are far, far too careless with these keys since "if they're inside our network, we have much bigger problems", both of which I've heard on various occasions. From imorgan at nas.nasa.gov Wed Feb 1 11:53:57 2012 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Tue, 31 Jan 2012 16:53:57 -0800 Subject: PATCH: Support for encrypted host keys In-Reply-To: References: <30D9F5B0-59F6-420E-AC97-FF6FD09C0339@gmail.com> <4F28011B.2070506@fifthhorseman.net> Message-ID: <20120201005357.GB4834@linux124.nas.nasa.gov> On Tue, Jan 31, 2012 at 13:39:09 -0600, Nico Kadel-Garcia wrote: > On Tue, Jan 31, 2012 at 9:56 AM, Daniel Kahn Gillmor > wrote: > > Hi Zev-- > > > > On 01/28/2012 04:25 AM, Zev Weiss wrote: > >> I recently found myself wanting to run sshd with passphrase-protected host keys rather than the usual unencrypted format, and was somewhat surprised to discover that sshd did not support this. ?I'm not sure if there's any particular reason for that, but I've developed the below patch (relative to current CVS at time of writing) that implements this. ?It prompts for the passphrase when the daemon is started, similarly to Apache's behavior with encrypted SSL certificates. > > > > Can i ask what threats you hope to mitigate with this approach? ?What > > are your concerns about having a cleartext ~/.ssh/known_hosts? > > One concern is pretending to be the designated host with host keys > retrieved from backup or from sites that deploy identical hostkeys via > a base installation or replicated OS image in virtualization. Since > the sshd handles passwords in many environments, and there is no > mechanism for revocation or expiration of host keys in > $HOME/.ssh/known_hosts, the ability to pretend to be a previously > accepted host with stolen keys has presented a functional security > issue since SSH was first written. With recent versions of OpenSSH, 5.4p1 and later, you can use host certificates which can be expired or revoked. Also, regarding backups, it is possible to exclude the private keys from being backed up. That is only a partial solution and would mean that new keys would have to be created if the old ones were lost. > > Too many sites are far, far too careless with these keys since "if > they're inside our network, we have much bigger problems", both of > which I've heard on various occasions. Note that encrypting the private keys would break ssh-keysign (unless some agent mechanism is used). Thus, this would break hostbased authentication in cases where the client host used encrypted host keys. -- Iain Morgan From nkadel at gmail.com Wed Feb 1 12:50:58 2012 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Tue, 31 Jan 2012 20:50:58 -0500 Subject: PATCH: Support for encrypted host keys In-Reply-To: <20120201005357.GB4834@linux124.nas.nasa.gov> References: <30D9F5B0-59F6-420E-AC97-FF6FD09C0339@gmail.com> <4F28011B.2070506@fifthhorseman.net> <20120201005357.GB4834@linux124.nas.nasa.gov> Message-ID: On Tue, Jan 31, 2012 at 7:53 PM, Iain Morgan wrote: > On Tue, Jan 31, 2012 at 13:39:09 -0600, Nico Kadel-Garcia wrote: >> On Tue, Jan 31, 2012 at 9:56 AM, Daniel Kahn Gillmor >> wrote: >> > Hi Zev-- >> > >> > On 01/28/2012 04:25 AM, Zev Weiss wrote: >> >> I recently found myself wanting to run sshd with passphrase-protected host keys rather than the usual unencrypted format, and was somewhat surprised to discover that sshd did not support this. ?I'm not sure if there's any particular reason for that, but I've developed the below patch (relative to current CVS at time of writing) that implements this. ?It prompts for the passphrase when the daemon is started, similarly to Apache's behavior with encrypted SSL certificates. >> > >> > Can i ask what threats you hope to mitigate with this approach? ?What >> > are your concerns about having a cleartext ~/.ssh/known_hosts? >> >> One concern is pretending to be the designated host with host keys >> retrieved from backup or from sites that deploy identical hostkeys via >> a base installation or replicated OS image in virtualization. Since >> the sshd handles passwords in many environments, and there is no >> mechanism for revocation or expiration of host keys in >> $HOME/.ssh/known_hosts, the ability to pretend to be a previously >> accepted host with stolen keys has presented a functional security >> issue since SSH was first written. > > With recent versions of OpenSSH, 5.4p1 and later, you can use host > certificates which can be expired or revoked. Also, regarding backups, > it is possible to exclude the private keys from being backed up. That is > only a partial solution and would mean that new keys would have to be > created if the old ones were lost. Good! I'm afraid I'm compelled by work to spend my time with older releases in "production" environments. And until more deployed clients support this as well, I'm afraid it will still be a risk. But it's a good move. And yes, backing up the private keys is important if you have to restore the host. It's *precisely* the sort of data you want to be able to build an authorized replacement host. >> Too many sites are far, far too careless with these keys since "if >> they're inside our network, we have much bigger problems", both of >> which I've heard on various occasions. > > Note that encrypting the private keys would break ssh-keysign (unless > some agent mechanism is used). Thus, this would break hostbased > authentication in cases where the client host used encrypted host keys. Excellent point! From zhenbo1987 at gmail.com Sat Feb 4 12:55:21 2012 From: zhenbo1987 at gmail.com (Zhenbo Xu) Date: Sat, 4 Feb 2012 09:55:21 +0800 Subject: Potential memory leak in sshd [detected by melton] Message-ID: Hi all, After the memory leaks (bug 1967 ) I reported in bugzilla are fixed, I also applied melton(http://lcs.ios.ac.cn/~xuzb/melton.html) to detect the potential bugs in sshd (openssh-5.9p1). The url below is the index of bug reports that are checked as real bugs manually. http://lcs.ios.ac.cn/~xuzb/bugsfound/memleak/openssh-5.9p1/realbugs/sshd/index.html Shall we fix these bugs? Or just let them go since they are not so serious? Hope for your replies! -- Zhenbo Xu From zhenbo1987 at gmail.com Sat Feb 4 13:02:03 2012 From: zhenbo1987 at gmail.com (Zhenbo Xu) Date: Sat, 4 Feb 2012 10:02:03 +0800 Subject: Potential memory leak in sshd [detected by melton] In-Reply-To: References: Message-ID: By the way, I submitted this report in bugzilla a few days ago, but there is no response. Should I report bugs in this mailing list rather than in bugzilla? 2012/2/4 Zhenbo Xu > Hi all, > > After the memory leaks (bug 1967 ) I reported in bugzilla are fixed, > > I also applied melton(http://lcs.ios.ac.cn/~xuzb/melton.html) > > to detect the potential bugs in sshd (openssh-5.9p1). > > > The url below is the index of bug reports that are checked as real bugs manually. > > http://lcs.ios.ac.cn/~xuzb/bugsfound/memleak/openssh-5.9p1/realbugs/sshd/index.html > > > Shall we fix these bugs? Or just let them go since they are not so serious? > > Hope for your replies! > > > -- > Zhenbo Xu > -- Zhenbo Xu From dan at doxpara.com Sat Feb 4 13:21:37 2012 From: dan at doxpara.com (Dan Kaminsky) Date: Fri, 3 Feb 2012 21:21:37 -0500 Subject: Potential memory leak in sshd [detected by melton] In-Reply-To: References: Message-ID: ssh uses a unique process for each connection, and sshd forks for each new connection, so the only memory leaks that are "in scope" are those that apply to the master sshd. I don't think that applies to any of these bugs. Melton looks rather cool though. On Fri, Feb 3, 2012 at 9:02 PM, Zhenbo Xu wrote: > By the way, I submitted this report in bugzilla a few days ago, but there > is no response. > Should I report bugs in this mailing list rather than in bugzilla? > > 2012/2/4 Zhenbo Xu > > > Hi all, > > > > After the memory leaks (bug 1967 < > https://bugzilla.mindrot.org/show_bug.cgi?id=1967>) I reported in > bugzilla are fixed, > > > > I also applied melton(http://lcs.ios.ac.cn/~xuzb/melton.html) > > > > to detect the potential bugs in sshd (openssh-5.9p1). > > > > > > The url below is the index of bug reports that are checked as real bugs > manually. > > > > > http://lcs.ios.ac.cn/~xuzb/bugsfound/memleak/openssh-5.9p1/realbugs/sshd/index.html > > > > > > Shall we fix these bugs? Or just let them go since they are not so > serious? > > > > Hope for your replies! > > > > > > -- > > Zhenbo Xu > > > > > > -- > Zhenbo Xu > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From zhenbo1987 at gmail.com Sun Feb 5 16:54:44 2012 From: zhenbo1987 at gmail.com (Zhenbo Xu) Date: Sun, 5 Feb 2012 13:54:44 +0800 Subject: Potential memory leak in sshd [detected by melton] In-Reply-To: References: Message-ID: What about this report http://lcs.ios.ac.cn/~xuzb/bugsfound/memleak/openssh-5.9p1/realbugs/sshd/report-uWzwb1.html#EndPath ? At the end of the function server_accept_loop, fdset leaks. It means each time the master sshd accept a new connection, it create a new space for fdset but no free it. Or it is a false positive? 2012/2/4 Dan Kaminsky > ssh uses a unique process for each connection, and sshd forks for each new > connection, so the only memory leaks that are "in scope" are those that > apply to the master sshd. I don't think that applies to any of these bugs. > > Melton looks rather cool though. > > On Fri, Feb 3, 2012 at 9:02 PM, Zhenbo Xu wrote: > >> By the way, I submitted this report in bugzilla a few days ago, but there >> is no response. >> Should I report bugs in this mailing list rather than in bugzilla? >> >> 2012/2/4 Zhenbo Xu >> >> > Hi all, >> > >> > After the memory leaks (bug 1967 < >> https://bugzilla.mindrot.org/show_bug.cgi?id=1967>) I reported in >> bugzilla are fixed, >> >> > >> > I also applied melton(http://lcs.ios.ac.cn/~xuzb/melton.html) >> > >> > to detect the potential bugs in sshd (openssh-5.9p1). >> > >> > >> > The url below is the index of bug reports that are checked as real bugs >> manually. >> > >> > >> http://lcs.ios.ac.cn/~xuzb/bugsfound/memleak/openssh-5.9p1/realbugs/sshd/index.html >> > >> > >> > Shall we fix these bugs? Or just let them go since they are not so >> serious? >> > >> > Hope for your replies! >> > >> > >> > -- >> > Zhenbo Xu >> > >> >> >> >> -- >> Zhenbo Xu >> _______________________________________________ >> openssh-unix-dev mailing list >> openssh-unix-dev at mindrot.org >> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev >> > > -- Zhenbo Xu From keisial at gmail.com Mon Feb 6 07:38:41 2012 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Sun, 05 Feb 2012 21:38:41 +0100 Subject: Potential memory leak in sshd [detected by melton] In-Reply-To: References: Message-ID: <4F2EE8D1.4030606@gmail.com> On 05/02/12 06:54, Zhenbo Xu wrote: > What about this report > http://lcs.ios.ac.cn/~xuzb/bugsfound/memleak/openssh-5.9p1/realbugs/sshd/report-uWzwb1.html#EndPath > ? > At the end of the function server_accept_loop, fdset leaks. It means each > time the master sshd accept a new connection, it create a new space for > fdset but no free it. Or it is a false positive? No. Before allocating the fdset (line 14156), it frees the previous one if present (line 14155). There's a small leak of the last one when it exits the infinite loop. It should probably free fdset on line 14330. It seems an odd way, doing the free() + calloc() on every iteration. Seems easier to do if (fdset != NULL) bzero(fdset, ...); else fdset = xcalloc(...); maxfd can be decreased in line 14236, but that doesn't require the xfree() + xcalloc() pattern. From keisial at gmail.com Mon Feb 6 07:51:32 2012 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Sun, 05 Feb 2012 21:51:32 +0100 Subject: Potential memory leak in sshd [detected by melton] In-Reply-To: References: Message-ID: <4F2EEBD4.4080801@gmail.com> On 04/02/12 02:55, Zhenbo Xu wrote: > I also applied melton(http://lcs.ios.ac.cn/~xuzb/melton.html) > > to detect the potential bugs in sshd (openssh-5.9p1). > > > The url below is the index of bug reports that are checked as real > bugs manually. > > http://lcs.ios.ac.cn/~xuzb/bugsfound/memleak/openssh-5.9p1/realbugs/sshd/index.html > > > Shall we fix these bugs? Or just let them go since they are not so serious? > Hope for your replies! The second leak Logic error Memory leak session.i 13193 13 View Report http://lcs.ios.ac.cn/~xuzb/bugsfound/memleak/openssh-5.9p1/realbugs/sshd/report-zSMfqI.html#EndPath is a false positive. The only way to exit the infinite loop is the return of line 13267. And line 13266 calls session_close(), which frees s->auth_data in line 14994. (granted, it's tricky to follow...) The analysis seem to have stopped in line 13193, after step 14. As a suggestion, I recommend you to make the messages "Execution continues on line 12345" links to line 12345. Also, going to the opening brace from the closing one would be useful when dealing with big blocks. From keisial at gmail.com Mon Feb 6 08:02:58 2012 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Sun, 05 Feb 2012 22:02:58 +0100 Subject: Potential memory leak in sshd [detected by melton] In-Reply-To: References: Message-ID: <4F2EEE82.6000106@gmail.com> On 04/02/12 02:55, Zhenbo Xu wrote: > The url below is the index of bug reports that are checked as real > bugs manually. > > http://lcs.ios.ac.cn/~xuzb/bugsfound/memleak/openssh-5.9p1/realbugs/sshd/index.html > > > Shall we fix these bugs? Or just let them go since they are not so serious? > > Hope for your replies! The third error Logic error Memory leak monitor.i 13658 3 seems like a good catch. There should be a call to buffer_free(&logmsg); before the return -1 of monitor_read_log. Although it only happens if the client closed the socket, in which case the next poll of line 13702 should fail and monitor_read_log never called again. So it probably only leaks once. Attaching fix. -------------- next part -------------- A non-text attachment was scrubbed... Name: monitor_read_log-buffer_free.patch Type: text/x-patch Size: 377 bytes Desc: not available URL: From keisial at gmail.com Mon Feb 6 08:11:34 2012 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Sun, 05 Feb 2012 22:11:34 +0100 Subject: Potential memory leak in sshd [detected by melton] In-Reply-To: <4F2EEBD4.4080801@gmail.com> References: <4F2EEBD4.4080801@gmail.com> Message-ID: <4F2EF086.6040003@gmail.com> On 05/02/12 21:51, ?ngel Gonz?lez wrote: > The second leak > > Logic error Memory leak session.i 13193 13 View Report > > > > http://lcs.ios.ac.cn/~xuzb/bugsfound/memleak/openssh-5.9p1/realbugs/sshd/report-zSMfqI.html#EndPath > > is a false positive. > > The only way to exit the infinite loop is the return of line 13267. > And line 13266 calls session_close(), which frees s->auth_data in line > 14994. The fifth one is a duplicate of this (same path, but the variable allocated on next line). 12th one is the same issue of freeing at session_close not detected. But this time with s->auth_display From keisial at gmail.com Mon Feb 6 08:34:30 2012 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Sun, 05 Feb 2012 22:34:30 +0100 Subject: Potential memory leak in sshd [detected by melton] In-Reply-To: References: Message-ID: <4F2EF5E6.5070504@gmail.com> On 04/02/12 02:55, Zhenbo Xu wrote: > The url below is the index of bug reports that are checked as real > bugs manually. > > http://lcs.ios.ac.cn/~xuzb/bugsfound/memleak/openssh-5.9p1/realbugs/sshd/index.html > > Shall we fix these bugs? Or just let them go since they are not so serious? > > Hope for your replies! The seventh report is not complete, but seem a genuine leak: Logic error Memory leak auth2-chall.i 9868 5 View Report http://lcs.ios.ac.cn/~xuzb/bugsfound/memleak/openssh-5.9p1/realbugs/sshd/report-0o5DSr.html#EndPath Melton complains that authctxt->kbdintctxt is never freed. The return value passes authctxt to auth2_challenge_start(), and auth2_challenge_start() may call auth2_challenge_stop(), which frees it (line 9878) [melton doesn't realise this]. In the path where it doesn't free it, it sets authctxt->postponed and returns 0 to userauth_kbdint(), itself called from input_userauth_request() at auth2.c line 283. There then calls userauth_finish() at line 285. Which return in line 336. And input_userauth_request() finishes with authctxt getting out of scope, without authctxt->kbdintctxt having been freed. From keisial at gmail.com Mon Feb 6 08:58:52 2012 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Sun, 05 Feb 2012 22:58:52 +0100 Subject: Potential memory leak in sshd [detected by melton] In-Reply-To: References: Message-ID: <4F2EFB9C.5080901@gmail.com> On 04/02/12 02:55, Zhenbo Xu wrote: > The url below is the index of bug reports that are checked as real > bugs manually. > > http://lcs.ios.ac.cn/~xuzb/bugsfound/memleak/openssh-5.9p1/realbugs/sshd/index.html > > > Shall we fix these bugs? Or just let them go since they are not so serious? > > Hope for your replies! The 8th report is another false positive Logic error Memory leak auth2.i 11503 6 View http://lcs.ios.ac.cn/~xuzb/bugsfound/memleak/openssh-5.9p1/realbugs/sshd/report-ABKOwr.html#EndPath fakepw() returns a static variable. From keisial at gmail.com Mon Feb 6 09:04:07 2012 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Sun, 05 Feb 2012 23:04:07 +0100 Subject: Potential memory leak in sshd [detected by melton] In-Reply-To: References: Message-ID: <4F2EFCD7.9050301@gmail.com> On 04/02/12 02:55, Zhenbo Xu wrote: > The url below is the index of bug reports that are checked as real > bugs manually. > > http://lcs.ios.ac.cn/~xuzb/bugsfound/memleak/openssh-5.9p1/realbugs/sshd/index.html > > > Shall we fix these bugs? Or just let them go since they are not so serious? > > Hope for your replies! The 10th report is another false positive: Logic error Memory leak auth-options.i 10587 28 View Report http://lcs.ios.ac.cn/~xuzb/bugsfound/memleak/openssh-5.9p1/realbugs/sshd/report-mVEeJj.html#EndPath Melton complains that in line 10587 the memory of data wasn't released, but there's a call to buffer_free(&data); in line 10585. From djm at mindrot.org Mon Feb 6 08:59:35 2012 From: djm at mindrot.org (Damien Miller) Date: Mon, 6 Feb 2012 08:59:35 +1100 (EST) Subject: PATCH: Support for encrypted host keys In-Reply-To: <4F281DD0.1020705@fifthhorseman.net> References: <30D9F5B0-59F6-420E-AC97-FF6FD09C0339@gmail.com> <4F28011B.2070506@fifthhorseman.net> <4F280AD2.2070600@gmail.com> <4F281DD0.1020705@fifthhorseman.net> Message-ID: On Tue, 31 Jan 2012, Daniel Kahn Gillmor wrote: > What about an approach instead that allows sshd to talk to a running > ssh-agent for its keys? Then a system administrator could load the host > key to the system ssh-agent at any point, leaving them > passphrase-protected on disk. I'm hoping to implement this anyway to support hostkeys in PKCS11 tokens. It would be fantastic if someone did it first and saved me the work :) -d From keisial at gmail.com Mon Feb 6 09:07:51 2012 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Sun, 05 Feb 2012 23:07:51 +0100 Subject: Potential memory leak in sshd [detected by melton] In-Reply-To: <4F2EFCD7.9050301@gmail.com> References: <4F2EFCD7.9050301@gmail.com> Message-ID: <4F2EFDB7.4090809@gmail.com> On 05/02/12 23:04, ?ngel Gonz?lez wrote: > The 10th report is another false positive: > Logic error Memory leak auth-options.i 10587 28 View Report > > > > http://lcs.ios.ac.cn/~xuzb/bugsfound/memleak/openssh-5.9p1/realbugs/sshd/report-mVEeJj.html#EndPath > > Melton complains that in line 10587 the memory of data wasn't released, > but there's a call to buffer_free(&data); > in line 10585. Same false positive for 11th, 13th & 14th. http://lcs.ios.ac.cn/~xuzb/bugsfound/memleak/openssh-5.9p1/realbugs/sshd/report-UDrpYF.html#EndPath http://lcs.ios.ac.cn/~xuzb/bugsfound/memleak/openssh-5.9p1/realbugs/sshd/report-BtfghY.html#EndPath http://lcs.ios.ac.cn/~xuzb/bugsfound/memleak/openssh-5.9p1/realbugs/sshd/report-XXMHNK.html#EndPath From zhenbo1987 at gmail.com Mon Feb 6 12:53:22 2012 From: zhenbo1987 at gmail.com (Zhenbo Xu) Date: Mon, 6 Feb 2012 09:53:22 +0800 Subject: Potential memory leak in sshd [detected by melton] In-Reply-To: <4F2EEBD4.4080801@gmail.com> References: <4F2EEBD4.4080801@gmail.com> Message-ID: 2012/2/6 ?ngel Gonz?lez > On 04/02/12 02:55, Zhenbo Xu wrote: > > I also applied melton(http://lcs.ios.ac.cn/~xuzb/melton.html) > > to detect the potential bugs in sshd (openssh-5.9p1). > > > The url below is the index of bug reports that are checked as real > bugs manually. > http://lcs.ios.ac.cn/~xuzb/bugsfound/memleak/openssh-5.9p1/realbugs/sshd/index.html > > > Shall we fix these bugs? Or just let them go since they are not so serious? > Hope for your replies! > > > The second leak > > Logic error Memory leak session.i 13193 13 View Report > > > http://lcs.ios.ac.cn/~xuzb/bugsfound/memleak/openssh-5.9p1/realbugs/sshd/report-zSMfqI.html#EndPath > > is a false positive. > > The only way to exit the infinite loop is the return of line 13267. > And line 13266 calls session_close(), which frees s->auth_data in line > 14994. > (granted, it's tricky to follow...) > This report may not be so clear. The leak occurs at the second loop iteration when the "type = packet_read()" is equal to case 34 (line 13192) twice. At the first iteration, s->auth_proto gets a heap buffer but is not freed. And at the second iteration, s->auth_proto is reassigned, which means the heap buffer allocated at the first iteration leaks. > The analysis seem to have stopped in line 13193, after step 14. > > As a suggestion, I recommend you to make the messages "Execution continues > on line 12345" > links to line 12345. > Also, going to the opening brace from the closing one would be useful when > dealing with big blocks. > > Thank you for your suggestion and your detail replies! -- Zhenbo Xu From zhenbo1987 at gmail.com Mon Feb 6 13:03:17 2012 From: zhenbo1987 at gmail.com (Zhenbo Xu) Date: Mon, 6 Feb 2012 10:03:17 +0800 Subject: Potential memory leak in sshd [detected by melton] In-Reply-To: <4F2EFB9C.5080901@gmail.com> References: <4F2EFB9C.5080901@gmail.com> Message-ID: 2012/2/6 ?ngel Gonz?lez > On 04/02/12 02:55, Zhenbo Xu wrote: > > The url below is the index of bug reports that are checked as real > bugs manually. > http://lcs.ios.ac.cn/~xuzb/bugsfound/memleak/openssh-5.9p1/realbugs/sshd/index.html > > > Shall we fix these bugs? Or just let them go since they are not so serious? > > Hope for your replies! > > The 8th report is another false positive > Logic error Memory leak auth2.i 11503 6 View > http://lcs.ios.ac.cn/~xuzb/bugsfound/memleak/openssh-5.9p1/realbugs/sshd/report-ABKOwr.html#EndPath > > fakepw() returns a static variable. > > Shall we free authctxt->pw before this assignment authctxt->pw = fakepw();, Since authctxt->pw gets a heap space at 11496. (authctxt->pw = (use_privsep ? mm_getpwnamallow(user) : getpwnamallow(user) );) -- Zhenbo Xu From zhenbo1987 at gmail.com Mon Feb 6 13:30:04 2012 From: zhenbo1987 at gmail.com (Zhenbo Xu) Date: Mon, 6 Feb 2012 10:30:04 +0800 Subject: Potential memory leak in sshd [detected by melton] In-Reply-To: <4F2EFCD7.9050301@gmail.com> References: <4F2EFCD7.9050301@gmail.com> Message-ID: 2012/2/6 ?ngel Gonz?lez > On 04/02/12 02:55, Zhenbo Xu wrote: > > The url below is the index of bug reports that are checked as real > bugs manually. > http://lcs.ios.ac.cn/~xuzb/bugsfound/memleak/openssh-5.9p1/realbugs/sshd/index.html > > > Shall we fix these bugs? Or just let them go since they are not so serious? > > Hope for your replies! > > The 10th report is another false positive: > Logic error Memory leak auth-options.i 10587 28 View Report > http://lcs.ios.ac.cn/~xuzb/bugsfound/memleak/openssh-5.9p1/realbugs/sshd/report-mVEeJj.html#EndPath > > Melton complains that in line 10587 the memory of data wasn't released, > but there's a call to buffer_free(&data); > in line 10585. > > What melton complains is the heap object returned by buffer_get_cstring_ret wasn't released. -- Zhenbo Xu From zhenbo1987 at gmail.com Mon Feb 6 13:33:31 2012 From: zhenbo1987 at gmail.com (Zhenbo Xu) Date: Mon, 6 Feb 2012 10:33:31 +0800 Subject: Potential memory leak in sshd [detected by melton] In-Reply-To: <4F2EFDB7.4090809@gmail.com> References: <4F2EFCD7.9050301@gmail.com> <4F2EFDB7.4090809@gmail.com> Message-ID: Same with these reports. 2012/2/6 ?ngel Gonz?lez > On 05/02/12 23:04, ?ngel Gonz?lez wrote: > > The 10th report is another false positive: > > Logic error Memory leak auth-options.i 10587 28 View Report > > < > http://lcs.ios.ac.cn/%7Exuzb/bugsfound/memleak/openssh-5.9p1/realbugs/sshd/report-mVEeJj.html#EndPath > > > > > > > > > http://lcs.ios.ac.cn/~xuzb/bugsfound/memleak/openssh-5.9p1/realbugs/sshd/report-mVEeJj.html#EndPath > > > > Melton complains that in line 10587 the memory of data wasn't released, > > but there's a call to buffer_free(&data); > > in line 10585. > > Same false positive for 11th, 13th & 14th. > > http://lcs.ios.ac.cn/~xuzb/bugsfound/memleak/openssh-5.9p1/realbugs/sshd/report-UDrpYF.html#EndPath > > http://lcs.ios.ac.cn/~xuzb/bugsfound/memleak/openssh-5.9p1/realbugs/sshd/report-BtfghY.html#EndPath > > http://lcs.ios.ac.cn/~xuzb/bugsfound/memleak/openssh-5.9p1/realbugs/sshd/report-XXMHNK.html#EndPath > > > -- Zhenbo Xu From keisial at gmail.com Mon Feb 6 19:58:20 2012 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Mon, 06 Feb 2012 09:58:20 +0100 Subject: Potential memory leak in sshd [detected by melton] In-Reply-To: References: <4F2EFCD7.9050301@gmail.com> Message-ID: <4F2F962C.1080306@gmail.com> On 06/02/12 03:30, Zhenbo Xu wrote: > > The 10th report is another false positive: > Logic error Memory leak auth-options.i 10587 28 View Report > > > > http://lcs.ios.ac.cn/~xuzb/bugsfound/memleak/openssh-5.9p1/realbugs/sshd/report-mVEeJj.html#EndPath > > > Melton complains that in line 10587 the memory of data wasn't > released, but there's a call to buffer_free(&data); > in line 10585. > > > What melton complains is the heap object returned > by buffer_get_cstring_ret > wasn't > released. You are right. I missed that it was about allowed. However, Melton is doing: > switch (addr_match_cidr_list(remote_ip, > > > 11 > Control jumps to 'case 1:' at line 10525 > > 10524 allowed)) { > 10525 case 1: > 10526 > 10527 xfree(allowed); > 10528 break; > > > 12 > Execution continues on line 10548 > Where it is freed (and add_match_cidr_list can only return -1, 0 or 1 so all cases are covered). Then it seems to do another loop where buffer_get_cstring_ret returns NULL, so nothing was allocated. I still don't see the leak. From zhenbo1987 at gmail.com Mon Feb 6 20:09:10 2012 From: zhenbo1987 at gmail.com (Zhenbo Xu) Date: Mon, 6 Feb 2012 17:09:10 +0800 Subject: Potential memory leak in sshd [detected by melton] In-Reply-To: <4F2F962C.1080306@gmail.com> References: <4F2EFCD7.9050301@gmail.com> <4F2F962C.1080306@gmail.com> Message-ID: 2012/2/6 ?ngel Gonz?lez > On 06/02/12 03:30, Zhenbo Xu wrote: > > The 10th report is another false positive: >> Logic error Memory leak auth-options.i 10587 28 View Report >> http://lcs.ios.ac.cn/~xuzb/bugsfound/memleak/openssh-5.9p1/realbugs/sshd/report-mVEeJj.html#EndPath >> >> Melton complains that in line 10587 the memory of data wasn't released, >> but there's a call to buffer_free(&data); >> in line 10585. >> >> > What melton complains is the heap object returned by > buffer_get_cstring_ret wasn't > released. > > You are right. I missed that it was about allowed. > However, Melton is doing: > > switch (addr_match_cidr_list(remote_ip, > 11 > Control jumps to 'case 1:' at line 10525 > 10524 allowed)) { 10525 case 1: 10526 10527 xfree(allowed); 10528 > break; > 12 > Execution continues on line 10548 > > Where it is freed (and add_match_cidr_list can only return -1, 0 or 1 so > all cases are covered). > > Then it seems to do another loop where buffer_get_cstring_retreturns NULL, so nothing was allocated. > > I still don't see the leak. > > What if line 10511 takes the true branch, and it just "goto out"in line 10514 without releasing allowed. -- Zhenbo Xu From apb at cequrux.com Mon Feb 6 22:26:02 2012 From: apb at cequrux.com (Alan Barrett) Date: Mon, 6 Feb 2012 13:26:02 +0200 Subject: Potential memory leak in sshd [detected by melton] In-Reply-To: <4F2F962C.1080306@gmail.com> References: <4F2EFCD7.9050301@gmail.com> <4F2F962C.1080306@gmail.com> Message-ID: <20120206112602.GC556@apb-laptoy.apb.alt.za> On Mon, 06 Feb 2012, ngel Gonzlez wrote: >> The 10th report is another false positive: >> Logic error Memory leak auth-options.i 10587 28 View Report >> >> >> >> http://lcs.ios.ac.cn/~xuzb/bugsfound/memleak/openssh-5.9p1/realbugs/sshd/report-mVEeJj.html#EndPath >> >> >> Melton complains that in line 10587 the memory of data wasn't >> released, but there's a call to buffer_free(&data); >> in line 10585. Similarly to several of the other cases, this leak occurs only with unusual input. If "source-address" appears twice in the options, then the allocation in line 10505 occurs twice; the first allocation leaks, and the second allocation is freed later. The presence of both "7 Taking true branch" and "21 Taking true branch" at line 10504 is the clue that this leak occurs when "source-address" appears twice. --apb (Alan Barrett) From phribbr at gmail.com Tue Feb 7 23:04:54 2012 From: phribbr at gmail.com (Paulo) Date: Tue, 7 Feb 2012 10:04:54 -0200 Subject: Suggestion for openssh Message-ID: Hi! I do not know if it's the ideal place, but I'm sending some suggestion. Always use openssh and its enormous features. - I needed to create an environment with only sftp access and thus used: - Match User suporte ForceCommand / usr / lib / openssh / sftp-server OK! It worked perfectly! But only sftp. - Create an environment with only blocking the ssh, but scp and sftp access, I used: - Rssh; - Mysecureshell; - Scponly. Work, but change my SHELL, and also created another environment for authentication and this is not good. So I suggest to you developers the following idea: - Create the following options to sshd_config: - DenyCmdssh - DenyCmdscp - DenyCmdsftp All three options above with default value "no". If I want to scp access only could perform the following configuration. - Match User suporte DenyCmdssh yes DenyCmdsftp yes DenyCmdscp no I see that being possible the inclusion of these options, it would kill commands rssh, scponly and mysecureshell and the whole configuration of openssh would just in / etc / ssh / sshd_config. I imagine that working with ChrootDirectory... OK! This was just a suggestion! And thank you for openssh. Thank you! Paulo Henrique Ribeiro From peter at stuge.se Wed Feb 8 01:24:50 2012 From: peter at stuge.se (Peter Stuge) Date: Tue, 7 Feb 2012 15:24:50 +0100 Subject: Suggestion for openssh In-Reply-To: References: Message-ID: <20120207142450.5932.qmail@stuge.se> Paulo wrote: > I see that being possible the inclusion of these options, it would > kill commands rssh, scponly and mysecureshell and the whole > configuration of openssh would just in / etc / ssh / sshd_config. Mh, it's not so easy. Best stick with internal-sftp and chroot for your support. //Peter From nkadel at gmail.com Wed Feb 8 02:07:12 2012 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Tue, 7 Feb 2012 10:07:12 -0500 Subject: Suggestion for openssh In-Reply-To: <20120207142450.5932.qmail@stuge.se> References: <20120207142450.5932.qmail@stuge.se> Message-ID: On Tue, Feb 7, 2012 at 9:24 AM, Peter Stuge wrote: > Paulo wrote: >> I see that being possible the inclusion of these options, it would >> kill commands rssh, scponly and mysecureshell and the whole >> configuration of openssh would just in / etc / ssh / sshd_config. > > Mh, it's not so easy. Best stick with internal-sftp and chroot for > your support. What are you actually trying to achieve? Safe upload/download repositories without shell access or filesysem access except in the relevant direcotry From phribbr at gmail.com Wed Feb 8 06:38:56 2012 From: phribbr at gmail.com (Paulo) Date: Tue, 7 Feb 2012 17:38:56 -0200 Subject: Suggestion for openssh Message-ID: I know this is hard.... I do not have idea how to do it, but imagine the difficulty. I use many ways for acess to ssh. - Some users can acess by ssh normally. - Others can just by sftp (I'd like scp, but without rssh, mysecureshell, scponly) and with chroot, just for transfers. - Others acounts are blocked in DennyHost, but should login by "su - [user]. - Denny users login, but allow authentication(Example: command bbcp use ssh authentication). - etc... I already use another tools for this, with ssh. Remember, this is just one suggestion. Thanks! From mouring at offwriting.org Wed Feb 8 07:43:46 2012 From: mouring at offwriting.org (Ben Lindstrom) Date: Tue, 7 Feb 2012 14:43:46 -0600 Subject: Suggestion for openssh In-Reply-To: References: Message-ID: <2F4791B7-6B4A-49DC-B84F-0146F68AED37@offwriting.org> On Feb 7, 2012, at 6:04 AM, Paulo wrote: > Hi! > > I do not know if it's the ideal place, but I'm sending some suggestion. > Always use openssh and its enormous features. > > - I needed to create an environment with only sftp access and thus used: > > - Match User suporte > ForceCommand / usr / lib / openssh / sftp-server > > OK! It worked perfectly! But only sftp. > > - Create an environment with only blocking the ssh, but scp and sftp > access, I used: > - Rssh; > - Mysecureshell; > - Scponly. > Work, but change my SHELL, and also created another > environment for authentication and this is not good. > > > So I suggest to you developers the following idea: > - Create the following options to sshd_config: > - DenyCmdssh > - DenyCmdscp This is kinda bogus.. "scp" is just a normal program. All the scp command does is the moral equiv of: tar -cvf .. | ssh .. tar -xvf So that deny command isn't possible unless you are looking to block the whole ability to run remote commands. Which has been discussed and the decision was long ago to let it be a shell level issue. As there is no really good way of handling this. Even if the user has a normal shell they can still bluff this behavior via expect scripts. > - DenyCmdsftp This is also bogus because if you deny "sftp" but allow "scp" one can still do: sftp -1 ... which will act like how scp works by ignoring the subsystem definitions. It would be more useful to allow "Subsystem" be allowed in a 'Match' section and ensure 'Subsystem sftp none' or such to remove it from the user's valid subsystem support. Still, not useful to deny subsystems if you still give them access to run remote commands. > All three options above with default value "no". > If I want to scp access only could perform the following configuration. > > - Match User suporte > DenyCmdssh yes > DenyCmdsftp yes > DenyCmdscp no I see above as why this wouldn't block "scp" and why you really need to do it via the shell level. You can look through the history of this mailinglist. This isn't the first time this has come up, and I doubt it will be the last, but in truth this isn't a problem that can be neatly solved in sshd and there are times it is just better to manage it via 3rd party tools. - Ben From john.m.olsson at ericsson.com Wed Feb 8 18:21:05 2012 From: john.m.olsson at ericsson.com (John Olsson M) Date: Wed, 8 Feb 2012 08:21:05 +0100 Subject: Suggestion for openssh In-Reply-To: <2F4791B7-6B4A-49DC-B84F-0146F68AED37@offwriting.org> References: <2F4791B7-6B4A-49DC-B84F-0146F68AED37@offwriting.org> Message-ID: Ben Lindstrom wrote: > It would be more useful to allow "Subsystem" be allowed in a > 'Match' section and ensure 'Subsystem sftp none' or such to > remove it from the user's valid subsystem support. I'm strongly in favor of such an enhancement of OpenSSH. This would also allow for setting a chroot jail per individual subsystem. E.g. sftp chroot:ed but not ssh. :) See also https://bugzilla.mindrot.org/show_bug.cgi?id=1975 /John -----Original Message----- From: openssh-unix-dev-bounces+john.m.olsson=ericsson.com at mindrot.org [mailto:openssh-unix-dev-bounces+john.m.olsson=ericsson.com at mindrot.org] On Behalf Of Ben Lindstrom Sent: den 7 februari 2012 21:44 To: paulo.henrique at cptec.inpe.br Cc: openssh-unix-dev at mindrot.org Subject: Re: Suggestion for openssh On Feb 7, 2012, at 6:04 AM, Paulo wrote: > Hi! > > I do not know if it's the ideal place, but I'm sending some suggestion. > Always use openssh and its enormous features. > > - I needed to create an environment with only sftp access and thus used: > > - Match User suporte > ForceCommand / usr / lib / openssh / sftp-server > > OK! It worked perfectly! But only sftp. > > - Create an environment with only blocking the ssh, but scp and sftp > access, I used: > - Rssh; > - Mysecureshell; > - Scponly. > Work, but change my SHELL, and also created another > environment for authentication and this is not good. > > > So I suggest to you developers the following idea: > - Create the following options to sshd_config: > - DenyCmdssh > - DenyCmdscp This is kinda bogus.. "scp" is just a normal program. All the scp command does is the moral equiv of: tar -cvf .. | ssh .. tar -xvf So that deny command isn't possible unless you are looking to block the whole ability to run remote commands. Which has been discussed and the decision was long ago to let it be a shell level issue. As there is no really good way of handling this. Even if the user has a normal shell they can still bluff this behavior via expect scripts. > - DenyCmdsftp This is also bogus because if you deny "sftp" but allow "scp" one can still do: sftp -1 ... which will act like how scp works by ignoring the subsystem definitions. Still, not useful to deny subsystems if you still give them access to run remote commands. > All three options above with default value "no". > If I want to scp access only could perform the following configuration. > > - Match User suporte > DenyCmdssh yes > DenyCmdsftp yes > DenyCmdscp no I see above as why this wouldn't block "scp" and why you really need to do it via the shell level. You can look through the history of this mailinglist. This isn't the first time this has come up, and I doubt it will be the last, but in truth this isn't a problem that can be neatly solved in sshd and there are times it is just better to manage it via 3rd party tools. - Ben _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From mouring at offwriting.org Thu Feb 9 01:11:03 2012 From: mouring at offwriting.org (Ben Lindstrom) Date: Wed, 8 Feb 2012 08:11:03 -0600 Subject: Suggestion for openssh In-Reply-To: References: <2F4791B7-6B4A-49DC-B84F-0146F68AED37@offwriting.org> Message-ID: <6313BF5A-9C38-46D5-85C9-9C79C33ACC41@offwriting.org> On Feb 8, 2012, at 1:21 AM, John Olsson M wrote: > Ben Lindstrom wrote: >> It would be more useful to allow "Subsystem" be allowed in a >> 'Match' section and ensure 'Subsystem sftp none' or such to >> remove it from the user's valid subsystem support. > > I'm strongly in favor of such an enhancement of OpenSSH. This would also allow for setting a chroot jail per individual subsystem. E.g. sftp chroot:ed but not ssh. :) > > See also https://bugzilla.mindrot.org/show_bug.cgi?id=1975 Completely a different thing then what was being discussed. What was being discussed was allowing say: Match User mouring Subsystem sftp none Subsystem custom /usr/local/bin/custome_subsystem Not a "Match Subsystem ..." - Ben From masmertoz at gmail.com Thu Feb 9 10:11:02 2012 From: masmertoz at gmail.com (Merto Mertek) Date: Thu, 9 Feb 2012 00:11:02 +0100 Subject: Having issues with remote command execution - ssh -t host 'sudo command' Message-ID: I've been trying to find an answer on other sites however I could not resolve my problem. spec: os: ubuntu 10.0, OpenSSH_5.5p1 Debian-4ubuntu4, OpenSSL 0.9.8o problem: When trying to restart deamons on remote pcs having the same specs, sometimes deamons are executed succesfully and sometimes not. I am using the following command: ssh -t -vvv "$host" 'sudo /usr/local/sbin/program' which asks me for a pass and then continues. From the debug log I can see that the difference from a successfull and unsuscesful run depends on sequence of the following code blocks. If successful first runs code block1 and then block2, otherwise the opposite. code1: debug2: channel 0: rcvd eof debug2: channel 0: output open -> drain debug2: channel 0: obuf empty debug2: channel 0: close_write debug2: channel 0: output drain -> closed code2: debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 debug1: client_input_channel_req: channel 0 rtype eow at openssh.com reply 0 debug2: channel 0: rcvd eow debug2: channel 0: close_read debug2: channel 0: input open -> closed Any help appreciated.. thanks From peter at stuge.se Thu Feb 9 21:59:57 2012 From: peter at stuge.se (Peter Stuge) Date: Thu, 9 Feb 2012 11:59:57 +0100 Subject: Having issues with remote command execution - ssh -t host 'sudo command' In-Reply-To: References: Message-ID: <20120209105957.26579.qmail@stuge.se> Merto Mertek wrote: > spec: > os: ubuntu 10.0, OpenSSH_5.5p1 Debian-4ubuntu4, OpenSSL 0.9.8o > > problem: > When trying to restart deamons on remote pcs having the same specs, > sometimes deamons are executed succesfully and sometimes not. The problem happens when stdin, stdout and stderr are not all closed by the daemon. This is very well known. > I am using the following command: > > ssh -t -vvv "$host" 'sudo /usr/local/sbin/program' > > which asks me for a pass and then continues. Instead you should let the ubuntu service manager (upstartd for now) manage your services, and use the commands put in place by the service manager for controlling your services. Avoid starting things manually. Incidentally, if you do make your services run under the service manager then you will also never have the stdio problem. //Peter From alex at alex.org.uk Thu Feb 9 22:30:23 2012 From: alex at alex.org.uk (Alex Bligh) Date: Thu, 09 Feb 2012 11:30:23 +0000 Subject: Having issues with remote command execution - ssh -t host 'sudo command' In-Reply-To: <20120209105957.26579.qmail@stuge.se> References: <20120209105957.26579.qmail@stuge.se> Message-ID: --On 9 February 2012 11:59:57 +0100 Peter Stuge wrote: >> When trying to restart deamons on remote pcs having the same specs, >> sometimes deamons are executed succesfully and sometimes not. > > The problem happens when stdin, stdout and stderr are not all closed > by the daemon. This is very well known. Also: man nohup if you can't use your distro scripts -- Alex Bligh From sonne_meyer at yahoo.de Fri Feb 10 00:08:13 2012 From: sonne_meyer at yahoo.de (Sonja Meyer) Date: Thu, 9 Feb 2012 13:08:13 +0000 (GMT) Subject: Restrict commands available in an SFTP session Message-ID: <1328792893.72760.YahooMailNeo@web28612.mail.ukl.yahoo.com> Hello, i am using SFTP with CHROOT. I want to allow my users that they can upload and download with the sftp server, but they should never do an MKDIR! Is it possible to restrict commands and how can i do this? i only found material of modifing the source...and that is not the best way for me. regards Sonja Meyer sonne_meyer at yahoo.de From peter at stuge.se Fri Feb 10 00:35:53 2012 From: peter at stuge.se (Peter Stuge) Date: Thu, 9 Feb 2012 14:35:53 +0100 Subject: Restrict commands available in an SFTP session In-Reply-To: <1328792893.72760.YahooMailNeo@web28612.mail.ukl.yahoo.com> References: <1328792893.72760.YahooMailNeo@web28612.mail.ukl.yahoo.com> Message-ID: <20120209133553.7033.qmail@stuge.se> Hi Sonja, Sonja Meyer wrote: > i am using SFTP with CHROOT. I want to allow my users that they can > upload and download with the sftp server, but they should never do > an MKDIR! > Is it possible to restrict commands and how can i do this? sftp-server has no provisions for this. > i only found material of modifing the source...and that is not the > best way for me. Maybe you can work with filesystem permissions and ACLs. //Peter From yeremko at gmail.com Sat Feb 11 03:51:52 2012 From: yeremko at gmail.com (Oleksandr Yeremko) Date: Fri, 10 Feb 2012 18:51:52 +0200 Subject: openssh client on Windows 7 key auth issue Message-ID: Dear All, could anybody be so kind and explain me such situation: I set up OpenSSH client on Windows 7. Then I generated keys pair by 'ssh-keygen -t dsa' and with empty (no) passphrase. Then I inserted appropriate info into authorized_keys file on my Unix host. But when I try to connect to my Unix host 'ssh' asks for passphrase for 'id_dsa' and than wants to authenticate by password because 'publickey method is refused - no passphrase is given'. I have no such situation in Windows XP - everything is OK there. What is the problem with Windows 7? Thank you for your time and your help, Oleksandr - Kiev, UKRAINE From dan at doxpara.com Sat Feb 11 06:46:08 2012 From: dan at doxpara.com (Dan Kaminsky) Date: Fri, 10 Feb 2012 14:46:08 -0500 Subject: openssh client on Windows 7 key auth issue In-Reply-To: References: Message-ID: I'm not sure which Windows port of OpenSSH you're using; however, I usually recommend people looking to use SSH on Windows either work with PuTTY or Cygwin's OpenSSH (w/ the rxvt native client). Good luck! --Dan On Fri, Feb 10, 2012 at 11:51 AM, Oleksandr Yeremko wrote: > Dear All, > > could anybody be so kind and explain me such situation: > > I set up OpenSSH client on Windows 7. > Then I generated keys pair by 'ssh-keygen -t dsa' and with empty (no) > passphrase. > Then I inserted appropriate info into authorized_keys file on my Unix host. > But when I try to connect to my Unix host 'ssh' asks for passphrase > for 'id_dsa' and than wants to authenticate by password because > 'publickey method is refused - no passphrase is given'. > > I have no such situation in Windows XP - everything is OK there. > > What is the problem with Windows 7? > > Thank you for your time and your help, > Oleksandr > - > Kiev, UKRAINE > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From dan at doxpara.com Sat Feb 11 06:48:13 2012 From: dan at doxpara.com (Dan Kaminsky) Date: Fri, 10 Feb 2012 14:48:13 -0500 Subject: openssh client on Windows 7 key auth issue In-Reply-To: References: Message-ID: It also may be that the ssh client can't find your generated key. I'd do: ssh-keygen -f id_dsa -t dsa then add id_dsa.pub to authorized keys then ssh -i id_dsa user at host Add "-v -v -v" to ssh if things still don't work. Good luck once more! On Fri, Feb 10, 2012 at 2:46 PM, Dan Kaminsky wrote: > I'm not sure which Windows port of OpenSSH you're using; however, I > usually recommend people looking to use SSH on Windows either work with > PuTTY or Cygwin's OpenSSH (w/ the rxvt native client). > > Good luck! > > --Dan > > > > On Fri, Feb 10, 2012 at 11:51 AM, Oleksandr Yeremko wrote: > >> Dear All, >> >> could anybody be so kind and explain me such situation: >> >> I set up OpenSSH client on Windows 7. >> Then I generated keys pair by 'ssh-keygen -t dsa' and with empty (no) >> passphrase. >> Then I inserted appropriate info into authorized_keys file on my Unix >> host. >> But when I try to connect to my Unix host 'ssh' asks for passphrase >> for 'id_dsa' and than wants to authenticate by password because >> 'publickey method is refused - no passphrase is given'. >> >> I have no such situation in Windows XP - everything is OK there. >> >> What is the problem with Windows 7? >> >> Thank you for your time and your help, >> Oleksandr >> - >> Kiev, UKRAINE >> _______________________________________________ >> openssh-unix-dev mailing list >> openssh-unix-dev at mindrot.org >> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev >> > > From masmertoz at gmail.com Sun Feb 12 07:00:11 2012 From: masmertoz at gmail.com (Merto Mertek) Date: Sat, 11 Feb 2012 21:00:11 +0100 Subject: Having issues with remote command execution - ssh -t host 'sudo command' In-Reply-To: References: <20120209105957.26579.qmail@stuge.se> Message-ID: Thanks both of you for your answer... I've spot an error I made in /etc/init.d/script so now I am able to run it with a 'service' command and everything works fine. I've try to run it with nohup and it works as good too, however like I could read is more appropriate to run it with a service command so that I can afterwards stop it cleanly.. If we return to my initial question.. Does this behavior still exist in newer releases that session is closed no matter what is the status of executed remote commands? On 9 February 2012 12:30, Alex Bligh wrote: > > > --On 9 February 2012 11:59:57 +0100 Peter Stuge wrote: > > When trying to restart deamons on remote pcs having the same specs, >>> sometimes deamons are executed succesfully and sometimes not. >>> >> >> The problem happens when stdin, stdout and stderr are not all closed >> by the daemon. This is very well known. >> > > Also: > man nohup > > if you can't use your distro scripts > > -- > Alex Bligh > > ______________________________**_________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/**mailman/listinfo/openssh-unix-**dev > From gtautvis at gmail.com Mon Feb 13 02:22:09 2012 From: gtautvis at gmail.com (Tautvydas) Date: Sun, 12 Feb 2012 17:22:09 +0200 Subject: PATCH: multiple BindAddress Message-ID: Hello all, I recently have a problem with multiple addresses and address families. Problem is simple, i have some hosts with IPv4 access only and some with IPv6 access. This wouldn't be big problem if I had a stable IP addresses. But sometimes I move to another network with complete different addresses. So I created patch which on option BindAddress accept list of addresses. With ip I solved two main problems: 1. When using "Host *" it is possible to set address from one family (IPv4 or IPv6), ofcource there can be introduced BindAddress4 and BindAddress6 options 2. I can move to another net and there no need do modify ~/.ssh/config file Of course added address called "any" witch means to use any address (like the are no option BindAddress defined) So my config file now looks like: Host * BindAddress 2001:1010:10::1 192.168.0.4 any # means that tries both binds, if everything fail will use any address Host ipv4_only.host IdentityFile ~/.ssh/ipv4 Host ipv6_only.host IdentityFile ~/.ssh/ipv6 Host ipv4_ipv6.host IdentityFile ~/.ssh/secr3t RemoteForward 127.0.0.1:1234 127.0.0.1:1234 DynamicForward 6666 I think is much easier to have BindAddress configuration in top of config file. Thanks, Tautvydas ?elvys -- This patch is made on openssh-5.9p1 version -- diff -rupN orig/openssh-5.9p1/readconf.c openssh-5.9p1/readconf.c --- orig/openssh-5.9p1/readconf.c 2011-05-29 14:42:31.000000000 +0300 +++ openssh-5.9p1/readconf.c 2012-02-12 15:43:43.302048950 +0200 @@ -641,8 +641,10 @@ parse_char_array: goto parse_string; case oBindAddress: - charptr = &options->bind_address; - goto parse_string; + cpptr = (char**)&options->bind_addresses; + uintptr = &options->num_bind_address; + max_entries =SSH_MAX_BIND_ADDRESSES; + goto parse_char_array; case oPKCS11Provider: charptr = &options->pkcs11_provider; @@ -1176,7 +1178,7 @@ initialize_options(Options * options) options->clear_forwardings = -1; options->log_level = SYSLOG_LEVEL_NOT_SET; options->preferred_authentications = NULL; - options->bind_address = NULL; + options->num_bind_address = 0; options->pkcs11_provider = NULL; options->enable_ssh_keysign = - 1; options->no_host_authentication_for_localhost = - 1; diff -rupN orig/openssh-5.9p1/readconf.h openssh-5.9p1/readconf.h --- orig/openssh-5.9p1/readconf.h 2011-05-29 14:42:33.000000000 +0300 +++ openssh-5.9p1/readconf.h 2012-02-12 16:05:42.450092058 +0200 @@ -27,8 +27,12 @@ typedef struct { } Forward; /* Data structure for representing option data. */ -#define MAX_SEND_ENV 256 -#define SSH_MAX_HOSTS_FILES 256 +#define MAX_SEND_ENV 256 +#define SSH_MAX_HOSTS_FILES 256 +#define SSH_MAX_BIND_ADDRESSES 8 /* 16 addresses, should be enough */ + +#define SSH_BIND_ADDRESS_ANY "any" /* any address mark, used in configuration file */ +#define SSH_BIND_ADDRESS_ANYlen strlen(SSH_BIND_ADDRESS_ANY) typedef struct { int forward_agent; /* Forward authentication agent. */ @@ -89,7 +93,10 @@ typedef struct { u_int num_user_hostfiles; /* Path for $HOME/.ssh/known_hosts */ char *user_hostfiles[SSH_MAX_HOSTS_FILES]; char *preferred_authentications; - char *bind_address; /* local socket address for connection to sshd */ + + char *bind_addresses[SSH_MAX_BIND_ADDRESSES]; /* local socket address list for connection to sshd, main reason for this is ipv4 and ipv6 only hosts, when using global host match */ + u_int num_bind_address; /* count of bind_addresses */ + char *pkcs11_provider; /* PKCS#11 provider */ int verify_host_key_dns; /* Verify host key using DNS */ diff -rupN orig/openssh-5.9p1/ssh.c openssh-5.9p1/ssh.c --- orig/openssh-5.9p1/ssh.c 2011-08-05 23:18:16.000000000 +0300 +++ openssh-5.9p1/ssh.c 2012-02-12 15:41:39.446044903 +0200 @@ -595,7 +595,8 @@ main(int ac, char **av) options.control_path = xstrdup(optarg); break; case 'b': - options.bind_address = optarg; + options.bind_addresses[0] = optarg; + options.num_bind_address = 1; break; case 'F': config = optarg; diff -rupN orig/openssh-5.9p1/ssh_config openssh-5.9p1/ssh_config --- orig/openssh-5.9p1/ssh_config 2010-01-12 10:40:27.000000000 +0200 +++ openssh-5.9p1/ssh_config 2012-02-12 16:57:02.150192696 +0200 @@ -45,3 +45,8 @@ # PermitLocalCommand no # VisualHostKey no # ProxyCommand ssh -q -W %h:%p gateway.example.com + +# --Examble of BindAddress +# BindAddress 192.168.0.1 3004:aaaa::beef any +# This means, that ssh tries 192.168.0.1 if fail to bind, next address willbe 3004:aaaa::beef and if it fails, +# uses default bind strategy, bind on any address diff -rupN orig/openssh-5.9p1/ssh_config.5 openssh-5.9p1/ssh_config.5 --- orig/openssh-5.9p1/ssh_config.5 2011-08-05 23:17:32.000000000 +0300 +++ openssh-5.9p1/ssh_config.5 2012-02-12 16:40:31.502160322 +0200 @@ -145,8 +145,10 @@ or The default is .Dq no . .It Cm BindAddress -Use the specified address on the local machine as the source address of -the connection. +Use the specified address (or addresses seperated by space) on the local machine as the source address of +the connection. This list can be interrupted with +.Dq any +address. Only useful on systems with more than one address. Note that this option does not work if .Cm UsePrivilegedPort diff -rupN orig/openssh-5.9p1/sshconnect.c openssh-5.9p1/sshconnect.c --- orig/openssh-5.9p1/sshconnect.c 2011-05-29 14:42:34.000000000 +0300 +++ openssh-5.9p1/sshconnect.c 2012-02-12 16:26:33.986132953 +0200 @@ -189,7 +189,7 @@ ssh_create_socket(int privileged, struct { int sock, gaierr; struct addrinfo hints, *res; - + uint i=0; /* * If we are running as root and want to connect to a privileged * port, bind our own socket to a privileged port. @@ -214,28 +214,61 @@ ssh_create_socket(int privileged, struct fcntl(sock, F_SETFD, FD_CLOEXEC); /* Bind the socket to an alternative local IP address */ - if (options.bind_address == NULL) + if (options.num_bind_address == 0){ return sock; + } - memset(&hints, 0, sizeof(hints)); - hints.ai_family = ai->ai_family; - hints.ai_socktype = ai->ai_socktype; - hints.ai_protocol = ai->ai_protocol; - hints.ai_flags = AI_PASSIVE; - gaierr = getaddrinfo(options.bind_address, NULL, &hints, &res); - if (gaierr) { - error("getaddrinfo: %s: %s", options.bind_address, - ssh_gai_strerror(gaierr)); - close(sock); - return -1; + uint addrfound = 0; + uint last_idx = options.num_bind_address - 1; // last address index + + verbose("Trying %d addresses to connect",options.num_bind_address); + for(i=0;iai_family; + hints.ai_socktype = ai->ai_socktype; + hints.ai_protocol = ai->ai_protocol; + hints.ai_flags = AI_PASSIVE; + gaierr = getaddrinfo(options.bind_addresses[i], NULL, &hints, &res); + if (gaierr) { + error("getaddrinfo: %s: %s", options.bind_addresses[i], + ssh_gai_strerror(gaierr)); + if ( i == last_idx){ + close(sock); + return -1; + } else { + error("We have more addresses, trying next address: %s",options.bind_addresses[i+1]); + continue; + } + } + + if (bind(sock, res->ai_addr, res->ai_addrlen) < 0) { + error("bind: %s: %s", options.bind_addresses[i], strerror(errno)); + if ( i == last_idx){ + close(sock); + freeaddrinfo(res); + return -1; + } else { + error("We have more addresses, trying next address: %s",options.bind_addresses[i+1]); + continue; + } + } else { + addrfound = 1; + break; + } + freeaddrinfo(res); } - if (bind(sock, res->ai_addr, res->ai_addrlen) < 0) { - error("bind: %s: %s", options.bind_address, strerror(errno)); + + if (!addrfound){ + error("no bindable addres is found, exiting"); close(sock); - freeaddrinfo(res); return -1; } - freeaddrinfo(res); return sock; } From jdmossh at nand.net Mon Feb 13 06:48:59 2012 From: jdmossh at nand.net (Jeremy Monin) Date: Sun, 12 Feb 2012 14:48:59 -0500 (EST) Subject: Restrict commands available in an SFTP session In-Reply-To: <20120209133553.7033.qmail@stuge.se> References: <1328792893.72760.YahooMailNeo@web28612.mail.ukl.yahoo.com> <20120209133553.7033.qmail@stuge.se> Message-ID: Hello, I had a similar need, so I've maintained a patch to do just that, with a new sshd_config option that can be global or in a Match block. Could my patch possibly be merged? I'd be grateful for feedback either way. https://bugzilla.mindrot.org/show_bug.cgi?id=1979 Many thanks, Jeremy Monin Sysadmin and open-source developer On Thu, 9 Feb 2012, Peter Stuge wrote: > Date: Thu, 9 Feb 2012 14:35:53 +0100 > From: Peter Stuge > To: openssh-unix-dev at mindrot.org > Subject: Re: Restrict commands available in an SFTP session > > Hi Sonja, > > Sonja Meyer wrote: >> i am using SFTP with CHROOT. I want to allow my users that they can >> upload and download with the sftp server, but they should never do an >> MKDIR! Is it possible to restrict commands and how can i do this? > > sftp-server has no provisions for this. > > >> i only found material of modifing the source...and that is not the >> best way for me. > > Maybe you can work with filesystem permissions and ACLs. > > > //Peter > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From peter at stuge.se Mon Feb 13 07:19:45 2012 From: peter at stuge.se (Peter Stuge) Date: Sun, 12 Feb 2012 21:19:45 +0100 Subject: Restrict commands available in an SFTP session In-Reply-To: References: <1328792893.72760.YahooMailNeo@web28612.mail.ukl.yahoo.com> <20120209133553.7033.qmail@stuge.se> Message-ID: <20120212201945.3999.qmail@stuge.se> Jeremy Monin wrote: > I had a similar need, so I've maintained a patch to do just that, with a > new sshd_config option that can be global or in a Match block. > > Could my patch possibly be merged? I'd be grateful for feedback > either way. I for one like the code but the name really sucks. Long and awkward. :) //Peter From jdmossh at nand.net Mon Feb 13 08:54:53 2012 From: jdmossh at nand.net (Jeremy Monin) Date: Sun, 12 Feb 2012 16:54:53 -0500 (EST) Subject: Restrict commands available in an SFTP session In-Reply-To: <20120212201945.3999.qmail@stuge.se> References: <1328792893.72760.YahooMailNeo@web28612.mail.ukl.yahoo.com> <20120209133553.7033.qmail@stuge.se> <20120212201945.3999.qmail@stuge.se> Message-ID: On Sun, 12 Feb 2012, Peter Stuge wrote: > I for one like the code but the name really sucks. Long and awkward. :) Thank you. It's definitely a klunky name. Maybe something like SFtpBasicsOnly ? The name isn't important of course, just the functionality. -Jeremy From djm at mindrot.org Mon Feb 13 17:51:10 2012 From: djm at mindrot.org (Damien Miller) Date: Mon, 13 Feb 2012 17:51:10 +1100 (EST) Subject: Call for testing: OpenSSH-6.0 Message-ID: Hi, OpenSSH 6.0 is almost ready for release, so we would appreciate testing on as many platforms and systems as possible. This release contains a couple of new features and changes and bug fixes. Testing of the new sandboxed privilege separation mode (see below) would be particularly appreciated. Snapshot releases for portable OpenSSH are available from http://www.mindrot.org/openssh_snap/ The OpenBSD version is available in CVS HEAD: http://www.openbsd.org/anoncvs.html Portable OpenSSH is also available via anonymous CVS using the instructions at http://www.openssh.com/portable.html#cvs or via Mercurial at http://hg.mindrot.org/openssh Running the regression tests supplied with Portable OpenSSH does not require installation and is a simply: $ ./configure && make tests Live testing on suitable non-production systems is also appreciated. Please send reports of success or failure to openssh-unix-dev at mindrot.org. Below is a summary of changes. More detail may be found in the ChangeLog in the portable OpenSSH tarballs. Thanks to the many people who contributed to this release. ------------------------------- Features: * ssh-keygen(1): Add optional checkpoints for moduli screening * ssh-add(1): new -k option to load plain keys (skipping certificates) * sshd(8): Add wildcard support to PermitOpen, allowing things like "PermitOpen localhost:*". bz #1857 * ssh(1): support for cancelling local and remote port forwards via the multiplex socket. Use ssh -O cancel -L xx:xx:xx -R yy:yy:yy user at host" to request the cancellation of the specified forwardings * support cancellation of local/dynamic forwardings from ~C commandline Bugfixes: * ssh(1): ensure that $DISPLAY contains only valid characters before using it to extract xauth data so that it can't be used to play local shell metacharacter games. * ssh(1): unbreak remote portforwarding with dynamic allocated listen ports * scp(1): uppress adding '--' to remote commandlines when the first argument does not start with '-'. saves breakage on some difficult-to-upgrade embedded/router platforms * ssh(1)/sshd(8): fix typo in IPQoS parsing: there is no "AF14" class, but there is an "AF21" class * ssh(1)/sshd(8): do not permit SSH2_MSG_SERVICE_REQUEST/ACCEPT during rekeying * ssh(1): skip attempting to create ~/.ssh when -F is passed * sshd(8): unbreak stdio forwarding when ControlPersist is in use; bz#1943 * sshd(1): send tty break to pty master instead of (probably already closed) slave side; bz#1859 * sftp(1): silence error spam for "ls */foo" in directory with files; bz#1683 * Fixed a number of memory and file descriptor leaks Portable OpenSSH: * ssh-keygen(1): don't fail in -A on platforms that don't support ECC * Add optional support for LDNS, a BSD licensed DNS resolver library which supports DNSSEC Reporting Bugs: =============== - Please read http://www.openssh.com/report.html Security bugs should be reported directly to openssh at openssh.com OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de Raadt, Kevin Steves, Damien Miller, Darren Tucker, Jason McIntyre, Tim Rice and Ben Lindstrom. From djm at mindrot.org Mon Feb 13 17:55:46 2012 From: djm at mindrot.org (Damien Miller) Date: Mon, 13 Feb 2012 17:55:46 +1100 (EST) Subject: Call for testing: OpenSSH-6.0 In-Reply-To: References: Message-ID: On Mon, 13 Feb 2012, Damien Miller wrote: > Hi, > > OpenSSH 6.0 is almost ready for release, so we would appreciate testing > on as many platforms and systems as possible. This release contains a > couple of new features and changes and bug fixes. Testing of the new > sandboxed privilege separation mode (see below) would be particularly > appreciated. oops, the bit about the sandboxed privsep code is a carryover from the previous release and isn't mentioned in the feature list below after all. It could still do with some more testing though, as I don't recall seeing any reports from users who tried it. -d From fredports at mufley.com Mon Feb 13 21:16:43 2012 From: fredports at mufley.com (fredports) Date: Mon, 13 Feb 2012 11:16:43 +0100 Subject: Call for testing: OpenSSH-6.0 In-Reply-To: References: Message-ID: <8b0603f7c53dca122fb2c42e2dc02db9@www.mufley.com> Hi there... I have run now the tests on: 8.2-RELEASE-p5 FreeBSD 8.2-RELEASE-p5 #0 and all tests passed. Frederico On 2012-02-13 07:55, Damien Miller wrote: > On Mon, 13 Feb 2012, Damien Miller wrote: > >> Hi, >> >> OpenSSH 6.0 is almost ready for release, so we would appreciate >> testing >> on as many platforms and systems as possible. This release contains >> a >> couple of new features and changes and bug fixes. Testing of the new >> sandboxed privilege separation mode (see below) would be >> particularly >> appreciated. > > oops, the bit about the sandboxed privsep code is a carryover from > the > previous release and isn't mentioned in the feature list below after > all. > It could still do with some more testing though, as I don't recall > seeing > any reports from users who tried it. > > -d > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From fredports at mufley.com Mon Feb 13 21:18:37 2012 From: fredports at mufley.com (fredports) Date: Mon, 13 Feb 2012 11:18:37 +0100 Subject: Call for testing: OpenSSH-6.0 In-Reply-To: <8b0603f7c53dca122fb2c42e2dc02db9@www.mufley.com> References: <8b0603f7c53dca122fb2c42e2dc02db9@www.mufley.com> Message-ID: <69c61a522cada84214d7b7f1ed6c82d7@www.mufley.com> I should have mentioned that i have used the snapshot: openssh-SNAP-20120213.tar.gz BR Frederico On 2012-02-13 11:16, fredports wrote: > Hi there... > > I have run now the tests on: > > 8.2-RELEASE-p5 FreeBSD 8.2-RELEASE-p5 #0 > > and all tests passed. > > Frederico > > On 2012-02-13 07:55, Damien Miller wrote: >> On Mon, 13 Feb 2012, Damien Miller wrote: >> >>> Hi, >>> >>> OpenSSH 6.0 is almost ready for release, so we would appreciate >>> testing >>> on as many platforms and systems as possible. This release contains >>> a >>> couple of new features and changes and bug fixes. Testing of the >>> new >>> sandboxed privilege separation mode (see below) would be >>> particularly >>> appreciated. >> >> oops, the bit about the sandboxed privsep code is a carryover from >> the >> previous release and isn't mentioned in the feature list below after >> all. >> It could still do with some more testing though, as I don't recall >> seeing >> any reports from users who tried it. >> >> -d >> _______________________________________________ >> openssh-unix-dev mailing list >> openssh-unix-dev at mindrot.org >> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From christophe at garault.org Mon Feb 13 22:50:07 2012 From: christophe at garault.org (Christophe Garault) Date: Mon, 13 Feb 2012 12:50:07 +0100 Subject: Call for testing: OpenSSH-6.0 In-Reply-To: References: Message-ID: <4F38F8EF.2040102@garault.org> Le 13/02/2012 07:51, Damien Miller a ?crit : > ------------------------------- > > Features: > > * ssh-keygen(1): Add optional checkpoints for moduli screening > Hello ssh users, I've used that new feature a lot and posted the smallest patch ever to preserve tested primes between sessions: https://bugzilla.mindrot.org/show_bug.cgi?id=1957 Christophe Garault From vinschen at redhat.com Tue Feb 14 01:05:35 2012 From: vinschen at redhat.com (Corinna Vinschen) Date: Mon, 13 Feb 2012 15:05:35 +0100 Subject: Call for testing: OpenSSH-6.0 In-Reply-To: References: Message-ID: <20120213140535.GC7809@calimero.vinschen.de> On Feb 13 17:51, Damien Miller wrote: > Hi, > > OpenSSH 6.0 is almost ready for release, so we would appreciate testing > on as many platforms and systems as possible. This release contains a > couple of new features and changes and bug fixes. Testing of the new > sandboxed privilege separation mode (see below) would be particularly > appreciated. All tests pass on Cygwin. However, is it possible to apply the below patch before releasing 6.0? It just added back an important system environment variable for native Windows apps. Thanks, Corinna Index: openbsd-compat/bsd-cygwin_util.c =================================================================== RCS file: /cvs/openssh/openbsd-compat/bsd-cygwin_util.c,v retrieving revision 1.23 diff -u -p -r1.23 bsd-cygwin_util.c --- openbsd-compat/bsd-cygwin_util.c 17 Aug 2011 01:31:09 -0000 1.23 +++ openbsd-compat/bsd-cygwin_util.c 13 Feb 2012 13:45:21 -0000 @@ -76,6 +76,7 @@ static struct wenv { { NL("OS=") }, { NL("PATH=") }, { NL("PATHEXT=") }, + { NL("PROGRAMFILES=") }, { NL("SYSTEMDRIVE=") }, { NL("SYSTEMROOT=") }, { NL("WINDIR=") } -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From keisial at gmail.com Tue Feb 14 03:59:25 2012 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Mon, 13 Feb 2012 17:59:25 +0100 Subject: Call for testing: OpenSSH-6.0 In-Reply-To: References: Message-ID: <4F39416D.3010806@gmail.com> ./configure is failing for me with > ... > configure: creating ./config.status > config.status: creating Makefile > config.status: creating buildpkg.sh > config.status: creating opensshd.init > config.status: creating openssh.xml > config.status: creating openbsd-compat/Makefile > config.status: creating openbsd-compat/regress/Makefile > config.status: creating survey.sh > config.status: error: cannot find input file: `config.h.in' Is it expected to fail with autoconf 2.68? Also, not too important, but the following files have execute permissions, and I don't think they should: - ssh-sandbox.h - openbsd-compat/sha2.h - openbsd-compat/sha2.c - contrib/solaris/README - opensshd.init.in Although I'm not sure about the last one, it may have it on purpose for having opensshd.init inherit the +x, even though that's not happening in my system. From djm at mindrot.org Tue Feb 14 06:31:05 2012 From: djm at mindrot.org (Damien Miller) Date: Tue, 14 Feb 2012 06:31:05 +1100 (EST) Subject: Call for testing: OpenSSH-6.0 In-Reply-To: <4F39416D.3010806@gmail.com> References: <4F39416D.3010806@gmail.com> Message-ID: On Mon, 13 Feb 2012, ?ngel Gonz?lez wrote: > ./configure is failing for me with > > ... > > configure: creating ./config.status > > config.status: creating Makefile > > config.status: creating buildpkg.sh > > config.status: creating opensshd.init > > config.status: creating openssh.xml > > config.status: creating openbsd-compat/Makefile > > config.status: creating openbsd-compat/regress/Makefile > > config.status: creating survey.sh > > config.status: error: cannot find input file: `config.h.in' > Is it expected to fail with autoconf 2.68? No, that's what I use to generate configure. The tarball ships with a config.h.in so generated. Are you forgetting to run autoheader? > Also, not too important, but the following files have execute permissions, > and I don't think they should: > - ssh-sandbox.h > - openbsd-compat/sha2.h > - openbsd-compat/sha2.c > - contrib/solaris/README Fixed - thanks -d From djm at mindrot.org Tue Feb 14 06:38:48 2012 From: djm at mindrot.org (Damien Miller) Date: Tue, 14 Feb 2012 06:38:48 +1100 (EST) Subject: Call for testing: OpenSSH-6.0 In-Reply-To: <20120213140535.GC7809@calimero.vinschen.de> References: <20120213140535.GC7809@calimero.vinschen.de> Message-ID: On Mon, 13 Feb 2012, Corinna Vinschen wrote: > On Feb 13 17:51, Damien Miller wrote: > > Hi, > > > > OpenSSH 6.0 is almost ready for release, so we would appreciate testing > > on as many platforms and systems as possible. This release contains a > > couple of new features and changes and bug fixes. Testing of the new > > sandboxed privilege separation mode (see below) would be particularly > > appreciated. > > All tests pass on Cygwin. However, is it possible to apply the below > patch before releasing 6.0? It just added back an important system > environment variable for native Windows apps. Done -d From keisial at gmail.com Tue Feb 14 10:03:20 2012 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Tue, 14 Feb 2012 00:03:20 +0100 Subject: Call for testing: OpenSSH-6.0 In-Reply-To: References: <4F39416D.3010806@gmail.com> Message-ID: <4F3996B8.2000005@gmail.com> On 13/02/12 20:31, Damien Miller wrote: > No, that's what I use to generate configure. The tarball ships with a > config.h.in so generated. Are you forgetting to run autoheader? Yes. I had only run autoconf. Either autoconf + autoheader or autoreconf is needed. My fault. It compiles and passes all tests now. Some tests run utils which show error messages, though. regress/copy2: Not a directory rm: cannot remove `.': Is a directory rm: cannot remove `..': Is a directory rm: cannot remove `.': Is a directory rm: cannot remove `..': Is a directory which: no time in ($PATH) >> Also, not too important, but the following files have execute permissions, >> and I don't think they should: >> - ssh-sandbox.h >> - openbsd-compat/sha2.h >> - openbsd-compat/sha2.c >> - contrib/solaris/README > Fixed - thanks > > -d Ok. Thanks. From tim at multitalents.net Tue Feb 14 10:53:51 2012 From: tim at multitalents.net (Tim Rice) Date: Mon, 13 Feb 2012 15:53:51 -0800 (PST) Subject: Call for testing: OpenSSH-6.0 In-Reply-To: <4F3996B8.2000005@gmail.com> References: <4F39416D.3010806@gmail.com> <4F3996B8.2000005@gmail.com> Message-ID: On Tue, 14 Feb 2012, ?ngel Gonz?lez wrote: > Some tests run utils which show error messages, though. > regress/copy2: Not a directory > rm: cannot remove `.': Is a directory > rm: cannot remove `..': Is a directory > rm: cannot remove `.': Is a directory > rm: cannot remove `..': Is a directory These are to be expected. > which: no time in ($PATH) What platform are you on that does not have time(1)? -- Tim Rice Multitalents tim at multitalents.net From loganaden at gmail.com Thu Feb 16 20:11:40 2012 From: loganaden at gmail.com (Loganaden Velvindron) Date: Thu, 16 Feb 2012 13:11:40 +0400 Subject: Pending enhancement (permitOpen none) Message-ID: The tree is now unlocked, and the diff got 1 ok: https://bugzilla.mindrot.org/show_bug.cgi?id=1949 :-) -- Brightest day, Blackest night, No bug shall escape my sight, And those who worship evil's mind, be wary of my powers, puffy lantern's light ! From pcerny at suse.cz Sat Feb 18 11:39:14 2012 From: pcerny at suse.cz (Petr Cerny) Date: Sat, 18 Feb 2012 01:39:14 +0100 Subject: Call for testing: OpenSSH-6.0 In-Reply-To: References: Message-ID: <4F3EF332.8080101@suse.cz> Damien Miller wrote: > On Mon, 13 Feb 2012, Damien Miller wrote: > >> Hi, >> >> OpenSSH 6.0 is almost ready for release, so we would appreciate testing >> on as many platforms and systems as possible. This release contains a >> couple of new features and changes and bug fixes. Testing of the new >> sandboxed privilege separation mode (see below) would be particularly >> appreciated. > > oops, the bit about the sandboxed privsep code is a carryover from the > previous release and isn't mentioned in the feature list below after all. > It could still do with some more testing though, as I don't recall seeing > any reports from users who tried it. openssh-SNAP-20120213.tar.gz: testsuite passes on: SUSE Linux Enterprise 11: x86-64 openSUSE/Factory (reasonably "cutting edge" repository): x86-64 Slackware-current: x86-32 I have also tried to run the testsuite in our automated build environment (to test several architectures and distributions), but all failed with at least of the following errors: 1) test connection multiplexing: status 4 test connection multiplexing: status 5 test connection multiplexing: status 44 Master running (pid=14631) Exit request sent. failed connection multiplexing make[1]: *** [t-exec] Error 1 2) key option proto 1 from="127.0.0.1" not allowed but should be key option proto 1 from="127.0.0.0/8" key option proto 2 from="127.0.0.1" key option proto 2 from="127.0.0.1" not allowed but should be key option proto 2 from="127.0.0.0/8" failed key options make[1]: *** [t-exec] Error 1 3) test try ciphers: proto 2 cipher acss at openssh.org mac hmac-sha2-512-96 ok try ciphers run test yes-head.sh ... ok yes pipe head run test login-timeout.sh ... FATAL: no sshd running on port 4242 make[1]: *** [t-exec] Error 1 I think these problems could be related to some missing system functionality that is generally not required in the build environment for building (e.g. it could be a missing or incorectly set up network interface). The build environment is usually a chroot or a VM (which in turn may be running in LPAR in the case of S/390, AFAIK). Can you give me a hint what could be the problem behind these errors? Thanks Kind regards Petr -- Petr Cerny Mozilla/OpenSSH maintainer for SUSE Linux From des at des.no Tue Feb 21 02:17:54 2012 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Mon, 20 Feb 2012 16:17:54 +0100 Subject: Call for testing: OpenSSH-6.0 References: Message-ID: <868vjxbkkd.fsf@ds4.des.no> [resent without troublesome attachments] Damien Miller writes: > OpenSSH 6.0 is almost ready for release, so we would appreciate testing > on as many platforms and systems as possible. This release contains a > couple of new features and changes and bug fixes. Testing of the new > sandboxed privilege separation mode (see below) would be particularly > appreciated. openssh-SNAP-20120221 fails to build on FreeBSD 9 and 10: the configure script incorrectly concludes that FreeBSD doesn't have openpty(3), and bsd-openpty.c doesn't build on FreeBSD. See http://www.des.no/openssh/ The same snapshot builds fine and passes all tests on 8.2p3. BTW, what about my ssh-agent reference-counting patch? :) DES -- Dag-Erling Sm?rgrav - des at des.no From kevin.brott at gmail.com Tue Feb 21 12:07:27 2012 From: kevin.brott at gmail.com (Kevin Brott) Date: Mon, 20 Feb 2012 17:07:27 -0800 Subject: Call for testing: OpenSSH-6.0 In-Reply-To: References: Message-ID: On Sun, Feb 12, 2012 at 22:51, Damien Miller wrote: > Hi, > > OpenSSH 6.0 is almost ready for release, so we would appreciate testing > on as many platforms and systems as possible. This release contains a > couple of new features and changes and bug fixes. Testing of the new > sandboxed privilege separation mode (see below) would be particularly > appreciated. > > ... Using openssh-SNAP-20120221.tar.gz ./configure && make tests OS Build_Target CC OpenSSL BUILD TEST ============== =========================== ================ ================= ===== ====================== RH 6.2 i686-pc-linux-gnu egcs 2.91.66 0.9.8j YES All tests passed RH 8.0 i686-pc-linux-gnu gcc 3.2.2-5 0.9.7a YES All tests passed RHEL 2.1 i686-pc-linux-gnu gcc 2.96-129.7.2 0.9.6b YES All tests passed RHEL 3.0 i686-pc-linux-gnu gcc 3.2.3-20 0.9.7a YES All tests passed RHEL 4.0 tu6 i686-pc-linux-gnu gcc 3.4.6 0.9.7a YES All tests passed RHEL 4.0 nu8 x86_64-unknown-linux-gnu gcc 3.4.6-8 0.9.7a YES All tests passed RHEL 4.0 nu7 powerpc64-unknown-linux-gnu gcc 3.4.6 0.9.7a YES All tests passed RHEL 5.1 x86_64-redhat-linux gcc 4.1.2-14 0.9.8b YES All tests passed RHEL 5.4 i686-pc-linux-gnu gcc 4.1.2-46 0.9.8e-fips-rhel5 YES All tests passed RHEL 5.5 i686-pc-linux-gnu gcc 4.1.2-48 0.9.8e-fips-rhel5 YES All tests passed RHEL 5.5 x86_64-redhat-linux gcc 4.1.2-48 0.9.8e-fips-rhel5 YES All tests passed RHEL 5.6 i686-pc-linux-gnu gcc 4.1.2-50 0.9.8e-fips-rhel5 YES All tests passed RHEL 5.6 x86_64-redhat-linux gcc 4.1.2-50 0.9.8e-fips-rhel5 YES All tests passed RHEL 5.7 i686-redhat-linux gcc 4.1.2-51 0.9.8e-fips-rhel5 YES All tests passed RHEL 5.7 x86_64-redhat-linux gcc 4.1.2-51 0.9.8e-fips-rhel5 YES All tests passed Fedora Core r2 i686-pc-linux-gnu gcc 3.3.3-7 0.9.7a YES All tests passed Ubuntu 8.04.04 i686-pc-linux-gnu gcc 4.2.4-1ubuntu4 0.9.8g YES All tests passed Ubuntu 10.10 x86_64-linux-gnu gcc 4.4.4-14ubuntu5 0.9.8o YES All tests passed AIX 5200-10-04 powerpc-ibm-aix5.2.0.0 gcc 3.3.2 0.9.8f YES All tests passed AIX 5300-12-02 powerpc-ibm-aix5.3.0.0 gcc 4.0.0 0.9.8m YES All tests passed AIX 6100-04-06 powerpc-ibm-aix6.1.0.0 gcc 4.2.0 0.9.8k YES All tests passed AIX 7100-01-01 powerpc-ibm-aix7.1.0.0 xlc 11.1.0.6 0.9.8m YES All tests passed HP-UX 11.11 hppa2.0w-hp-hpux11.11 gcc 3.4.3 0.9.7m YES All tests passed HP-UX 11.23 ia64-hp-hpux11.23 gcc 4.1.1 0.9.8o YES All tests passed HP-UX 11.31 ia64-hp-hpux11.31 gcc 4.3.3 0.9.8n YES All tests passed HP-UX 11.31 ia64-hp-hpux11.31 C/aC++ A.06.20 0.9.8n YES All tests passed RH Red Hat RHEL Red Hat Enterprise Linux Non-prod usage testing in progress. -- # include /* Kevin Brott */ From des at des.no Tue Feb 21 22:40:31 2012 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Tue, 21 Feb 2012 12:40:31 +0100 Subject: chroot directory ownership Message-ID: <86wr7g9zyo.fsf@ds4.des.no> Currently, sshd requires the chroot directory to be owned by root. This makes it impossible to chroot users into their own home directory, which would be convenient for sftp-only users. Is there a particular reason why, in safely_chroot() in session.c, if (st.st_uid != 0 || (st.st_mode & 022) != 0) fatal("bad ownership or modes for chroot " "directory %s\"%s\"", cp == NULL ? "" : "component ", component); can't be changed to if ((st.st_uid != 0 && st.st_uid != uid) || (st.st_mode & 022) != 0) fatal("bad ownership or modes for chroot " "directory %s\"%s\"", cp == NULL ? "" : "component ", component); ? DES -- Dag-Erling Sm?rgrav - des at des.no From ldv at altlinux.org Tue Feb 21 23:22:53 2012 From: ldv at altlinux.org (Dmitry V. Levin) Date: Tue, 21 Feb 2012 16:22:53 +0400 Subject: chroot directory ownership In-Reply-To: <86wr7g9zyo.fsf@ds4.des.no> References: <86wr7g9zyo.fsf@ds4.des.no> Message-ID: <20120221122253.GA18039@altlinux.org> On Tue, Feb 21, 2012 at 12:40:31PM +0100, Dag-Erling Sm?rgrav wrote: > Currently, sshd requires the chroot directory to be owned by root. This > makes it impossible to chroot users into their own home directory, which > would be convenient for sftp-only users. Is there a particular reason > why, in safely_chroot() in session.c, > > if (st.st_uid != 0 || (st.st_mode & 022) != 0) > fatal("bad ownership or modes for chroot " > "directory %s\"%s\"", > cp == NULL ? "" : "component ", component); Most likely, this was made to ensure that the chroot directory itself is not writable and cannot be made writable by the user, to avoid various kinds of attacks. -- ldv -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From des at des.no Wed Feb 22 00:13:45 2012 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Tue, 21 Feb 2012 14:13:45 +0100 Subject: chroot directory ownership In-Reply-To: <20120221122253.GA18039@altlinux.org> (Dmitry V. Levin's message of "Tue, 21 Feb 2012 16:22:53 +0400") References: <86wr7g9zyo.fsf@ds4.des.no> <20120221122253.GA18039@altlinux.org> Message-ID: <86sji49vna.fsf@ds4.des.no> "Dmitry V. Levin" writes: > Most likely, this was made to ensure that the chroot directory itself is > not writable and cannot be made writable by the user, to avoid various > kinds of attacks. Sure, but *which* attacks? Currently, if I don't want sftp-only users to see eachother's home directories, I have to have two levels of directories: /home/$USER owned by root and /home/$USER/$USER owned by the user. Alternatively (note: I haven't tested this) I can chmod o-rw /home so users can't ls /home but can still access /home/$USER, but they'll be able to tell whether other directories exist because they will get EPERM instead of ENOENT. Not a big deal, perhaps, but wouldn't it be simpler if you could just chroot users to their ~? DES -- Dag-Erling Sm?rgrav - des at des.no From mwlucas at blackhelicopters.org Wed Feb 22 00:56:50 2012 From: mwlucas at blackhelicopters.org (Michael W. Lucas) Date: Tue, 21 Feb 2012 08:56:50 -0500 Subject: any hope for bug 1663 or similar function? Message-ID: <20120221135650.GA74606@bewilderbeast.blackhelicopters.org> Hi folks, Is there any hope for an external source of public keys, such as given in bug 1663? I have dozens of servers, and I have to patch sshd on the vast majority of them. OpenSSH is a BSD program, but the BSD boxes are the most difficult to manage because of this. Thanks, ==ml -- Michael W. Lucas http://www.MichaelWLucas.com/, http://blather.MichaelWLucas.com/ Latest book: SSH Mastery http://www.michaelwlucas.com/nonfiction/ssh-mastery mwlucas at BlackHelicopters.org, Twitter @mwlauthor From keisial at gmail.com Wed Feb 22 01:10:52 2012 From: keisial at gmail.com (=?UTF-8?B?w4FuZ2VsIEdvbnrDoWxleg==?=) Date: Tue, 21 Feb 2012 15:10:52 +0100 Subject: chroot directory ownership In-Reply-To: <86sji49vna.fsf@ds4.des.no> References: <86wr7g9zyo.fsf@ds4.des.no> <20120221122253.GA18039@altlinux.org> <86sji49vna.fsf@ds4.des.no> Message-ID: <4F43A5EC.2020505@gmail.com> On 21/02/12 14:13, Dag-Erling Sm?rgrav wrote: > "Dmitry V. Levin" writes: >> Most likely, this was made to ensure that the chroot directory itself is >> not writable and cannot be made writable by the user, to avoid various >> kinds of attacks. > Sure, but *which* attacks? > > Currently, if I don't want sftp-only users to see eachother's home > directories, I have to have two levels of directories: /home/$USER owned > by root and /home/$USER/$USER owned by the user. Alternatively (note: I > haven't tested this) I can chmod o-rw /home so users can't ls /home but > can still access /home/$USER, but they'll be able to tell whether other > directories exist because they will get EPERM instead of ENOENT. Not a > big deal, perhaps, but wouldn't it be simpler if you could just chroot > users to their ~? > > DES Just one example. If the user is the owner of /, he could move away /etc and replace it with its own one, providing a /etc/passwd under its control. You may think a user-owned chroot is not a problem for your setup, and it may not be, or there may be a way you don't yet known (or opened by a config change). Having a root-owned / is *much* safer. From Roman.Fiedler at ait.ac.at Wed Feb 22 01:34:32 2012 From: Roman.Fiedler at ait.ac.at (Fiedler Roman) Date: Tue, 21 Feb 2012 15:34:32 +0100 Subject: AW: chroot directory ownership In-Reply-To: <4F43A5EC.2020505@gmail.com> References: <86wr7g9zyo.fsf@ds4.des.no> <20120221122253.GA18039@altlinux.org> <86sji49vna.fsf@ds4.des.no> <4F43A5EC.2020505@gmail.com> Message-ID: <9F69795E29C890408AC2DAF646C89BB379D12D3DD5@MAILBOX.arc.local> > DES > Just one example. > If the user is the owner of /, he could move away /etc and replace it with > its own one, providing a /etc/passwd under its control. > > You may think a user-owned chroot is not a problem for your setup, and it > may not be, or there may be a way you don't yet known (or opened by a > config > change). Having a root-owned / is *much* safer. With sftp, most likely attack scenario might be local code execution, where user had only sftp access. With user-writeable chroot, minor programming errors might allow such a task, e.g. * sftp or libc might load locale info or translations from untrusted files (changing normal print to format string vuln) * Buffer overflows reading locale/translation file info, e.g. by placing a 4GB+something locale files * A memory error, e.g. double free, in sftp - which would have be caught by libc -- might trigger loading of another shared library, e.g. the result in http://www.cvedetails.com/cve/CVE-2012-0031/ These additional attacks are not possible with non-writeable root. Kind regards, Roman From kak at cisco.com Fri Feb 24 05:25:40 2012 From: kak at cisco.com (Keith Kaple) Date: Thu, 23 Feb 2012 13:25:40 -0500 Subject: FIPS fix for signature verification in ssh-rsa.c Message-ID: <20120223182540.GB6046@cisco.com> code version referenced: openssh-5.9p1 Hi all, When building openssh with openssl (specifically versions newer than openssl 0.9.8q), there is an issue if FIPS mode is active for openssl. In ssh-rsa.c on line 243 RSA_public_decrypt is called, which is disallowed now in openssl (if in FIPS mode). The library requires appliactions to use the EVP API if running in FIPS mode so it can disallow certain cipher suites and hash algorithms that are not considered FIPS compliant. The user experience is that the scp/ssh client fails because RSA_public_decrypt just returns null if FIPS mode is active in openssl > 0.9.8q. I have a fix, essentially just check for FIPS mode in ssh-rsa.c and appropriately call a new function which uses the EVP API of openssl. I'll be putting this fix in the fedora based rpm we're using in our appliance based product, but also wanted to offer the fix here so it can propogate to future linux distro releases. This is my first source modification of openssh so I'm not sure what I need to do to get approval/acceptance of the change or how to commit it, please let me know what the process is... thanks, Keith From dtucker at zip.com.au Fri Feb 24 10:27:50 2012 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 24 Feb 2012 10:27:50 +1100 Subject: Solaris BSM audit support In-Reply-To: <9C50C7EBEE767343AB45090430D1E3A101029EABEB38@exch-07.centrify.com> References: <9C50C7EBEE767343AB45090430D1E3A101029EABEB38@exch-07.centrify.com> Message-ID: On Wed, Jan 25, 2012 at 7:22 AM, Leo Liou wrote: > Does anyone know if openssh has removed the experimental designation for ?BSM audit support for Solaris systems? > If so, which release, please. No, but it's been present in the code for a long time. I no longer have cause to use it, but if folks pipe up report that they a) use it and b) it works then we can probably remove it. -- 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 leo.liou at centrify.com Fri Feb 24 12:34:06 2012 From: leo.liou at centrify.com (Leo Liou) Date: Thu, 23 Feb 2012 17:34:06 -0800 Subject: Solaris BSM audit support In-Reply-To: References: <9C50C7EBEE767343AB45090430D1E3A101029EABEB38@exch-07.centrify.com> Message-ID: <9C50C7EBEE767343AB45090430D1E3A101029EABED2D@exch-07.centrify.com> Thanks for responding. Yes. We are software vendor (www.centrify.com). I have several customers asked me about this - they would like to use openssh rather than Sun's stock sshd which has other (unrelated) issues. BSM is the issue that stands in the way right now. They saw the experimental designation, and just backed off, hence the email to you. So, I think the point is if they run into issue, can they (or we) get some help to look into it and possibly get fix. Thanks. -----Original Message----- From: dtucker at dtucker.net [mailto:dtucker at dtucker.net] On Behalf Of Darren Tucker Sent: Thursday, February 23, 2012 3:28 PM To: Leo Liou Cc: openssh-unix-dev at mindrot.org Subject: Re: Solaris BSM audit support On Wed, Jan 25, 2012 at 7:22 AM, Leo Liou wrote: > Does anyone know if openssh has removed the experimental designation for ?BSM audit support for Solaris systems? > If so, which release, please. No, but it's been present in the code for a long time. I no longer have cause to use it, but if folks pipe up report that they a) use it and b) it works then we can probably remove it. -- 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 peter at stuge.se Fri Feb 24 13:06:36 2012 From: peter at stuge.se (Peter Stuge) Date: Fri, 24 Feb 2012 03:06:36 +0100 Subject: Solaris BSM audit support In-Reply-To: <9C50C7EBEE767343AB45090430D1E3A101029EABED2D@exch-07.centrify.com> References: <9C50C7EBEE767343AB45090430D1E3A101029EABEB38@exch-07.centrify.com> <9C50C7EBEE767343AB45090430D1E3A101029EABED2D@exch-07.centrify.com> Message-ID: <20120224020636.30099.qmail@stuge.se> Leo Liou wrote: > We are software vendor (www.centrify.com). .. > I think the point is if they run into issue, can they (or we) get > some help to look into it and possibly get fix. I think if your customers want the feature and you discover that there is an issue then the software vendor (that's you) has to fix it. //Peter From saku at ytti.fi Fri Feb 24 21:25:25 2012 From: saku at ytti.fi (Saku Ytti) Date: Fri, 24 Feb 2012 12:25:25 +0200 Subject: ssh-agent use in different security domains In-Reply-To: <20111027073613.GA1500@apb-laptoy.apb.alt.za> References: <4EA85490.2010303@fifthhorseman.net> <4EA85B3E.9050303@fifthhorseman.net> <4EA8731B.9020906@fifthhorseman.net> <260FB869588EFDFDDAF3B07C@nimrod.local> <20111027073613.GA1500@apb-laptoy.apb.alt.za> Message-ID: <20120224102525.GA25545@pob.ytti.fi> I just had discussion about another usage case for ssh agent forwarding, which I'm not sure ProxyCommand can fix, am I missing something, or is there after all usage case for agent forwarding? Consider this: http://www.asciiflow.com/#7099563569916439048/817014389 How can you scp file from c to d, when you're sitting on a. a is in internet and has low speed connection b is secure jump box c,d can't be reached from internet, but can reach each other directly You don't want to pull file to a, but do it directly to c->d. With agent forwarding you could do a% ssh b ssh c scp file d: -- ++ytti From apb at cequrux.com Fri Feb 24 22:05:29 2012 From: apb at cequrux.com (Alan Barrett) Date: Fri, 24 Feb 2012 13:05:29 +0200 Subject: ssh-agent use in different security domains In-Reply-To: <20120224102525.GA25545@pob.ytti.fi> References: <4EA85490.2010303@fifthhorseman.net> <4EA85B3E.9050303@fifthhorseman.net> <4EA8731B.9020906@fifthhorseman.net> <260FB869588EFDFDDAF3B07C@nimrod.local> <20111027073613.GA1500@apb-laptoy.apb.alt.za> <20120224102525.GA25545@pob.ytti.fi> Message-ID: <20120224110529.GH1788@apb-laptoy.apb.alt.za> On Fri, 24 Feb 2012, Saku Ytti wrote: > I just had discussion about another usage case for ssh agent > forwarding, which I'm not sure ProxyCommand can fix, am I > missing something, or is there after all usage case for agent > forwarding? [...] >With agent forwarding you could do >a% ssh b ssh c scp file d: With ProxyCommand, you'd just do: a% ssh c scp file d: and the intermediate step of hopping through b would be handled by a ProxyCommand setting in your .ssh/config file: Host c ProxyCommand ssh -W %h:%p b --apb (Alan Barrett) From saku at ytti.fi Fri Feb 24 22:16:55 2012 From: saku at ytti.fi (Saku Ytti) Date: Fri, 24 Feb 2012 13:16:55 +0200 Subject: ssh-agent use in different security domains In-Reply-To: <20120224110529.GH1788@apb-laptoy.apb.alt.za> References: <4EA85490.2010303@fifthhorseman.net> <4EA85B3E.9050303@fifthhorseman.net> <4EA8731B.9020906@fifthhorseman.net> <260FB869588EFDFDDAF3B07C@nimrod.local> <20111027073613.GA1500@apb-laptoy.apb.alt.za> <20120224102525.GA25545@pob.ytti.fi> <20120224110529.GH1788@apb-laptoy.apb.alt.za> Message-ID: <20120224111655.GA30158@pob.ytti.fi> On (2012-02-24 13:05 +0200), Alan Barrett wrote: > With ProxyCommand, you'd just do: > a% ssh c scp file d: > > and the intermediate step of hopping through b would be handled by a > ProxyCommand setting in your .ssh/config file: > > Host c > ProxyCommand ssh -W %h:%p b Curious. I need some cluebat, how does the key authentication work here. D needs key which is only in a, but d is asking for it from c, is it not? There is no magic lines for c<->d connectivity. I know that you could easily daisy-chain ProxyCommand do to a->b->c->d ssh connection, but does that mean you can also do a->b->c and c<->d, meaning you're 'dropping out' in the middle? -- ++ytti From apb at cequrux.com Fri Feb 24 23:26:07 2012 From: apb at cequrux.com (Alan Barrett) Date: Fri, 24 Feb 2012 14:26:07 +0200 Subject: ssh-agent use in different security domains In-Reply-To: <20120224111655.GA30158@pob.ytti.fi> References: <4EA85490.2010303@fifthhorseman.net> <4EA85B3E.9050303@fifthhorseman.net> <4EA8731B.9020906@fifthhorseman.net> <260FB869588EFDFDDAF3B07C@nimrod.local> <20111027073613.GA1500@apb-laptoy.apb.alt.za> <20120224102525.GA25545@pob.ytti.fi> <20120224110529.GH1788@apb-laptoy.apb.alt.za> <20120224111655.GA30158@pob.ytti.fi> Message-ID: <20120224122607.GI1788@apb-laptoy.apb.alt.za> On Fri, 24 Feb 2012, Saku Ytti wrote: >> With ProxyCommand, you'd just do: >> a% ssh c scp file d: >> >> and the intermediate step of hopping through b would be handled by a >> ProxyCommand setting in your .ssh/config file: >> >> Host c >> ProxyCommand ssh -W %h:%p b > >Curious. I need some cluebat, how does the key authentication work here. > >D needs key which is only in a, but d is asking for it from c, is it not? >There is no magic lines for c<->d connectivity. Oh, I didn't understand that the C->D commenction needed a key from A. Even so, you could forward the agent connection from A to C, and allow C to use the agent's key to connect to D, without needing to expose the agent to B. --apb (Alan Barrett) From saku at ytti.fi Fri Feb 24 23:48:21 2012 From: saku at ytti.fi (Saku Ytti) Date: Fri, 24 Feb 2012 14:48:21 +0200 Subject: ssh-agent use in different security domains In-Reply-To: <20120224122607.GI1788@apb-laptoy.apb.alt.za> References: <4EA85B3E.9050303@fifthhorseman.net> <4EA8731B.9020906@fifthhorseman.net> <260FB869588EFDFDDAF3B07C@nimrod.local> <20111027073613.GA1500@apb-laptoy.apb.alt.za> <20120224102525.GA25545@pob.ytti.fi> <20120224110529.GH1788@apb-laptoy.apb.alt.za> <20120224111655.GA30158@pob.ytti.fi> <20120224122607.GI1788@apb-laptoy.apb.alt.za> Message-ID: <20120224124821.GA5798@pob.ytti.fi> On (2012-02-24 14:26 +0200), Alan Barrett wrote: > Oh, I didn't understand that the C->D commenction needed a key from > A. Even so, you could forward the agent connection from A to C, and > allow C to use the agent's key to connect to D, without needing to > expose the agent to B. What is the general feeling in SSH community on usability of agent forwarding and proxy command? I feel that proxy command is bit too complex and does not solve all the issues. And agent is too insecure. Are the issues solvable? ProxyCommand probably does solve the original question I had in this thread, but seems not to remove all need for agent forwarding. For ProxyCommand I's love to see syntactic sugar like this: ---- # cat >> .ssh/config Host org1-ultimate path org1-firstjump, org1-secondjump ^d # ssh org2-firstjump,org2-secondjump,org2-ultimate # ssh org1-ultimate ---- Showing how to jump through multiple box with config or directly from CLI. I'd like to believe this would be well received. But this still leaves open the question how do we support this scp issue in userfriendly way, is ProxyCommand or other such secure channel for key exchange all it takes? Or should agent forwarding be fixed to be (more) secure? -- ++ytti From nkadel at gmail.com Sat Feb 25 00:15:00 2012 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Fri, 24 Feb 2012 08:15:00 -0500 Subject: Solaris BSM audit support In-Reply-To: <9C50C7EBEE767343AB45090430D1E3A101029EABED2D@exch-07.centrify.com> References: <9C50C7EBEE767343AB45090430D1E3A101029EABEB38@exch-07.centrify.com> <9C50C7EBEE767343AB45090430D1E3A101029EABED2D@exch-07.centrify.com> Message-ID: On Thu, Feb 23, 2012 at 8:34 PM, Leo Liou wrote: > Thanks for responding. > Yes. We are software vendor (www.centrify.com). > I have several customers asked me about this - they would like to use > openssh rather than Sun's stock sshd which has other (unrelated) issues. > BSM is the issue that stands in the way right now. > They saw the experimental designation, and just backed off, hence the > email to you. > So, I think the point is if they run into issue, can they (or we) get some > help to look into it and possibly get fix. > Thanks. > > Hi, Leo: I've used Centrify's OpenSSH and related tools for genuine single-sign-in for Linux servers and Windows clients. They provided updated Putty and OpenSSH servers with GSSAPI for RHEL 3, RHEL 4 and RHEL 5 servers. Good, useful stuff, especially with the Active Directory integration for mixed environments. Have you folks seen any BSM issues? I'd expect your clients who've activated this to be some of the best test beds to verify its effectiveness. Leo, did you guys ever straighten out the "compile OpenSSH for the particular Linux distribution, don't assume OpenSSH compiled on older distributions will operate on the most recent release" issue? You used to publish only the RHEL 3 RPM's for RHEL based Linux, and I'm the one who sent the "xauth moved since then, you need to recompile on RHEL 5 or edit sshd_config" workaround. From mark at nosredna.net Mon Feb 27 02:02:59 2012 From: mark at nosredna.net (Mark Anderson) Date: Sun, 26 Feb 2012 10:02:59 -0500 Subject: spc restarts Message-ID: <4F4A49A3.3050802@nosredna.net> I was wondering why scp didn't have a restart-in-the-middle option when transferring a large file. Isn't that something that is supported by the underlying ssh protocol? Is there some other program that can give me this functionality ? From gert at greenie.muc.de Mon Feb 27 03:35:20 2012 From: gert at greenie.muc.de (Gert Doering) Date: Sun, 26 Feb 2012 17:35:20 +0100 Subject: spc restarts In-Reply-To: <4F4A49A3.3050802@nosredna.net> References: <4F4A49A3.3050802@nosredna.net> Message-ID: <20120226163520.GI7024@greenie.muc.de> Hi, On Sun, Feb 26, 2012 at 10:02:59AM -0500, Mark Anderson wrote: > I was wondering why scp didn't have a restart-in-the-middle > option when transferring a large file. Isn't that something > that is supported by the underlying ssh protocol? Is there > some other program that can give me this functionality ? rsync (-over-ssh). gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert at net.informatik.tu-muenchen.de From mouring at eviladmin.org Mon Feb 27 04:09:42 2012 From: mouring at eviladmin.org (Ben Lindstrom) Date: Sun, 26 Feb 2012 11:09:42 -0600 Subject: spc restarts In-Reply-To: <4F4A49A3.3050802@nosredna.net> References: <4F4A49A3.3050802@nosredna.net> Message-ID: On Feb 26, 2012, at 9:02 AM, Mark Anderson wrote: > I was wondering why scp didn't have a restart-in-the-middle > option when transferring a large file. Isn't that something > that is supported by the underlying ssh protocol? Is there > some other program that can give me this functionality ? Scp came from rcp.. Which is a stupid simple(ish) protocol more like doing: tar -cvf | ssh tar -xvf. So it really has nothing to do with the ssh protocol itself as it just needs a streaming socket to throw data at. I suspect you're thinking sftp service, and that could be easily extended to support it. I did a cheap proof of concept that required adding an sha1 hash request extension to the server so I could determine where I needed to pick up in the transfer. It really was an attempt to implement a simplified rsync over sftp. However, that code is long since dead and burned. - Ben From mark at nosredna.net Mon Feb 27 04:15:06 2012 From: mark at nosredna.net (Mark Anderson) Date: Sun, 26 Feb 2012 12:15:06 -0500 Subject: spc restarts In-Reply-To: References: <4F4A49A3.3050802@nosredna.net> Message-ID: <4F4A689A.6060605@nosredna.net> Yes, I was thinking of sftp but had forgotten because I had wanted to ask this question on this list a while ago but figured I ought to watch the list for a while first to find out if it was appropriate. I saw that the server side supported starting in the middle and I figured that if you had part of the file locally downloaded it would be easy to start where it left off. The same capability that wget has for http transfers. I could use rsync but only if that server was running on the other end, which is not as likely as sshd. On 02/26/12 12:09, Ben Lindstrom wrote: > > On Feb 26, 2012, at 9:02 AM, Mark Anderson wrote: > >> I was wondering why scp didn't have a restart-in-the-middle >> option when transferring a large file. Isn't that something >> that is supported by the underlying ssh protocol? Is there >> some other program that can give me this functionality ? > > Scp came from rcp.. Which is a stupid simple(ish) protocol > more like doing: tar -cvf | ssh tar -xvf. So it really has nothing > to do with the ssh protocol itself as it just needs a streaming > socket to throw data at. > > I suspect you're thinking sftp service, and that could be easily > extended to support it. I did a cheap proof of concept that > required adding an sha1 hash request extension to the server > so I could determine where I needed to pick up in the transfer. > It really was an attempt to implement a simplified rsync over sftp. > > However, that code is long since dead and burned. > > - Ben From nkadel at gmail.com Mon Feb 27 04:17:36 2012 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Sun, 26 Feb 2012 12:17:36 -0500 Subject: spc restarts In-Reply-To: <20120226163520.GI7024@greenie.muc.de> References: <4F4A49A3.3050802@nosredna.net> <20120226163520.GI7024@greenie.muc.de> Message-ID: On Sun, Feb 26, 2012 at 11:35 AM, Gert Doering wrote: > Hi, > > On Sun, Feb 26, 2012 at 10:02:59AM -0500, Mark Anderson wrote: > > I was wondering why scp didn't have a restart-in-the-middle > > option when transferring a large file. Isn't that something > > that is supported by the underlying ssh protocol? Is there > > some other program that can give me this functionality ? > > rsync (-over-ssh). > Specifically, review the documentation for and use the "-P" option for rsync, which can use rsync automatically. Rsync over ssh actually has a number of concrete advantages over scp: In particular, using the "-a" or related options, it can copy symlinks as symlinks, and using the "-H" option, it can copy hard links as hardlinks. The syntax take a bit of practice, especially to handle directories. For example, to replicate /etc from one host to a backup on a localhost: Note the options used, and the trailing slashes. rsync -avH root at srchost:/etc/ /backupdir/etc/ From glenn at zewt.org Mon Feb 27 04:26:34 2012 From: glenn at zewt.org (Glenn Maynard) Date: Sun, 26 Feb 2012 12:26:34 -0500 Subject: spc restarts In-Reply-To: <4F4A689A.6060605@nosredna.net> References: <4F4A49A3.3050802@nosredna.net> <4F4A689A.6060605@nosredna.net> Message-ID: On Sun, Feb 26, 2012 at 12:15 PM, Mark Anderson wrote: > I could use rsync but only if that server was running > on the other end, which is not as likely as sshd. > You don't actually need a server running, rsync just needs to be available on the other host. The client side of rsync will run rsync on the remote end--that's all it's actually doing when it runs ssh (or rsh). rsync defaults to ssh for me (not rsh), so I don't have to give it any extra arguments. I'm not sure if that's the default or a Debian patch. (If it's not the default upstream, it should be.) -- Glenn Maynard From gert at greenie.muc.de Mon Feb 27 05:02:35 2012 From: gert at greenie.muc.de (Gert Doering) Date: Sun, 26 Feb 2012 19:02:35 +0100 Subject: spc restarts In-Reply-To: <4F4A689A.6060605@nosredna.net> References: <4F4A49A3.3050802@nosredna.net> <4F4A689A.6060605@nosredna.net> Message-ID: <20120226180234.GJ7024@greenie.muc.de> Hi, On Sun, Feb 26, 2012 at 12:15:06PM -0500, Mark Anderson wrote: > I could use rsync but only if that server was running > on the other end, which is not as likely as sshd. Use rsync-over-ssh, not rsync-to-rsyncd, then :-) (Of course that requires rsync to be installed on the target machine, which might not be the case, so I do see your point). gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert at net.informatik.tu-muenchen.de From nkadel at gmail.com Mon Feb 27 07:54:09 2012 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Sun, 26 Feb 2012 15:54:09 -0500 Subject: spc restarts In-Reply-To: <20120226180234.GJ7024@greenie.muc.de> References: <4F4A49A3.3050802@nosredna.net> <4F4A689A.6060605@nosredna.net> <20120226180234.GJ7024@greenie.muc.de> Message-ID: On Sun, Feb 26, 2012 at 1:02 PM, Gert Doering wrote: > Hi, > > On Sun, Feb 26, 2012 at 12:15:06PM -0500, Mark Anderson wrote: > > I could use rsync but only if that server was running > > on the other end, which is not as likely as sshd. > > Use rsync-over-ssh, not rsync-to-rsyncd, then :-) > > (Of course that requires rsync to be installed on the target machine, > which might not be the case, so I do see your point). rsync is a pretty common system utility. It actually takes *work* to leave it out of most common UNIX or Linux deployments, and it is very easy to test. If the server is one of the commercial SFTP/FTP servers, which are typically Windows based, it may not be available. From christian.heinrich at cmlh.id.au Mon Feb 27 13:54:47 2012 From: christian.heinrich at cmlh.id.au (Christian Heinrich) Date: Mon, 27 Feb 2012 13:54:47 +1100 Subject: Article on Fingerprinting Public/Private Keypairs Message-ID: I have published the preview of a "hints and tips" article for the upcoming print edition of Secure Computing Magazine (Australia) on OpenSSH Public/Private Key Fingerprinting, including "BubbleBabble" encoding and the ASCII ?randomart image?, at http://cmlh.id.au/tagged/openssh -- Regards, Christian Heinrich http://cmlh.id.au/contact From TECHTEAMCRP at icicibank.com Mon Feb 27 18:49:10 2012 From: TECHTEAMCRP at icicibank.com (TECHTEAMCRP) Date: Mon, 27 Feb 2012 13:19:10 +0530 Subject: Error: Connection closed by remote host Message-ID: < 957FF488AA64E74AB21583D35883A4B22034BA3590%bkcexhvs01.icicibankltd.com@mailhub.eait.uq.edu.au> Hello, We are using OpenSSH for Windows v3.8.1p1-1 in Windows Server 2003 Enterprise Edition Service Pack 2. Server is member of WORKGROUP and not in domain. Hardware details: CPU : Intel Xeon 2.40 GHz RAM: 4 GB There is a strange problem with login to a particular ID. There are several local ID's created on server. All ID's are properly able to login on server. However a particular ID is intermediately getting below mentioned error message. Client End is using Linux AS5 OS platform to login. And user ID password is saved. Error code: ssh_exchange_identification: Connection closed by remote host. Help on this will be highly appreciated and thanks in advance. Please let me know if any additional details are required. Regards, Mitesh Visaria --- "Print this mail only if absolutely necessary. Save Paper. Save Trees." "This e-mail message may contain confidential, proprietary or legally privileged information. It should not be used by anyone who is not the original intended recipient. If you have erroneously received this message, please delete it immediately and notify the sender. The recipient acknowledges that ICICI Bank or its subsidiaries and associated companies, (collectively "ICICI Group"), are unable to exercise control or ensure or guarantee the integrity of/over the contents of the information contained in e-mail transmissions and further acknowledges that any views expressed in this message are those of the individual sender and no binding nature of the message shall be implied or assumed unless the sender does so expressly with due authority of ICICI Group. Before opening any attachments please check them for viruses and defects." From sfandino at yahoo.com Mon Feb 27 20:28:41 2012 From: sfandino at yahoo.com (Salvador Fandino) Date: Mon, 27 Feb 2012 10:28:41 +0100 Subject: spc restarts In-Reply-To: References: <4F4A49A3.3050802@nosredna.net> Message-ID: <4F4B4CC9.4000208@yahoo.com> On 02/26/2012 06:09 PM, Ben Lindstrom wrote: > > On Feb 26, 2012, at 9:02 AM, Mark Anderson wrote: > >> I was wondering why scp didn't have a restart-in-the-middle >> option when transferring a large file. Isn't that something >> that is supported by the underlying ssh protocol? Is there >> some other program that can give me this functionality ? > > Scp came from rcp.. Which is a stupid simple(ish) protocol > more like doing: tar -cvf | ssh tar -xvf. So it really has nothing > to do with the ssh protocol itself as it just needs a streaming > socket to throw data at. > > I suspect you're thinking sftp service, and that could be easily > extended to support it. I did a cheap proof of concept that > required adding an sha1 hash request extension to the server > so I could determine where I needed to pick up in the transfer. > It really was an attempt to implement a simplified rsync over sftp. You don't really need a hashing extension in order to support transfer resuming. You can make a good heuristic just comparing remote and local timestamps and file sizes. For instance, for "put": if local_ts > remote_ts: do full transfer else: if local_size <= remote_size: done else: resume transfer from remote_size That works reliably as far as the remote files are not modified in other ways. SFTP clients supporting that that I know are lftp and my perl module Net::SFTP::Foreign. From sfandino at yahoo.com Mon Feb 27 20:28:41 2012 From: sfandino at yahoo.com (Salvador Fandino) Date: Mon, 27 Feb 2012 10:28:41 +0100 Subject: spc restarts In-Reply-To: References: <4F4A49A3.3050802@nosredna.net> Message-ID: <4F4B4CC9.4000208@yahoo.com> On 02/26/2012 06:09 PM, Ben Lindstrom wrote: > > On Feb 26, 2012, at 9:02 AM, Mark Anderson wrote: > >> I was wondering why scp didn't have a restart-in-the-middle >> option when transferring a large file. Isn't that something >> that is supported by the underlying ssh protocol? Is there >> some other program that can give me this functionality ? > > Scp came from rcp.. Which is a stupid simple(ish) protocol > more like doing: tar -cvf | ssh tar -xvf. So it really has nothing > to do with the ssh protocol itself as it just needs a streaming > socket to throw data at. > > I suspect you're thinking sftp service, and that could be easily > extended to support it. I did a cheap proof of concept that > required adding an sha1 hash request extension to the server > so I could determine where I needed to pick up in the transfer. > It really was an attempt to implement a simplified rsync over sftp. You don't really need a hashing extension in order to support transfer resuming. You can make a good heuristic just comparing remote and local timestamps and file sizes. For instance, for "put": if local_ts > remote_ts: do full transfer else: if local_size <= remote_size: done else: resume transfer from remote_size That works reliably as far as the remote files are not modified in other ways. SFTP clients supporting that that I know are lftp and my perl module Net::SFTP::Foreign. From jan.pechanec at oracle.com Tue Feb 28 05:47:39 2012 From: jan.pechanec at oracle.com (Jan Pechanec) Date: Mon, 27 Feb 2012 10:47:39 -0800 (PST) Subject: spc restarts In-Reply-To: References: <4F4A49A3.3050802@nosredna.net> Message-ID: On Sun, 26 Feb 2012, Ben Lindstrom wrote: > >On Feb 26, 2012, at 9:02 AM, Mark Anderson wrote: > >> I was wondering why scp didn't have a restart-in-the-middle >> option when transferring a large file. Isn't that something >> that is supported by the underlying ssh protocol? Is there >> some other program that can give me this functionality ? > >Scp came from rcp.. Which is a stupid simple(ish) protocol >more like doing: tar -cvf | ssh tar -xvf. So it really has nothing >to do with the ssh protocol itself as it just needs a streaming >socket to throw data at. hello, actually, "tar -cvf | ssh tar -xvf" can be much faster then copying over scp, expecially with many files transferred over a long distance link since the transfer of each file is confirmed before the next one is sent. It is described here (section "Efficiency"): https://blogs.oracle.com/janp/entry/how_the_scp_protocol_works J. -- Jan Pechanec http://blogs.oracle.com/janp