similar to: Sign/verify data with ed25519 keys of a tinc 1.1 host

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

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

On Tue, Jan 26, 2016 at 08:35:15PM +0100, Anton Voyl wrote: > 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 ? Yes, that does make a lot of sense. I'll see if I can add a safe way to sign/verify arbitrary data with the tinc command. -- Met vriendelijke groet /

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!

On Tue, Jan 26, 2016 at 08:52:29PM +0100, Guus Sliepen wrote: > > 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 ? > > Yes, that does make a lot of sense. I'll see if I can add a safe way to > sign/verify arbitrary data with the tinc

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

Get the following error: root at x065:[/data/prj/openbsd/openssh/openssh-7.7p1/openbsd-compat]make ??????? xlc_r -I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5 -q64 -I. -I.. -I../../src/openssh-7.7p1/openbsd-compat -I../../src/openssh-7.7p1/openbsd-compat/.. -I/opt/include -DHAVE_CONFIG_H -c ../../src/openssh-7.7p1/openbsd-compat/strndup.c

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

There is no /root/.ssh/authorized_keys on remote host, so I have to authenticate with password. On the remote host: # /usr/sbin/sshd -T | egrep permitroot permitrootlogin yes Attempting: $ ssh root@<remotehost> shows: Received disconnect from <remotehost> port 22:2: Too many authentication failures for root packet_write_wait: Connection to <remotehost> port 22: Broken

Greetings, I discovered an issue in the latest version of SSH, where the number of password prompts are doubled. If I specify 1, I get 2, and so on. Best regards, Trey Henefield, CISSP Senior IAVA Engineer Ultra Electronics Advanced Tactical Systems, Inc. 4101 Smith School Road Building IV, Suite 100 Austin, TX 78744 USA Trey.Henefield at ultra-ats.com Tel: +1 512 327 6795 ext. 647 Fax: +1

On 23/04/2018 11:49, Michael Felt wrote: > On 21/04/2018 16:21, Michael Felt wrote: > > > Question: I have not dug into the tests yet. Will copy to a "local" > directory, and not build out of tree and see if that fixes it (as it > does for many other packages). However, just in case it does not - how > can I fast-forward the tests to the "agent" tests?

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.

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

https://bugzilla.mindrot.org/show_bug.cgi?id=2667 Bug ID: 2667 Summary: ssh-add does not display key comments for the first key added Product: Portable OpenSSH Version: -current Hardware: All OS: All Status: NEW Severity: minor Priority: P5 Component: ssh-add

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

Darren Tucker <dtucker at zip.com.au> writes: > On Tue, Nov 8, 2016 at 1:02 PM, Harry Putnam <reader at newsguy.com> wrote: > [...] >> gv harry> ssh -vv 2x >> >> OpenSSH_7.3p1-hpn14v11, OpenSSL 1.0.2j 26 Sep 2016 > > this is a third-party modified version of OpenSSH. Can you reproduce > the problem with a stock OpenSSH from the source from

https://bugzilla.mindrot.org/show_bug.cgi?id=2729 Bug ID: 2729 Summary: Can connect with MAC hmac-sha1 even though it's not configured on the server Product: Portable OpenSSH Version: 7.5p1 Hardware: All OS: Linux Status: NEW Severity: security Priority: P5

https://bugzilla.mindrot.org/show_bug.cgi?id=2695 Bug ID: 2695 Summary: inconsistent outout of "ssh.add -l" between ed25519 and rsa keys Product: Portable OpenSSH Version: 7.3p1 Hardware: Other OS: Linux Status: NEW Severity: minor Priority: P5 Component:

Hi, at first I'm not sure if this is the correct list to ask this question. But since I'm using winbind I hope you can help me. I try to realize a kerberized ssh from one client to another. Both clients are member of subdom2.subdom1.example.de and joined to it. The users are from example.de, where subdom1.example.de is a subdomain (bidirectional trust) of example.de and