similar to: An Analysis of the DHEat DoS Against SSH in Cloud Environments

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

On Tue, 18 Jun 2024, Joseph S. Testa II wrote: > 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? Not explicitly but

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.

On Wed, 2024-06-19 at 09:19 -0400, chris wrote: > real world example (current snapshot of portable on linux v. dheater) Thanks for this. However, much more extensive testing would be needed to show it is a complete solution. In my original research article, I used CPU idle time as the main metric. Also, I showed that very low- latency network links could bypass the existing countermeasures.

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

On Wed, Jun 19, 2024 at 02:10:30PM +1000, Damien Miller wrote: > On Tue, 18 Jun 2024, Joseph S. Testa II wrote: > > > 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

On 6/19/24 4:11 PM, Joseph S. Testa II wrote: > On Wed, 2024-06-19 at 09:19 -0400, chris wrote: >> real world example (current snapshot of portable on linux v. dheater) > > Thanks for this. However, much more extensive testing would be needed > to show it is a complete solution. In my original research article, I > used CPU idle time as the main metric. Also, I showed that

On Wed, 2024-06-26 at 04:32 +0200, Thorsten Glaser wrote: > If they get under attack, they?d better do. And if you?re ignoring > a known bottleneck, the results will probably not be very useful? > besides, not everyone is systemd-infested. The primary responsibility falls on system designers to choose reasonable default settings.

On Tue, 25 Jun 2024, Joseph S. Testa II wrote: >the way down to 6%! Additionally, I noticed that the systemd-journal You should test without that thing as well. It?s reportedly a known bottleneck (someone on, I think, IRC said that regarding a different problem some days ago, incidentally). Just use a real syslogd (inetutils-syslogd is nice, for example, and rsyslogd and syslog-ng both have

On Wed, 2024-06-26 at 02:58 +0200, Thorsten Glaser wrote: > On Tue, 25 Jun 2024, Joseph S. Testa II wrote: > > > the way down to 6%! Additionally, I noticed that the systemd- > > journal > > You should test without that thing as well. It?s reportedly a > known bottleneck (someone on, I think, IRC said that regarding > a different problem some days ago,

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

On Tue, 25 Jun 2024, Joseph S. Testa II wrote: >I'm primarily interested in the performance of the default case, since >the overwhelming majority of sysadmins don't modify any options in sshd >nor syslog. If they get under attack, they?d better do. And if you?re ignoring a known bottleneck, the results will probably not be very useful? besides, not everyone is systemd-infested.

On 6/26/24 7:56 AM, Joseph S. Testa II wrote: > On Wed, 2024-06-26 at 04:32 +0200, Thorsten Glaser wrote: >> If they get under attack, they?d better do. And if you?re ignoring >> a known bottleneck, the results will probably not be very useful? >> besides, not everyone is systemd-infested. > > > The primary responsibility falls on system designers to choose >

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

On Thu, 27 Jun 2024, Chris Rapier wrote: > I think it's really important to get this right. The problem, from my Yes, but if the reason behaviour under DoS is that logging is too slow and/or uses too much CPU, the fix is not to remove logging in the default configuration. bye, //mirabilos -- Infrastrukturexperte ? Qvest Digital AG Am Dickobskreuz 10, D-53121 Bonn ?

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

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, Are there any open source tools to keep track of ssh sessions? For example, if a specific user is ssh logging to remote server and what commands or scripts are being run. Basically, i need to log all users sessions. Thanks in Advance and i look forward to hearing from you. Best Regards, Kaushal

On 09/13/2018 08:18 PM, Damien Miller wrote: > We have any plans to add more crypto options to OpenSSH without a strong > justification, and I don't see one for X448-SHA512 ATM. What I like about it is that it offers ~224 bit security level, whereas X25519 offers ~128 bits (according to RFC7748). Hence, pairing X448 with AES256 would provide a full chain of security in the ~224 bit

Hi Kaushal, I maintain a set of SSH hardening guides for various platforms, including RHEL 8. You can find them here: https://ssh-audit.com/hardening_guides.html - Joe -- Joseph S. Testa II Founder & Principal Security Consultant Positron Security On Thu, 2024-01-25 at 18:39 +0530, Kaushal Shriyan wrote: > Hi, > > I am running the below servers on Red Hat Enterprise