search for: blumenth

.... In any case (no pun intended), IMHO it would be better to break a few of the current use cases but leave the majority functional - than kill scp for all. Regards, Uri > On Aug 3, 2020, at 02:50, Jakub Jelen <jjelen at redhat.com> wrote: > > ?On Sat, 2020-08-01 at 00:17 +0000, Blumenthal, Uri - 0553 - MITLL > wrote: >> Why can the local and remote paths be sanitized? > > Because remote path is *expected* to be expanded by remote shell before > executing remote scp. If you sanitize it in any way, you will break > existing use cases. > >> Regards, &g...

On Sun, 12 Aug 2018, Blumenthal, Uri - 0553 - MITLL wrote: > Tone aside, let me second what Bob said. OpenSSH maintainers seem to > be able to find time for many updates and upgrades - but ECC support > over PKCS#11 appears to repulse them for more than two years (I don't > care to check for exactly how many mo...

...:foo\* .". Especially, since (almost always) I have equal privileges on both local and remote hosts, so in that case I just originate that "scp" from that remote. ;-) TNX ?On 8/3/20, 11:09, "Thorsten Glaser" <t.glaser at tarent.de> wrote: On Mon, 3 Aug 2020, Blumenthal, Uri - 0553 - MITLL wrote: > I conjecture that only few of the existing use cases rely on remote expansion. No, this is used all the time. scp remotehost:foo\* . (Unless rsync is available, but sadly that?s ? GPLv3 and ? not universally installed.) bye, //mira...

...rather than loading keys in every time you need to do something. TPM, like other hardware tokens, was designed for storing things (keys) internally. And you can load keys onto PKCS#11 tokens (if you configure them so ? that?s a policy issue rather than a technological limitation). -- Regards, Uri Blumenthal On 11/3/17, 12:33, "James Bottomley" <James.Bottomley at HansenPartnership.com> wrote: On Fri, 2017-11-03 at 14:34 +0000, Blumenthal, Uri - 0553 - MITLL wrote: > >> Let me rephrase my question: what does using OpenSSL > engines enable &g...

...s silliness underscores the value and timeliness of using? hardware tokens & PK-based authentication. :-) Sent?from?my?BlackBerry?10?smartphone?on?the Verizon?Wireless?4G?LTE?network. ? Original Message ? From: Nico Kadel-Garcia Sent: Sunday, December 18, 2016 12:56 To: Philipp Vlassakakis Cc: Blumenthal, Uri - 0553 - MITLL; openssh-unix-dev at mindrot.org Subject: Re: Extend logging of openssh-server - e.g. plaintext password On Sun, Dec 18, 2016 at 12:26 PM, Philipp Vlassakakis <philipp at vlassakakis.de> wrote: > Please accept my apologies. Sorry if my previous mails sound rude, it w...

...n't there a proposal at one time to create something like AuthorizedKeysCommand for PKSC11 and other methods that required more complex backend processed so it could be externalized and OpenSSH could be simplified? > > Ben > > Damien Miller wrote: >>> On Mon, 13 Aug 2018, Blumenthal, Uri - 0553 - MITLL wrote: >>> >>> Lack of time on the Open Source projects is understandable, and not uncommon. >>> >>> However, PKCS11 has been in the codebase practically forever - the ECC >>> patches that I saw did not alter the API or such. It i...

...hing for OpenSSH to do would be to port their code to using accessor functions, and write a shim library to the ?old? way (exactly as was proposed here before). LibreSSL would have to do the same eventually. The pain of such migration can be postponed, but not avoided indefinitely. -- Regards, Uri Blumenthal On 10/18/17, 12:38, "openssh-unix-dev on behalf of Ingo Schwarze" <openssh-unix-dev-bounces+uri=ll.mit.edu at mindrot.org on behalf of schwarze at usta.de> wrote: Hi Emmanuel, Emmanuel Deloget wrote on Wed, Oct 18, 2017 at 05:45:40PM +0200: > Important A...

On Mon, 13 Aug 2018, Blumenthal, Uri - 0553 - MITLL wrote: > Lack of time on the Open Source projects is understandable, and not uncommon. > > However, PKCS11 has been in the codebase practically forever - the ECC > patches that I saw did not alter the API or such. It is especially > non-invasive when digital si...

I concur with Nico ? logging plaintext passwords is an extremely bad idea. The tone of the poster also leaves much to be desired ? but I?ll hold my tongue for now. -- Regards, Uri Blumenthal On 12/18/16, 11:48, "openssh-unix-dev on behalf of Nico Kadel-Garcia" <openssh-unix-dev-bounces+uri=ll.mit.edu at mindrot.org on behalf of nkadel at gmail.com> wrote: On Sun, Dec 18, 2016 at 9:42 AM, Philipp Vlassakakis <philipp at vlassakakis.de> wrote: > W...

I for one would like to see it merged.? Thanks! Sent?from?my?BlackBerry?10?smartphone?on?the Verizon?Wireless?4G?LTE?network. ? Original Message ? From: Jakob Schlyter Sent: Wednesday, December 14, 2016 04:29 To: openssh-unix-dev at mindrot.org Subject: Re: Call for testing: OpenSSH 7.4 On 2016-12-14 at 01:53, Damien Miller wrote: > OpenSSH 7.4 is almost ready for release, so we would

Howdy all, I compiled a set of kernel RPMs with the upstream kernel patch applied. Obviously they haven't gone through the full QA process, but I know of them running on approximately 50 servers without any reported issues. They're available at: http://erek.blumenthals.com/blog/2008/02/11/rhel-5-centos-5-kernel-rpms-patched-against-vmsplice-local-root-exploit/ Let me know any experiences you have with them. Regards, Erek Dyskant

On 2016-12-15 at 01:05, Darren Tucker wrote: > On Thu, Dec 15, 2016 at 6:58 AM, Blumenthal, Uri - 0553 - MITLL > <uri at ll.mit.edu> wrote: > [OSX launchd diff] >> I for one would like to see it merged. > > I took the patch and addressed the comments in > https://bugzilla.mindrot.org/show_bug.cgi?id=2341. If we can get some > confirmation that it > (ht...

>> Let me rephrase my question: what does using OpenSSL engines enable >> that we can't already do via PKCS#11? > > It allows you to use the TPM2 as a secure key store, because there's no > current PKCS11 code for it. > > The essential difference is that Engine files are just that: flat files >

On 11/16/16, 8:55 AM, "openssh-unix-dev on behalf of Juha-Matti Tapio" <openssh-unix-dev-bounces+uri=ll.mit.edu at mindrot.org on behalf of jmtapio at ssh.com> wrote: On Wed, Nov 16, 2016 at 12:54:44PM +0000, Blumenthal, Uri - 0553 - MITLL wrote: > I find this approach very bad in general. > > PKCS#11 standard says that *private* keys should not be accessible without authentication. *Public* keys and certificates of course can and should be accessible with no authentication. >...

Why can the local and remote paths be sanitized? Regards, Uri > On Jul 31, 2020, at 19:57, Ethan Rahn <ethan.rahn at gmail.com> wrote: > > ?I wanted to bring this up again due to: > https://github.com/cpandya2909/CVE-2020-15778/. This showcases a clear > issue with scp which it sounds like cannot be fixed without breaking scp. > This seems like it would lend some impetus

I find this approach very bad in general.? PKCS#11 standard says that *private* keys should not be accessible without authentication. *Public* keys and certificates of course can and should be accessible with no authentication. SoftHSM misinterpreted this originally (older pkcs11 documents were less clear :), but they rectified this mistake. We should not repeat it.?

Also, Jerry Solinas, the person listed as an author of the curves, also is the author of DUAL_EC_DRBG. On Tue, May 29, 2018 at 3:43 AM, Damien Miller <djm at mindrot.org> wrote: > On Tue, 29 May 2018, Damien Miller wrote: > >> We're aware of those arguments but don't find them convincing enough to >> switch early. > > (but we will be switching to ssh-ed25519

On Mon, 2020-08-03 at 19:17 +0200, Thorsten Glaser wrote: > That would be the same as killing scp? Better that... than having an inherently insecure scp... or at least make it absolutely clear and rename it to i[nsecure]scp. If the core functionality of a program (which is here probably the "secure") is no longer given, then it's IMO better to rather cause breakage (at least for

...ided windows share, but not me ;) I tried to solve this problem for one day using google etc. - but could not find a good hint. Does anybody know what goes wrong and give me he hint? Thanks for help/advise best regards Bernd Kohler - -- UMIC - RWTH Aachen http://www.umic.rwth-aachen.de Otto-Blumenthal-Str. 2 52074 Aachen Tel.: +49 241 80 20680 Fax: +49 241 80 22640 E-Mail: kohler@umic.rwth-aachen.de -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkk3mgAACgkQOiq/E1Lch49ZggCgg7Y3s+bQCX7MIy52TDMxTqhf rLEAn3sYFcjuVuOPuzneQxTdlrLjIfEb =k/SJ -----END PGP SIGNATUR...

> Uri (earlier in this thread) does answer this question clearly (that > the principal should be the hostname only), and, now that I've found > PROTOCOL.certkeys, this seems to be spelt out unambiguously there too: In turn this means: One cannot expect several SSH services on a single host to be securely distinguishable from each other by their particular