similar to: [Bug 3705] New: Disk space exhaustion from PerSourcePenalties logging

On Wed, 2024-06-19 at 16:11 -0400, Joseph S. Testa II wrote: > I suppose in the next few days, I'll try reproducing my original > steps > with the new version and see what happens. I managed to do some limited testing with a local VM, and the results are... interesting. I installed openssh-SNAP-20240626.tar.gz on a fresh and fully-updated Ubuntu Linux 24.04 LTS VM with 1 vCPU.

https://bugzilla.mindrot.org/show_bug.cgi?id=3766 Bug ID: 3766 Summary: openssh PerSourcePenalties and pam_nologin interaction Product: Portable OpenSSH Version: 9.8p1 Hardware: ARM64 OS: Linux Status: NEW Severity: normal Priority: P5 Component: PAM support Assignee:

I'd like to withdraw the last set of metrics I reported. I couldn't reproduce some of them, and I suspect I made a mistake during testing. Being more careful this time, I set up another fully updated Ubuntu 24.04 VM with 4 vCPUs running openssh-SNAP-20240628.tar.gz with all defaults unchanged. When running using "ssh-audit.py --conn-rate-test=16 target_host", the system idle

Damien Miller <djm at mindrot.org> writes: > On Mon, 9 Dec 2024, Dmitry Belyavskiy wrote: > >> Dear colleagues, >> >> Can we somehow improve the UX related to a relatively freshly >> introduced PerSourcePenalties option? >> >> A popular pattern implies installation of the users' keys to a freshly >> installed machine using ssh-copy-id

In the upcoming v9.8 release notes I see "the server will now block client addresses that repeatedly fail authentication, repeatedly connect without ever completing authentication or that crash the server." Has this new PerSourcePenalties config directive been tested against the DHEat attack? - Joe On Thu, 2024-04-25 at 18:09 -0400, Joseph S. Testa II wrote: > A few days ago, I

Dear colleagues, Can we somehow improve the UX related to a relatively freshly introduced PerSourcePenalties option? A popular pattern implies installation of the users' keys to a freshly installed machine using ssh-copy-id script. The default settings don't allow this command to work normally and causes login failures. A reasonable workaround could be adding some threshold for a number

Hi, A few people have requested rate-limiting for PerSourcePenalties logging. These patches add it. Please give them a try if you're interested in this feature. -d -------------- next part --------------

i'm not sure if anything has changed since https://marc.info/?l=openbsd-misc&m=151233345723889&w=2 On Wed, Jun 26, 2024 at 9:32?AM Joseph S. Testa II <jtesta at positronsecurity.com> wrote: > > Has anyone done any initial research into how much effort it would take > to port OpenSSH to Rust? If not, I might find that interesting to > start. (Mind you, this would

https://bugzilla.mindrot.org/show_bug.cgi?id=2793 Bug ID: 2793 Summary: DH Group Exchange Incorrect Fallback Product: Portable OpenSSH Version: -current Hardware: All OS: All Status: NEW Severity: major Priority: P5 Component: sshd Assignee: unassigned-bugs at mindrot.org

On Mon, 9 Dec 2024, Dmitry Belyavskiy wrote: > Dear colleagues, > > Can we somehow improve the UX related to a relatively freshly > introduced PerSourcePenalties option? > > A popular pattern implies installation of the users' keys to a freshly > installed machine using ssh-copy-id script. The default settings don't > allow this command to work normally and

I've had a patch on the bugzilla for a while related to U2F with support for a few additional settings such as providing a path to a specific key to use instead of the first one found and setting if user presence is required when using the key. Is there any objection to folding those parts in if appropriate? Joseph, to offer comment on NIST P-256. There was originally quite a limited subset

Hi, I admin a box that has Subversion users authenticate with public keys to a restricted 'svnuser' account. The comment field of all the keys describe who they belong to (it has their usernames), but unfortunately, sshd does not log this when a user successfully authenticates: Jun 21 08:18:22 localhost sshd[23636]: Accepted publickey for svnuser from x.x.x.x port 2065 ssh2 Jun

A few days ago, I published an article analyzing the susceptibility of the DHEat denial-of-service vulnerability against default OpenSSH settings in cloud environments. I thought those on this list might be interested: https://www.positronsecurity.com/blog/2024-04-23-an-analysis-of-dheat-dos-against-ssh-in-cloud-environments/ A short summary: the default MaxStartup setting is fully ineffective

subject: ssh non-intuitive logging setting (priority names). I installed openssh 2.3.0p1 on Solaris 7 for x86 box and sshd worked fine. However, somehow the logging of connection and disconnection to sshd was not recorded as I wished. Time to investigate. On a host where sshd from data-fellows once ran, the log was recorded with auth.info level. After trying to modify sshd_config, I found that

The attached modification to log-server.c add a "tag" to all the syslog output. The tag is a composite of the internal verbose level names used in sshd and the external syslogd names. The form of the tag is as follows. ssh_internal_name(syslog_priority) This might be instructive for a learning sysadmin trying to setup syslog for sshd logging. (I have posted earlier about

Asterisk Project Security Advisory - AST-2016-007 Product Asterisk Summary RTP Resource Exhaustion Nature of Advisory Denial of Service Susceptibility Remote Authenticated Sessions Severity Moderate

Asterisk Project Security Advisory - AST-2017-004 Product Asterisk Summary Memory exhaustion on short SCCP packets Nature of Advisory Denial of Service Susceptibility Remote Unauthenticated Sessions Severity

Has anyone done any initial research into how much effort it would take to port OpenSSH to Rust? If not, I might find that interesting to start. (Mind you, this would be just to get a handle on the project, not do the full porting work--unless it somehow turns out to be very easy.) - Joe -- Joseph S. Testa II Founder & Principal Security Consultant Positron Security

Hello, Just in case someone hasn't upgraded yet, and is using IAX2. -------- Original Message -------- Subject: AST-2009-006: IAX2 Call Number Resource Exhaustion Date: Thu, 03 Sep 2009 17:47:35 -0500 From: Asterisk Security Team <security at asterisk.org> To: bugtraq at securityfocus.com Asterisk Project Security Advisory - AST-2009-006

Open-Xchange Security Advisory 2020-08-12 Affected product: Dovecot IMAP server Internal reference: DOP-1849 (Bug ID) Vulnerability type: Uncontrolled recursion (CWE-674) Vulnerable version: 2.0 Vulnerable component: submission, lmtp, lda Fixed version: 2.3.11.3 Report confidence: Confirmed Solution status: Fix available Vendor notification: 2020-04-23 CVE reference: CVE-2020-12100 CVSS: 7.5