similar to: PrivateKeyCommand config idea

BTW not for your usecase with the decryption, but if people want to dynamically create/provision short lived keys, they could use ?match host * exec gen-key.sh %s? config to run a program before each connection. However it can?t stdout the key material, but what it could do is update a temporary Idendity file or push it short-lived with ssh-add to the running (standard) agent. openssh at tr.id.au

On Mon, Mar 11, 2024, at 6:05 PM, Bernd Eckenfels wrote: > BTW not for your usecase with the decryption, but if people want to > dynamically create/provision short lived > keys, they could use ?match host * exec gen-key.sh %s? config to run a > program before each connection. > However it can?t stdout the key material, but what it could do is > update a temporary Idendity file

Hey Damien, > Would you be able to do this using the ssh-agent protocol? It's > relatively easy to make custom agent implentations for special use > cases, e.g. using https://pkg.go.dev/golang.org/x/crypto/ssh/agent#Agent Hmm, okay, I just realized the protocol has a full specification at https://datatracker.ietf.org/doc/html/draft-miller-ssh-agent. Would it be possible to get that

G'day, In our infrastructure we're trying to be more diligent about switching to sk keys (and/or certs backed by sk keys.) However, there are some services like Gerrit and Jenkins which are written in java and I guess they will never support sk keys, or at least, it seems like it won't happen any time soon. For such services, typical practices at the moment include putting

On Fri, 8 Mar 2024, openssh at tr.id.au wrote: > G'day, > > In our infrastructure we're trying to be more diligent about switching > to sk keys (and/or certs backed by sk keys.) However, there are some > services like Gerrit and Jenkins which are written in java and I guess > they will never support sk keys, or at least, it seems like it won't > happen any time

BTW based on your output it looks like the DEFAULT policy is just fine, If you really want to turn etm HMAC and chacha20 off, you should follow the RHEL security alert https://access.redhat.com/security/cve/cve-2023-48795 cipher at SSH = -CHACHA20-POLY1305 ssh_etm = 0 by putting these lines into `/etc/crypto-policies/policies/modules/CVE-2023-48795.pmod`, applying the resulting subpolicy

Hi there, > So there could be a Chacha20-Poly1305v2 at openssh.com which uses AD data to chain the > messages together, so it will be resistant against terrapin even without the strict-kex. > > Consequently the hmac-etmv2 at openssh.com mode could be deviced in a similar manner, to > also include the transcript hash or similar things. This would still require both, client and

Hello, since one currently (after the 9.6 release addressing terrapin with strict-kex) cant be sure that strict KEX mode is negotiated (it depends on the capabilities of the partner), and the mitigation for that is to disable most modern/alternative ciphers and MAC modes - I would suggest you offer the option to enforce strict-kex mode as a server config as well as a per-host config in the

----- Am 8. Nov 2016 um 16:22 schrieb Johannes Ranke johannes.ranke at jrwb.de: > Hallo Bernd, > > das heisst die gleiche Fehlermeldung bei "configure"? > > Gru?, > > Johannes > > Am Dienstag, 8. November 2016, 15:45:15 schrieb Lentes, Bernd: >> ----- Am 8. Nov 2016 um 15:26 schrieb Johannes Ranke johannes.ranke at jrwb.de: >> > Hi >>

Hi all, > On Jun 5, 2017, at 11:52 PM, Andrew James Weaver <weevz at uw.edu> wrote: > > Hello all! > (cc-ing the flac-dev list) > > I would like to give an update as to the recent CELLAR work on the FLAC specification. > > • Work has been done to make internal and external links more accurate and reliable. > • 'Rice Coding' has been clarified as

Hi Christof! AFAIK, PowerDNS is the only open source name server that supports ALIAS. There was an idea to standardize ALIAS as "ANAME" (https://datatracker.ietf.org/doc/draft-ietf-dnsop-aname/), but the idea was dropped in favor of SVCB/HTTPS record https://datatracker.ietf.org/doc/rfc9460/. So now we have to wait until all Browser vendors implement SVCB/HTTPS. Regards Klaus PS: If

Dear alltogether, two lme's, the data are available at: http://www.anicca-vijja.de/lg/hlm3_nachw.Rdata explanations of the data: nachw = post hox knowledge tests over 6 measure time points (= equally spaced) zeitn = time points (n = 6) subgr = small learning groups (n = 28) gru = 4 different groups = treatment factor levels: time (=zeitn) (n=6) within subject (n=4) within smallgroups

Dear members of the flac-dev list, I'm writing to ask for feedback from the FLAC community regarding the possibility of standardizing the FLAC specification through the Internet Engineering Task Force. I'm working with MediaArea on the PREFORMA project which focuses on building conformance checkers for Matroska and FFV1. Since Matroska and FFV1 are not yet formally standardized, this

Hi Michael, Here's some more minor comments below. As long as you address the two comments from my previous email (254 -> 2 and the draft name), the draft is good for submitting as initial version on the IETF website (even if you don't address all the minor comments from this email). FYI, this is the address for submitting a new draft: https://datatracker.ietf.org/submit/

Hi all, I'm jumping in on this thread to make a few remarks about the spec. I implemented a FLAC decoder by only looking at the spec, and I have a few notes that would have saved me a lot of time if the spec had mentioned them. They are obvious in hindsight, of course. * If the channel assignment includes a difference channel, then the subframe for that channel has one extra bit per sample

Hi Ruud van Asseldonk, > On Jun 11, 2017, at 7:24 AM, Ruud van Asseldonk <dev at veniogames.com> wrote: > >>> I'm jumping in on this thread to make a few remarks about the spec. I >>> implemented a FLAC decoder by only looking at the spec, and I have a few >>> notes that would have saved me a lot of time if the spec had mentioned >>> them. They

Dear all, A new IETF working group is being formed, chartered to maintain SSH protocol specifications. Please see the below announcement for more information. Kind regards, Job ----- Forwarded message from Deb Cooley <debcooley1 at gmail.com> ----- Date: Tue, 13 Aug 2024 18:24:56 -0400 From: Deb Cooley <debcooley1 at gmail.com> To: SSH at ietf.org Subject: [Ssh] draft charter

[I tried to send this message privately, but the return address bounced.] I think this has been fixed in R-patched, but I doubt if the fix has been tested in Win98. Could you please download a copy from <http://cran.r-project.org/bin/windows/base/rpatched.html> and confirm that it has been fixed? Duncan Murdoch On Sat, 27 Nov 2004 23:31:23 +0100, Heinz Tuechler <tuechler at gmx.at>

While SVCB/HTTPS provides a better solution for the browsing use case, I see other use cases where ALIAS/ANAME would be ideal, notably in apex RRs. So while fostering SVCB/HTTPS deployment is a good thing, I wouldn?t mind name server software implementing ALIAS. Including NSD, but I reckon it?s much more challenging to do due to NSD architecture than it was to implement it in PowerDNS. But if

On Wed, May 22, 2019, at 23:43, Tanstaafl via dovecot wrote: > On Wed May 22 2019 05:44:59 GMT-0400 (Eastern Standard Time), Aki Tuomi > via dovecot <dovecot at dovecot.org> wrote: > > Unfortunately we have not been able to work on this much, but also the > > JMAP spec was until very recently still being worked. We have open > > dialogue with the Thunderbird people,