search for: jtesta

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

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

On 09/22/2017 03:22 PM, Daniel Kahn Gillmor wrote: > On Thu 2017-09-21 18:12:44 -0400, Joseph S Testa II wrote: >> I gotta say... having a fallback mechanism here seems pretty >> strange. The entire point of the group exchange is to use a dynamic >> group and not a static one. > > fwiw, i think dynamic groups for DHE key exchange is intrinsically > problematic

On 09/22/2017 06:55 PM, Tim Broberg wrote: > Do I understand correctly, that you find the security of group 14 unacceptable and yet you left it enabled? In the end, I'm trying to ensure a minimum equivalent of 128-bits of security. Group14 is 2048-bits, which roughly translates to 112-bits. [1] To this end, I disabled the "diffie-hellman-group14-sha1" and

...her than P-256 in the wild. Yubicos U2F only keys for example are currently listed on their site as only having P-256 support. I imagine multi-purpose keys might have more expansive support though. RS256 also appears to be marked as deprecated. On Sat, Nov 2, 2019 at 7:54 PM Joseph S. Testa II <jtesta at positronsecurity.com> wrote: > > On 11/1/19 4:36 AM, Damien Miller wrote: > > new key type "sk-ecdsa-sha2-nistp256 at openssh.com" > > Was ECDSA with NIST P-256 strictly necessary, or would Ed25519 be > possible as well? > > Thanks, > - Joe &gt...

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 09/24/2017 12:21 AM, Mark D. Baushke wrote: > I suggest you upgrade to a more recent edition of the OpenSSH software. > The most recent release is OpenSSH 7.5 and OpenSSH 7.6 will be released > very soon. This problem is in v7.5 and v7.6. See dh.c:436. > OpenSSH 6.6 was first released on October 6, 2014. I brought up v6.6 to give an example that older clients wouldn't be

Hi, As of this morning, OpenSSH now has experimental U2F/FIDO support, with U2F being added as a new key type "sk-ecdsa-sha2-nistp256 at openssh.com" or "ecdsa-sk" for short (the "sk" stands for "security key"). If you're not familiar with U2F, this is an open standard for making inexpensive hardware security tokens. These are easily the cheapest way

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

Hi all, Back in September 2018, I started a thread about implementing the X448 key exchange (see https://lists.mindrot.org/pipermail/openssh-unix-dev/2018-September/037183.html). In February 2020, RFC 8731 (formally specifying X448 in SSH) has been finalized: https://www.ietf.org/rfc/rfc8731.txt. I thought I'd start this conversation up again to see if the interest level has

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

On 09/22/2017 06:10 PM, Mark D. Baushke wrote: > I suppose you want to be more paranoid: > > DH * > dh_new_group_fallback(int max) > { > debug3("%s: requested max size %d", __func__, max); > if (max <= 2048) { > debug3("using 2k bit group 14"); > return dh_new_group14(); > }

Hi all, I'm interested in having X448 protocol available as an option, as it gives a larger security margin over X25519. For anyone unfamiliar, it is an Diffie-Hellman elliptic curve key exchange using Curve448 (defined in RFC7748: https://tools.ietf.org/html/rfc7748). Furthermore, it is included in the new TLS 1.3 specification (RFC8846: https://tools.ietf.org/html/rfc8446).

Hi, I'm interested in requiring a minimum of 3072-bit DH moduli when using the "diffie-hellman-group-exchange-sha256" kex, so I edited my /etc/ssh/moduli file such that only 3071+ moduli are left. However, when clients ask for a max of 2048-bit moduli, they actually get one (!). I poked around and found that a fallback mechanism exists (dh.c:185), which returns back the

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

> Portable OpenSSH is also available via [...] Github: https://github.com/openssh/openssh-portable > > Running the regression tests supplied with Portable OpenSSH does not require installation and is a simply: > > $ ./configure && make tests I was going to try this on Kali Linux (latest version), but ran into trouble right away. No "configure" script exists