similar to: "ssh -Q key" does not list rsa-sha2 algorithms

On Tue, 2 Jun 2020 at 06:12, Christian Weisgerber <naddy at mips.inka.de> wrote > On 2020-06-01, Ethan Rahn <ethan.rahn at gmail.com> wrote: > > > With the upcoming deprecation of ssh-rsa I was trying to see what keys my > > version of OpenSSH ( 7.8p1 ) supports. I noticed that "ssh -Q key" does not > > actually list the suggested algorithms to

Hi, I'm doing some test with a pkcs11 token that can only sign short messages. When connecting to one server, that reports pkalg rsa-sha2-512 blen 151, it fails to sign the pubkey because it is 83 bytes long. (sshd: OpenSSH_7.3p1) A older server that reports pkalg ssh-rsa blen 151, works perfectly as the pubkey signature required is only 35 bytes long. (sshd: OpenSSH_6.7p1) I am not sure

The defaults for HostKeyAlgorithms option are: ecdsa-sha2-nistp256-cert-v01 at openssh.com, ecdsa-sha2-nistp384-cert-v01 at openssh.com, ecdsa-sha2-nistp521-cert-v01 at openssh.com, ssh-ed25519-cert-v01 at openssh.com, ssh-rsa-cert-v01 at openssh.com, ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521, ssh-ed25519,ssh-rsa Why does OpenSSH prefer older and less secure

https://bugzilla.mindrot.org/show_bug.cgi?id=2680 Bug ID: 2680 Summary: Regression in server-sig-algs offer in 7.4p1 (Deprecation of SHA1 is not being enforced) Product: Portable OpenSSH Version: 7.4p1 Hardware: Other OS: Linux Status: NEW Severity: enhancement Priority: P5

When I do ssh -Q key, where ssh is the OpenSSH 7.4p1 client, I get the following output: ssh-ed25519 ssh-ed25519-cert-v01 at openssh.com ssh-rsa ssh-dss ecdsa-sha2-nistp256 ecdsa-sha2-nistp384 ecdsa-sha2-nistp521 ssh-rsa-cert-v01 at openssh.com ssh-dss-cert-v01 at openssh.com ecdsa-sha2-nistp256-cert-v01 at openssh.com ecdsa-sha2-nistp384-cert-v01 at openssh.com ecdsa-sha2-nistp521-cert-v01 at

On 2020-02-06 at 13:28 +1100, Darren Tucker wrote: > Like this. > --- a/sshd_config.5 > +++ b/sshd_config.5 The ssh_config.5 also has a copy of this and presumably needs the same change, unless I've misunderstood. -Phil

I uploaded the source tarball and binary releases for win32 and redhat 7. Solaris package should be ready tomorrow. See the news item for all the improvements from 1.0.3: http://flac.sourceforge.net/news.html#20020924 Developers, see the new Doxygen-based API docs: http://flac.sourceforge.net/api/index.html Thanks again to all the contributors and testers. Josh

Christian Weisgerber <naddy@mips.inka.de> wrote: > #0 0x0000000040d18810 in FLAC__lpc_compute_residual_from_qlp_coefficients_wide > (data=0x49e4c014, data_len=110, qlp_coeff=0x7f7ffffece70, order=1, > lp_quantization=14, residual=0x4fced000) at lpc.c:745 > 745 residual[i] = > data[i] - (FLAC__int32)((qlp_coeff[0] *

Running the basic (--disable-thorough-tests) test suite, I get these failures round-trip test (rt-1-24-111.raw) encode... Segmentation fault (core dumped) ERROR FAIL: ./test_flac.sh fsd24-01 (--channels=1 --bps=24 -0 -l 16 --lax -m -e -p): encode...ERROR during encode of fsd24-01 FAIL: ./test_streams.sh on alpha and amd64. By contrast, i386 is fine. (All OpenBSD/4.2.) Could be a generic LP64

On Thu, 6 Feb 2020 at 12:46, Phil Pennock <phil.pennock at globnix.org> wrote: [...] > ssh_config(5) describes for `HostKeyAlgorithms` that: > } The list of available key types may also be obtained using "ssh -Q key" > > Running `ssh -Q key`, the output does not include these proposed > replacements. > > Only in sshd_config(5): > rsa-sha2-512-cert-v01 at

Christian Weisgerber <naddy@mips.inka.de> wrote: > | # nasm build rule: > | %.lo: %.s Even with gmake, this really works only by accident. Automake generates a competing suffix rule, and gmake apparently gives the rule above a higher priority than the suffix rule (or that just happens to be the evaluation order). Matt, since you seem to understand automake, can you come up with

Matt Zimmerman <mdz@debian.org> wrote: > Aha. In FLAC__fixed_restore_signal, the index variable 'i' is declared > unsigned, then used like so: [...] With the following trivial patch applied, > everything works on Alpha, at least with my test sample. Against 0.9 or CVS? While this clearly fixes a bug, 0.9 still dies for me. #0 0x1600692a8 in

https://bugzilla.mindrot.org/show_bug.cgi?id=2650 Bug ID: 2650 Summary: UpdateHostKeys ignores RSA keys if HostKeyAlgorithms=rsa-sha2-256 Product: Portable OpenSSH Version: 7.4p1 Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 Component: ssh

On Tue, Sep 24, 2013 at 10:21 PM, Aris Adamantiadis <aris at 0xbadc0de.be> wrote: [snip] > I've worked this week on an alternative key exchange mechanism, in > reaction to the whole NSA leaks and claims over cryptographic backdoors > and/or cracking advances. The key exchange is in my opinion the most > critical defense against passive eavesdropping attacks. > I believe

The source release for 1.0.1 is finally up on sourceforge. If you are compiling for x86 make sure to read the note in in the README about automake 1.5. Josh __________________________________________________ Do You Yahoo!? Find the one for you at Yahoo! Personals http://personals.yahoo.com

Hello, as a follow-up on my mail some time last month where we were facing weird issues when authenticating to new OpenSSH servers, I went down the road to investigate what is really going on there and I found out that even though all the logs in client and server happily say that the SHA2 extension is used, under the hood there is just SHA1. This is because the different agents are ignoring the

Currently, if IPv6-enabled rsync is run as --daemon, it will perform a wildcard bind(2) on an AF_INET6 socket and expect that IPv4 traffic will be forwarded to the v6 socket (IPv4 mapped address, RFC2553). This has never worked on OpenBSD which disallows IPv4 mapped addresses for security reasons. On FreeBSD 5.0-CURRENT, where the behavior is subject to configuration, the default was switched to

I have checked in all the latest into CVS and am going to start the test suite again. if all goes well I will probably release this as beta 10. this one should have all the configure stuff working with the new assembly infrastructure. I have tried to make it as easy as possible to port routines to assembly. all that's really needed now is to write the corresponding routine for a specific

Problems in FLAC 0.9: - On alpha, flac immediately dumps core for both encoding and decoding (FreeBSD/alpha). - The distribution Makefile.in files haven't been generated with "automake --include-deps". The resulting Makefiles aren't fully portable; in particular they break with BSD make. In the future, care should be taken to use "--include-deps". - What is

Hi, So I finally have time to test the u2f support but so far I haven't been very successful, Specifically, current HEAD has SSH_SK_VERSION_MAJOR 0x00040000 and I can't seem to find a matching libfido2 version, current HEAD of Yubico/libfido2 is 0x00020000 Is there a more up to date libfido2 or a particular commit of openssh-portable I should be using? thanks Sean