similar to: [Bug 2215] New: Key fingerprint headline slightly broken with ED25519

https://bugzilla.mindrot.org/show_bug.cgi?id=2247 Bug ID: 2247 Summary: [visual host key] fix upper border display Product: Portable OpenSSH Version: 6.6p1 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 Component: ssh Assignee: unassigned-bugs at mindrot.org

Key types are getting longer and the current implementation of visual host key breaks with ED25519, resulting in (note the missing bracket): +--[ED25519 256--+ This reworks the calculation of visual host key upper border. Please be aware that this slightly modifies the output for other key types as well: +--[ DSA 1024]----+ +---[DSA 1024]----+ +--[ RSA 2048]----+ +---[RSA 2048]----+

Key types are getting longer and the current implementation of visual host key breaks with ED25519, resulting in (note the missing bracket): +--[ED25519 256--+ This reworks the calculation of visual host key upper border. Please be aware that this may change the output for other key types as well. --- key.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/key.c

I have to actions: def index @articles = Article.find(:all, :conditions => "un_published != ''1''", :order => "created_on desc") end and def group id = params[:id] @articles = ArticleGroup.find(:all, :include => [:group, :article], :conditions => ["articles.un_published !=

Hello, Maybe I'm asking an already answered question, if yes I'm sorry to bother you. Why in default HostKeyAlgorithms settings is ecdsa-sha2-nistp256-cert-v01 at openssh.com preferred over ssh-ed25519-cert-v01 at openssh.com ? For example in default settings for KexAlgorithms the curve25519-sha256 at libssh.org is preferred over ecdh-sha2-nistp256. Fedor Defaults in openssh-6.6p1

https://bugzilla.mindrot.org/show_bug.cgi?id=2271 Bug ID: 2271 Summary: Regression test #89 "fuzz Ed25519 sig" fails under Solaris Product: Portable OpenSSH Version: 6.6p1 Hardware: All OS: Solaris Status: NEW Severity: normal Priority: P5 Component:

Dear all, Ed25519 public keys being as small as they are is very convenient. There is an opportunity to nudge the world towards modern algorithms. I believe choices made in OpenSSH can positively impact the wider eco-system and industry. I'd like to suggest ssh-keygen to generate an Ed25519 keypair, if invoked without any arguments. OpenSSH has supported Ed25519 since version 6.5 (January

hi, I've created a small script to get a sum from the users and sessions (table username and table "#"), but it is annoying that the headline "username # proto (pids) (ips)" goes to STDERR, but the normal output to STDOUT. It would be nice, if both goes to the same STD :-) cu denny -------------- next part -------------- A non-text attachment was scrubbed... Name:

https://bugzilla.mindrot.org/show_bug.cgi?id=2223 Bug ID: 2223 Summary: Ed25519 support in SSHFP DNS resource records Product: Portable OpenSSH Version: -current Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 Component: ssh Assignee: unassigned-bugs at

On Tue, Jan 26, 2016 at 07:35:10PM +0100, Anton Voyl wrote: > Is it possible to sign/verify data with the ed25519 keys of a tinc 1.1 host? In principle yes, but tinc does not offer a way to do that. Also, reusing a key for another purpose is not recommended. What do you want to do exactly? > More specifically, is it possible to sign a file with these keys using openssl? If so, how? If

https://bugzilla.mindrot.org/show_bug.cgi?id=3195 Bug ID: 3195 Summary: ssh-keygen unable to convert ED25519 public keys Product: Portable OpenSSH Version: 8.2p1 Hardware: amd64 OS: Linux Status: NEW Severity: enhancement Priority: P5 Component: ssh-keygen Assignee:

Hello. Subramanian Moonesamy has gotten the ball rolling to include Ed25519 in IANA's registry for SSHFP key types [1]. I've opened a bug report [2] that includes a patch that adds the needed support code and provisionally assigns Ed25519 a value of 4 (values 1,2,3 reserved for RSA, DSA, and ECDA, respectively) [3]. The enhancement request/bug is meant to keep the issue on the radar.

Hi, Markus has just committed a few changes that add support for the Ed25519 signature algorithm[1] as a new private key type. This algorithm has a few benefits: it is fast (comparable to ECDSA and RSA), offers 256-bit security and doesn't require random numbers to generate a signature. This last property means it completely avoids (EC-)DSA's horrible, private-key leaking problem when fed

https://bugzilla.mindrot.org/show_bug.cgi?id=2179 Bug ID: 2179 Summary: ed25519 make install support Product: Portable OpenSSH Version: -current Hardware: All OS: All Status: NEW Severity: normal Priority: P5 Component: Build system Assignee: unassigned-bugs at mindrot.org

https://bugzilla.mindrot.org/show_bug.cgi?id=3202 Bug ID: 3202 Summary: Ed25519 key on HSM is not getting listed in ssh-add -l command Product: Portable OpenSSH Version: 8.2p1 Hardware: ARM64 OS: Linux Status: NEW Severity: enhancement Priority: P5 Component: ssh-add

My intention was to sign the content of export-all with the nodes' public key, which would require the corresponding private key to verify. Does this make sense ? @ > Le 26 janv. 2016 ? 20:19, Guus Sliepen <guus at tinc-vpn.org> a ?crit : > >> On Tue, Jan 26, 2016 at 07:35:10PM +0100, Anton Voyl wrote: >> >> Is it possible to sign/verify data with the ed25519

What I'm hearing in this thread is: "a minority of people on planet Earth have a problem with the open-source implementation of ED25519, but instead of letting that minority choose to re-implement it when/if they want to, the rest of the community needs to stall their progress in improving security." And isn't the ED25519 code is already there on their machine? So isn't

Here you go: OpenSSH_7.9p1, OpenSSL 1.1.1d 10 Sep 2019 debug1: Reading configuration data /home/ryantm/.ssh/config debug1: /home/ryantm/.ssh/config line 4: Applying options for * debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 13: Applying options for * debug2: resolving "{REDACTED}" port 22 debug2: ssh_connect_direct debug1: Connecting to

Hello. I am running OpenSSH 7.9p1 on my client and server. ssh-keyscan shows the server has ssh-rsa, ssh-ed25519, and ecdsa-sha2-nistp256 host keys. My /etc/ssh/ssh_known_hosts file contains the server's ssh-ed25519 host key. When I try to SSH to the server I get this error: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!

https://bugzilla.mindrot.org/show_bug.cgi?id=2197 Bug ID: 2197 Summary: Add ED25519 support to SSHFP dns record Product: Portable OpenSSH Version: -current Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 Component: ssh Assignee: unassigned-bugs at