similar to: ssh-keygen :: PEM_write_RSA_PUBKEY failed

ssh-keygen already supports importing and exporting ssh keys using various formats. The "-m PEM" which should have been the easiest to be used with various of external application expects PKCS#1 encoded key, while many applications use SubjectPublicKeyInfo encoded key. This change adds SubjectPublicKeyInfo support, to ease integration with applications. Examples: ## convert

Hi, I needed to convert a public RSA key to autorized_keys format and found ssh-keygen lacking this feature. I made the option -Q publicfile to allow an conversion like ssh-keygen -Q pubrsa.pem -y The patch is produced using unified diff and made on latest release. If you like it and can make a patch for the man-page also! Regards, /Lars -------------- next part -------------- diff -u

https://bugzilla.mindrot.org/show_bug.cgi?id=2567 Bug ID: 2567 Summary: Wrong terminology used for ssh-keygen "-m" option Product: Portable OpenSSH Version: 6.6p1 Hardware: Other OS: All Status: NEW Severity: normal Priority: P5 Component: Documentation Assignee:

Add private key protection information extraction to shh-keygen using -v option on top of -y option which is already parsing the private key. Technically, the passphrase isn't necessary to do this, but it is the most logical thing to do for me. Adding this to -l option is not appropriate because fingerprinting is using the .pub file when available. An other idea is to add a new option, I

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:

https://bugzilla.mindrot.org/show_bug.cgi?id=2369 Bug ID: 2369 Summary: `ssh-keygen -A` errors on RSA1 when building with SSH1 disabled Product: Portable OpenSSH Version: 6.9p1 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 Component: ssh-keygen

https://bugzilla.mindrot.org/show_bug.cgi?id=2116 Bug ID: 2116 Summary: SSH to Nortel/Avaya switch fails Product: Portable OpenSSH Version: 6.2p1 Hardware: All OS: All Status: NEW Severity: major Priority: P5 Component: ssh Assignee: unassigned-bugs at mindrot.org

Looking at ssh-keygen.c from openssh-6.2p2.tar.gz lines 186-187: if (type == KEY_DSA && *bitsp != 1024) fatal("DSA keys must be 1024 bits"); It appears to me that ssh-keygen will only generate 1024 bit DSA keys. Is that still current? FIPS 186-3 (2009-06) section 4.2 and FIPS 186-4 [1] (2013-07) section 4.2 state: 4.2 Selection of Parameter Sizes

On Fri, Feb 17, 2017 at 09:28:52AM +1100, Darren Tucker wrote: [...] > so yeah, ssh-keygen should have probably errored out "unsupported key type". diff --git a/sshkey.c b/sshkey.c index 4768790..f45e239 100644 --- a/sshkey.c +++ b/sshkey.c @@ -89,7 +89,9 @@ static const struct keytype keytypes[] = { { "ssh-ed25519-cert-v01 at openssh.com", "ED25519-CERT",

OpenSSH 6.1 has just been released. It will be available from the mirrors listed at http://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 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,

OpenSSH 6.1 has just been released. It will be available from the mirrors listed at http://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 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,

https://bugzilla.mindrot.org/show_bug.cgi?id=3724 Bug ID: 3724 Summary: Unable to convert from OpenSSH to PKCS8 or PEM Product: Portable OpenSSH Version: 9.8p1 Hardware: amd64 OS: Linux Status: NEW Severity: normal Priority: P5 Component: ssh-keygen Assignee: unassigned-bugs

Hello, I had some difficulties in order to convert private keys between different implementations of SSH. So, I wrote the following patch to allow export of SSH2 RSA and DSA private keys into IETF SECSH format. Note that I also slightly revised the IETF SECSH key import code. Usage: use of the "-e" option on a private key file generates an unencrypted private key file in IETF SECSH

https://bugzilla.mindrot.org/show_bug.cgi?id=2180 Bug ID: 2180 Summary: Improve the handling of the key comment field Product: Portable OpenSSH Version: 6.4p1 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 Component: ssh-keygen Assignee: unassigned-bugs

Hello, I need to allow for some people to execute ssh with one shared private key for remote executing command on various machines. However, it is not possible to set group permissions for private keys and it is possible to have just one private key file for one user. Please, is it possible to add patches into openssh development tree like these, so that standard behavior of ssh is not changed,

Hello all, I recently found myself wanting to run sshd with passphrase-protected host keys rather than the usual unencrypted format, and was somewhat surprised to discover that sshd did not support this. I'm not sure if there's any particular reason for that, but I've developed the below patch (relative to current CVS at time of writing) that implements this. It prompts for the

https://bugzilla.mindrot.org/show_bug.cgi?id=2332 Bug ID: 2332 Summary: Show more secure fingerprints than MD5 (e.g. SHA256) in ssh and ssh-keygen Product: Portable OpenSSH Version: 6.6p1 Hardware: Other OS: All Status: NEW Severity: enhancement Priority: P5

A Feature Request for OpenSSH 3.x: In version 2.x, when prompting for the passphrase ssh would print a prompt including the comment string from an RSA key, like: Enter passphrase for RSA key 'Your Dog's Name': The comment string was a useful way to remind the user what the passphrase was (i didn't use hints quite this easy :-). In Openssh 3.0, ssh prompts using the filename:

Dear R-developers, As part of our package building process, we maintain internal CRAN-like repositories of our packages. This has worked pretty well, but we are running into issues with R 3.1 and OSX mavericks. Specifically, machines with osx mavericks seem to, by default, expect packages to be located under a 'mavericks' sub-directory, but this is not the location reported when

OpenSSH 8.1 has just been released. It will be available from the mirrors listed at http://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