similar to: Any interest in a patch for setting the syslog facility for the ssh client?

To revive this thread - I filed a bug in bugzilla.mindrot.org ( Bug 2705 - https://bugzilla.mindrot.org/show_bug.cgi?id=2705 ). I have a patch attached to the email that implements this as well. I wasn't able to find a list of coding standards or contribution guidelines for OpenSSH, so please correct me if I'm wrong. I'd also like to thank Jakuje for helping me out with some info on

Darren, Thanks, evidently I need to practice my reading skills. I did some practice on the style guide, and I believe that I have the patch fixed up per the style guidelines. I've attached the new patch to this email for review. Cheers, Ethan On Fri, Apr 7, 2017 at 5:02 AM, Darren Tucker <dtucker at zip.com.au> wrote: > On Fri, Apr 7, 2017 at 4:45 PM, Ethan Rahn <ethan.rahn at

Ben, Thanks for the tip! I've added the patch to Bug 2705 on bugzilla. Cheers, Ethan On Fri, Apr 7, 2017 at 11:33 AM, Ben Lindstrom <mouring at offwriting.org> wrote: > > The mailinglist strips out attachments. So either you need to add it to > the bug or post it in-line to the email. > > Ben > > Ethan Rahn wrote: > > Darren, > > Thanks, evidently I

On Tue, Apr 25, 2017 at 5:38 AM, Ethan Rahn <ethan.rahn at gmail.com> wrote: > Hello, > > I wanted to check back in. It doesn't look like anyone has commented on the > patch. Is there someone I should prod to get this looked at? > Sorry, it came in just as we were prepping for the 7.5 release and we generally only take bug fixes at that point. I've added it to the

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

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 transition to ( rsa-sha2-256 and rsa-sha2-512 ) even though they are supported. Looking through the code, it looks like an issue with the arguments passed to sshkey_alg_list in ssh.c where it should

I don't think there is any point to generate so many moduli. Actually, 3 moduli of sizes 2048, 3072 and 4096 seem like a sane choice. On Fri, Feb 15, 2019 at 7:58 AM Darren Tucker <dtucker at dtucker.net> wrote: > > On Fri, 15 Feb 2019 at 14:22, Yegor Ievlev <koops1997 at gmail.com> wrote: > > I'm not nearly knowledgeable enough in crypto to fully understand your

Hello. I've got a question about encoding in sshd's log files. When I try to log in with a "?" username, which is a cyrillic "h" (U+0445), I get this message in a logfile: input_userauth_request: invalid user \\321\\205 [preauth]. I am struggling to understand: is that hex, is that octal? It doesn't map to any encoding that I know of.

On SPARC Solaris 10, using Solaris' native OpenSSL and Solaris Studio 12.2, I got the following errors: run test agent-getpeereid.sh ... ssh-add did not fail for nobody: 1 < 2 failed disallow agent attach from other uid gmake[1]: *** [t-exec] Error 1 gmake[1]: Leaving directory `/scratch/wieland/src/openssh/openssh-SNAP-20180817/regress' gmake: *** [tests] Error 2 -- Jeff Wieland,

That doesn't seem to be the case. See https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf (5.6.1 Comparable Algorithm Strengths) On Fri, Feb 15, 2019 at 8:28 AM Darren Tucker <dtucker at dtucker.net> wrote: > > On Fri, 15 Feb 2019 at 16:00, Yegor Ievlev <koops1997 at gmail.com> wrote: > > I don't think there is any point to generate so

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",

On Tue, Aug 2, 2016 at 12:52 AM, Darren Tucker <dtucker at zip.com.au> wrote: [...] >> Seems can't. But why? 7.2 does. > > Dunno, I can't think of any obvious changes to compiler flags. Maybe > try it without setting CFLAGS? OK, I think I see why it started in 7.3: it was when the wide character support was added. In configure.ac: dnl Wide character support. Linux

On Thu, Jul 21, 2016 at 1:34 PM, Selphie Keller <selphie.keller at gmail.com> wrote: > yeah I like this idea, fixes the issue with blowfish hashes and non root > passwords, maybe random delay as the final fall back if no salts/passwords > are found. Well if there are no accounts with a valid salt then there's also no valid account to compare the timing of invalid accounts

Hi All, Actually I am working with the OpenSSH version 6.2p which is vulnerable to above mentioned vulnerabilities (CVE-2016-6210). So am looking for some help how I can fix these vulnerabilities in my version. I need to fix it in the OpenSSH code. Regards Abhishek

I've been struggling with the OpenSSH 3.8.1p1-1 installation on windows 10, it does not finishes, gives no errors or messages, just stays like this: [image: openssh-install.jpg] Can someone help me with this please? Thanks! -- Atenciosamente, Daniel Cavalcanti Costa.

So far on FreeBSD 11.1 reject openssl 1.1.0 make with Openssl 1.0.2 l no issues Attempt to test in openssl 1.0.2m -dev -fips chokes on tests. -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! https://www.empire.kred/ROOTNK?t=94a1f39b Look at Psalms 14 and 53 on Atheism Talk

OpenSSL_add_all_algorithms has been deprecated with 1.1. Compatibility is needed. Signed-off-by: Rosen Penev <rosenp at gmail.com> --- ssh-keysign.c | 1 + ssh_api.c | 2 ++ 2 files changed, 3 insertions(+) diff --git a/ssh-keysign.c b/ssh-keysign.c index 744ecb4f..bcd1508c 100644 --- a/ssh-keysign.c +++ b/ssh-keysign.c @@ -40,6 +40,7 @@ #include <openssl/evp.h> #include

A non-text attachment was scrubbed... Name: 0001-Remove-unused-since-ssh1-protocol-removal-crc32.-ch.patch Type: text/x-patch Size: 20097 bytes Desc: not available URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20190206/ca9d8d10/attachment-0001.bin>

Hi, I am Vishwanath, I got one requirement from our clients regarding remote authentication. In which all users info present in remote user database. Currently using openssh for SSH connections. To open a new remote session via SSH, the openssh will look into the /etc/passwd file. If user present then it will allow to login using password or key authentication. But in my case all user info is

On Wed, Jul 20, 2016 at 09:02:57PM -0600, Selphie Keller wrote: > I wonder if could be useful to set the fall back account to something user > defined to avoid suggesting people add passwords to root, though I do like > root since the account is always there, Since committing that diff I've heard of people running in production with no root password (ie *LK*, !! or similar).