Displaying 20 results from an estimated 2000 matches similar to: "OL8 (RHEL8), ssh-rsa turned off using update-crypto-policies, receiving an openssh error that I don't seem to be able to override in my personal .ssh/config file"
2024 Sep 09
2
OL8 (RHEL8), ssh-rsa turned off using update-crypto-policies, receiving an openssh error that I don't seem to be able to override in my personal .ssh/config file
The crypto policies are system-wide to disallow any software (using system crypto) from using unsafe/weak/unwanted algorithm, which is exactly what you are trying to do.
You?ll need to allow that system-wide by default, unfortunately. Luckily you can then disallow ssh-rsa in ssh-config by default and only enable it for a few hosts.
The correct solution is to throw whatever requires it to the
2024 Sep 09
1
OL8 (RHEL8), ssh-rsa turned off using update-crypto-policies, receiving an openssh error that I don't seem to be able to override in my personal .ssh/config file
Lol! Our Security team sent out new policies that dictated turning off
ssh-rsa, so *we did. turns out our Security Team doesn't necessarily
follow their own dictates, so here we are. Our Linux team says that the
correct way to turn off ssh-rsa is via the crypto policies, not via direct
manipulation of the /etc/ssh/ssh_config, and I guess that's probably the
absolute best way to do so,
2024 Sep 09
1
OL8 (RHEL8), ssh-rsa turned off using update-crypto-policies, receiving an openssh error that I don't seem to be able to override in my personal .ssh/config file
well nuts. that, in fact, doesn't work. it appears that, based on an
strace, the order of reading for policies is personal .ssh/config,
/etc/ssh/ssh_config (and conf.d files), then crypto policies, with the more
restrictive policy being used.
---
Regards,
Kevin Martin
On Mon, Sep 9, 2024 at 11:07?AM kevin martin <ktmdms at gmail.com> wrote:
> Lol! Our Security team sent out
2024 Sep 09
1
OL8 (RHEL8), ssh-rsa turned off using update-crypto-policies, receiving an openssh error that I don't seem to be able to override in my personal .ssh/config file
Hi,
On Mon, Sep 09, 2024 at 05:41:42PM +0200, Jan Schermer wrote:
> The correct solution is to throw whatever requires it to the garbage and never buy from that vendor again.
As nice as this sounds, the selection of possible algorithms on the
(usually "internal network only") management interface is waaaaay low
on the priority list when shopping for a $50k router...
gert
--
2024 Sep 09
1
OL8 (RHEL8), ssh-rsa turned off using update-crypto-policies, receiving an openssh error that I don't seem to be able to override in my personal .ssh/config file
using "update-crypt-policies --set DEFAULT" allows the connectivity to work
again. setting that but then setting -ssh-rsa... in /etc/ssh/ssh_config
breaks it again. setting my personal .ssh/config file to +ssh-rsa... keeps
it still broken. so I guess my personal .ssh/config file is only used when
something isn't explicitly set in system wide crypto policies or the system
2020 Mar 02
3
Question about host key algorithms
When I do ssh -Q key, where ssh is the OpenSSH 7.4p1 client, I get the
following output:
ssh-ed25519
ssh-ed25519-cert-v01 at openssh.com
ssh-rsa
ssh-dss
ecdsa-sha2-nistp256
ecdsa-sha2-nistp384
ecdsa-sha2-nistp521
ssh-rsa-cert-v01 at openssh.com
ssh-dss-cert-v01 at openssh.com
ecdsa-sha2-nistp256-cert-v01 at openssh.com
ecdsa-sha2-nistp384-cert-v01 at openssh.com
ecdsa-sha2-nistp521-cert-v01 at
2020 Mar 02
4
Question about host key algorithms
$ ssh -Q HostKeyAlgorithms
Unsupported query "HostKeyAlgorithms"
$ ssh -V
OpenSSH_7.4p1, OpenSSL 1.0.2u 20 Dec 2019
On Mon, Mar 2, 2020 at 2:24 PM Christian Hesse <list at eworm.de> wrote:
> Luveh Keraph <1.41421 at gmail.com> on Mon, 2020/03/02 14:07:
> > When I do ssh -Q key, where ssh is the OpenSSH 7.4p1 client, I get the
> > following output:
> >
2018 May 25
5
Strange crypto choices
The defaults for HostKeyAlgorithms option are:
ecdsa-sha2-nistp256-cert-v01 at openssh.com,
ecdsa-sha2-nistp384-cert-v01 at openssh.com,
ecdsa-sha2-nistp521-cert-v01 at openssh.com,
ssh-ed25519-cert-v01 at openssh.com,
ssh-rsa-cert-v01 at openssh.com,
ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,
ssh-ed25519,ssh-rsa
Why does OpenSSH prefer older and less secure
2021 Jan 18
4
[Bug 3253] New: ssh-keygen man page still lists deprecated key types for -t
https://bugzilla.mindrot.org/show_bug.cgi?id=3253
Bug ID: 3253
Summary: ssh-keygen man page still lists deprecated key types
for -t
Product: Portable OpenSSH
Version: 8.4p1
Hardware: Other
OS: Linux
Status: NEW
Severity: minor
Priority: P5
Component: ssh-keygen
2020 Feb 06
3
Call for testing: OpenSSH 8.2
On 2020-02-05 at 20:39 -0500, Phil Pennock wrote:
> On 2020-02-06 at 10:29 +1100, Damien Miller wrote:
> > OpenSSH 8.2p1 is almost ready for release, so we would appreciate testing
> > on as many platforms and systems as possible. This is a feature release.
>
> > * The RFC8332 RSA SHA-2 signature algorithms rsa-sha2-256/512. These
> This actually affects me:
2018 Oct 11
2
no mutual signature algorithm with RSA user certs client 7.8, server 7.4
On Thu, 11 Oct 2018, Adam Eijdenberg wrote:
> On Thu, Oct 11, 2018 at 12:13 PM Damien Miller <djm at mindrot.org> wrote:
> > Could you try this?
> >
> > diff --git a/sshconnect2.c b/sshconnect2.c
> > index f104408..1d2906f 100644
> > --- a/sshconnect2.c
> > +++ b/sshconnect2.c
> > @@ -1080,7 +1080,8 @@ key_sig_algorithm(struct ssh *ssh, const
2018 Oct 10
2
no mutual signature algorithm with RSA user certs client 7.8, server 7.4
Hi,
One of our users who is running an OS (I think it's the latest beta
macOS 10.14.1) with ssh version "OpenSSH_7.8p1, LibreSSL 2.7.3" is
unable to use our user SSH RSA certificates to authenticate to our
servers (which are running "OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan
2017").
We see this error on the client side:
debug1: kex_input_ext_info:
2020 Sep 16
2
ssh-ed25519 and ecdsa-sha2-nistp256 host keys
Here you go:
OpenSSH_7.9p1, OpenSSL 1.1.1d 10 Sep 2019
debug1: Reading configuration data /home/ryantm/.ssh/config
debug1: /home/ryantm/.ssh/config line 4: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 13: Applying options for *
debug2: resolving "{REDACTED}" port 22
debug2: ssh_connect_direct
debug1: Connecting to
2024 Jul 14
1
Configuration for root logins
Hi,
I am trying to configure OpenSSH to allow root logins, without success
so far. So I could really use some advice.
This is my server configuration:
AllowUsers = thomas root
AuthenticationMethods hostbased,publickey
ExposeAuthInfo = no
ForceCommand none
GSSAPIAuthentication no
HostbasedAcceptedAlgorithms ssh-ed25519
HostbasedAuthentication yes
HostbasedUsesNameFromPacketOnly yes
HostKey
2018 Nov 23
2
Debian Stretch 9.6: openssh-server and old dropbear client don't work togheter
Il giorno gio 22 nov 2018 alle ore 21:24 Stuart Henderson
<stu at spacehopper.org> ha scritto:
>
> On 2018/11/22 19:55, owl700 at gmail.com wrote:
> > Hi, I have compatibility issues with the latest version of
> > openssh-server and an old dropbear client, the dopbear client stops at
> > preauth
> >
> > ov 22 14:34:03 myhostname sshd[3905]: debug1: Client
2020 May 03
10
[Bug 3157] New: known_hosts @cert-authority with legacy plain key entry drops incorrect set of HostKeyAlgorithms
https://bugzilla.mindrot.org/show_bug.cgi?id=3157
Bug ID: 3157
Summary: known_hosts @cert-authority with legacy plain key
entry drops incorrect set of HostKeyAlgorithms
Product: Portable OpenSSH
Version: 8.1p1
Hardware: All
OS: Mac OS X
Status: NEW
Severity: normal
Priority:
2018 Oct 11
2
no mutual signature algorithm with RSA user certs client 7.8, server 7.4
On Thu, Oct 11, 2018 at 10:41 AM Damien Miller <djm at mindrot.org> wrote:
> On Wed, 10 Oct 2018, Adam Eijdenberg wrote:
> > We see this error on the client side:
> >
> > debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
> > ...
> > debug1: Offering public key: RSA-CERT SHA256:xxx /path/to/key
> > debug1: send_pubkey_test: no
2020 Sep 16
2
ssh-ed25519 and ecdsa-sha2-nistp256 host keys
Hello.
I am running OpenSSH 7.9p1 on my client and server. ssh-keyscan shows
the server has ssh-rsa, ssh-ed25519, and ecdsa-sha2-nistp256 host
keys. My /etc/ssh/ssh_known_hosts file contains the server's
ssh-ed25519 host key. When I try to SSH to the server I get this
error:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!
2018 Nov 22
2
Debian Stretch 9.6: openssh-server and old dropbear client don't work togheter
Hi, I have compatibility issues with the latest version of
openssh-server and an old dropbear client, the dopbear client stops at
preauth
ov 22 14:34:03 myhostname sshd[3905]: debug1: Client protocol version
2.0; client software version dropbear_0.46
Nov 22 14:34:03 myhostname sshd[3905]: debug1: no match: dropbear_0.46
Nov 22 14:34:03 myhostname sshd[3905]: debug1: Local version string
2016 Sep 07
2
Question regarding Host keys.
Hi,
I'm having a problem when I add "HostKeyAlgorithms +ssh-dss" to the
ssh_config file the host key will always negotiate to a wrong one. In my
case it will negotiate to "ecdsa-sha2-nistp256". The client was already
configured with the servers rsa public key, before the change I added to
the ssh_config file I could see from the debug that server and client will
negotiate