similar to: Announce: OpenSSH 9.3p2 released

OpenSSH 9.3p2 has just been released. It will be available from the mirrors listed at https://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol 2.0 implementation and includes sftp client and server support. Once again, we would like to thank the OpenSSH community for their continued support of the project, especially those who contributed code or patches, reported bugs, tested

Dear Damien, Could you please clarify which versions are vulnerable? On Wed, Jul 19, 2023 at 7:38?PM Damien Miller <djm at cvs.openbsd.org> wrote: > > OpenSSH 9.3p2 has just been released. It will be available from the > mirrors listed at https://www.openssh.com/ shortly. > > OpenSSH is a 100% complete SSH protocol 2.0 implementation and > includes sftp client and server

Hi, OpenSSH 9.4 is almost ready for release, so we would appreciate testing on as many platforms and systems as possible. This is a bugfix release. 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 git using the instructions at

OpenSSH 9.6 has just been released. It will be available from the mirrors listed at https://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol 2.0 implementation and includes sftp client and server support. Once again, we would like to thank the OpenSSH community for their continued support of the project, especially those who contributed code or patches, reported bugs, tested

Hi, I have made a patch for enabling the use of ECDSA keys in the PKCS#11 support of ssh-agent which will be of interest to other users. I have tested it with P-256 keys. P-384 and P-521 should work out-of-the box. The code is ready for non-FIPS curves (named or explicit), but OpenSSH currently limits ECDSA to those 3 curves. At high level it works like the support for RSA, but because of

Hello, OpenSSH supports PKCS#11 on the client side, but that does not extend to the server side. I would like to bring PKCS#11 support to sshd. I am working on embedded Linux systems with integrated HSM. The sshd host key is stored on the HSM. To have sshd using that key, we rely on the following chain: sshd -> OpenSSL -> OpenSSL Engine -> HSM Having PKCS#11 support in sshd, would

Thomas Calderon <calderon.thomas at gmail.com> writes: > Hi, > > There is no need to add new mechanism identifiers to use specific curves. > > This can be done already using the CKM_ECDSA mechanism parameters (see > CKA_ECDSA_PARAMS > in the standard). > Given that the underlying HW or SW tokens supports Ed25519 curves, then you > could leverage it even with

Hello everyone, as you could have noticed over the years, there are several bugs for PKCS#11 improvement and integration which are slipping under the radar for several releases, but the most painful ones are constantly updated by community to build, work and make our lives better. I wrote some of the patches, provided feedback to others, or offered other help here on mailing list, but did not

On 10/8/2015 4:49 AM, Simon Josefsson wrote: > Mathias Brossard <mathias at brossard.org> writes: > >> Hi, >> >> I have made a patch for enabling the use of ECDSA keys in the PKCS#11 >> support of ssh-agent which will be of interest to other users. > > Nice! What would it take to add support for Ed25519 too? Do we need to > allocate any new PKCS#11

On Thu, 26 Oct 2017, James Bottomley wrote: > Engine keys are keys whose file format is understood by a specific > engine rather than by openssl itself. Since these keys are file > based, the pkcs11 interface isn't appropriate for them because they > don't actually represent tokens. What sort of keys do you have in mind here that can't be represented via PKCS#11? -d

Hello, PKCS#11 is a standard API interface that can be used in order to access cryptographic tokens. You can find the specification at http://www.rsasecurity.com/rsalabs/node.asp?id=2133, most smartcard and other cryptographic device vendors support PKCS#11, opensc also provides PKCS#11 interface. I can easily make the scard.c, scard-opensc.c and ssh-agent.c support PKCS#11. PKCS#11 is

Hello OpenSSH developers, A week ago I've posted a patch that enables openssh to work with PKCS#11 tokens. I didn't receive any comments regarding the patch or reply to my questions. In current software world, providing a security product that does not support standard interface for external cryptographic hardware makes the product obsolete. Please comment my patch, so I can know

Hi all, Thanks for all your hard work! I was particularly excited to see FIDO/U2F support in the latest release. I'd like to make the following bug report in ssh-agent's PKCS#11 support: Steps to reproduce: 1. Configure a smart card (e.g. Yubikey in PIV mode) as an SSH key. 2. Add that key to ssh-agent. 3. Remove that key from ssh-agent. 4. Add that key to ssh-agent. Expected results:

Hi, Is there any way to store HostKey in hardware (and delegate the related processing)? I have been using Roumen Petrov's x509 patch for clients, which works via an OpenSSL engine, but it does not seem to support server HostKey: http://roumenpetrov.info/pipermail/ssh_x509_roumenpetrov.info/2012q4/000019.html For PKCS#11, I have found an email on this list from a year back suggesting this

http://bugzilla.mindrot.org/show_bug.cgi?id=1371 Summary: Add PKCS#11 (Smartcards) support into OpenSSH Product: Portable OpenSSH Version: 4.7p1 Platform: All URL: http://alon.barlev.googlepages.com/openssh-pkcs11 OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component:

Alon, On 12/18/2018 06:52 PM, Alon Bar-Lev wrote: > OK... So you have an issue... > > First, you need to delegate your smartcard to remote machine, probably > using unix socket redirection managed by openssh. This can be done in > many levels... > 1. Delegate USB device, this will enable only exclusive usage of the > smartcard by remote machine. > 2. Delegate PC/SC, this

Right now, if I typo my PIN for a PKCS#11 token, I get the inscrutable message: $ ssh -I /path/to/module user at example.com Enter PIN for 'SSH key': C_Login failed: 160 I'd prefer to receive a more useful message: Login to PKCS#11 token failed: Incorrect PIN I've attached a patch that adds specific handling for three common error cases: Incorrect PIN, PIN too long or too

On Sat, 2020-02-22 at 10:50 -0600, Douglas E Engert wrote: > As a side note, OpenSC is looking at issues with using tokens vs > separate > readers and smart cards. The code paths in PKCS#11 differ. Removing a > card > from a reader leaves the pkcs#11 slot still available. Removing a > token (Yubikey) > removes both the reader and and its builtin smart card. Firefox has a >

Hello all, as PKCS#11 URI became standard (RFC 7512), it would be good to be able to specify the keys using this notation in openssh. So far I implemented the minimal subset of this standard allowing to specify the URI for the ssh tool, in ssh_config and to work with ssh-agent. It does not bring any new dependency, provides unit and regress tests (while fixing agent-pkcs11 regress test). The

On Sat, 2019-04-06 at 03:20 +1100, Damien Miller wrote: > On Fri, 5 Apr 2019, Jakub Jelen wrote: > > > There is also changed semantics of the ssh-keygen when listing keys > > from PKCS#11 modules. In the past, it was not needed to enter a PIN > > for > > this, but now. > > > > At least, it is not consistent with a comment in the function > >