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

On 19.07.23 16:40, Damien Miller wrote: > Exploitation can also be prevented by starting ssh-agent(1) with an > empty PKCS#11/FIDO allowlist (ssh-agent -P '') or by configuring > an allowlist that contains only specific provider libraries. Upon trying to deploy such a workaround, I found that the call to ssh-agent(1) nowadays is hidden *ridiculously* deep in the GUI startup

OpenSSH 9.4 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

Compiled on OpenIndiana using GCC 11 :; SunOS 5.11 illumos-2e79e00041 illumos Although snapshot was downloaded, it shows 9.3 version: :; ssh -V OpenSSH_9.3p1-snap20230809, OpenSSL 1.1.1v? 1 Aug 2023 Thanks and regards. On 31.07.2023 08:12, Damien Miller wrote: > Hi, > > OpenSSH 9.4 is almost ready for release, so we would appreciate testing > on as many platforms and systems as

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

https://bugzilla.mindrot.org/show_bug.cgi?id=3635 Bug ID: 3635 Summary: ssh-add -s always asks for PKCS#11 PIN Product: Portable OpenSSH Version: 9.0p1 Hardware: Other OS: Linux Status: NEW Severity: enhancement Priority: P5 Component: ssh-add Assignee: unassigned-bugs at

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 Andreas, On 10/11/05, Andreas Jellinghaus <aj at dungeon.inka.de> wrote: > Peter Koch pointed me to your posting on openssh-devel mailing list. I am very glad that he did. > I'm one of the opensc people, and from my point of view your idea > is a good one. The current openssh-opensc code has a number of issues, > for example the ssh-agent does not test the pin

Hi All, The version of "PKCS#11 support in OpenSSH" is ready for download. On download page http://alon.barlev.googlepages.com/openssh-pkcs11 you can find a patch for OpenSSH 4.5p1. Most of PKCS#11 code is now moved to a standalone library which I call pkcs11-helper, this library is used by all projects that I added PKCS#11 support into. The library can be downloaded from:

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

https://bugzilla.mindrot.org/show_bug.cgi?id=2817 Bug ID: 2817 Summary: Add support for PKCS#11 URIs (RFC 7512) Product: Portable OpenSSH Version: 7.6p1 Hardware: Other OS: Linux Status: NEW Severity: enhancement Priority: P5 Component: Smartcard Assignee: unassigned-bugs at

Hello, The version 0.07 of "PKCS#11 support in OpenSSH" is published. Changes: 1. Updated against OpenSSH 4.3p1. 2. Ignore '\r' at password prompt, cygwin/win32 password prompt support. 3. Workaround for iKey PKCS#11 provider bug. 4. Some minor cleanups. 5. Allow clean merge of Roumen Petrov's X.509 patch (version 5.3) after this one. [[[ The patch-set is too large for

ping. I've been using Alon's patch and following his arguments on this list for a while. I want to add my voice to say that the current opensc support should be completely replaced with pkcs#11 support, since it is the right way to handle smart cards. The use case that my organization wants is to use the TPM chips available in most machines as our primary smartcard mechanism,

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 >

Hi Chris, > There's a couple of headless systems on the LAN where login security > is important to me and I've been thinking about the relative merits of > password and public-key authentication. > <snip> At home, I have a smaller LAN than you, but at $DAYJOB I work with much bigger fleets. Whether at home or work, everything is Linux-based, and OpenSSH is the primary

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

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

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

Hello, The version 0.11 of "PKCS#11 support in OpenSSH" is published. Changes: 1. Updated against OpenSSH 4.3p2. 2. Modified against Roumen Petrov's X.509 patch (version 5.4), so self-signed certificates are treated by the X.509 patch now. 3. Added --pkcs11-x509-force-ssh if X.509 patch applied, until some issues with the X.509 patch are resolved. 4. Fixed issues with gcc-2. You