dcache
dcache copied to clipboard
dCache
current OpenSSH can no longer connect to dCache's ssh
Hey.
OpenSSH since 8.8p1 no longer (per default) connects to RSA/SHA1 signed keys (unless PubkeyAcceptedAlgorithms +ssh-rsa).
dCache's ssh server seems to use that.
Regenerating the server and user ssh keys doesn't help - it's apparently the server code that needs to be updated (tested with 9.1.2).
Cheers, Chris.
btw: When dcache cannot read the server SSH private key (and presumably the same for the public), it prints a stack trace, instead of a nice error message ;-)
Hi Chris,
I have just tried
ssh-keygen -N '' -t ecdsa -f ssh_host_ecdsa
and dCache looks happy about it:
$ ssh -v -p 22224 -l admin dcache-lab007
OpenSSH_9.0p1, OpenSSL 3.0.9 30 May 2023
debug1: Reading configuration data /home/tigran/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/50-redhat.conf
debug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config
debug1: configuration requests final Match pass
debug1: re-parsing configuration
debug1: Reading configuration data /home/tigran/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/50-redhat.conf
debug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config
debug1: Connecting to dcache-lab007 [131.169.191.144] port 22224.
debug1: Connection established.
debug1: identity file /home/tigran/.ssh/id_rsa type 0
debug1: identity file /home/tigran/.ssh/id_rsa-cert type -1
debug1: identity file /home/tigran/.ssh/id_ecdsa type -1
debug1: identity file /home/tigran/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/tigran/.ssh/id_ecdsa_sk type 10
debug1: identity file /home/tigran/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/tigran/.ssh/id_ed25519 type -1
debug1: identity file /home/tigran/.ssh/id_ed25519-cert type -1
debug1: identity file /home/tigran/.ssh/id_ed25519_sk type -1
debug1: identity file /home/tigran/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/tigran/.ssh/id_xmss type -1
debug1: identity file /home/tigran/.ssh/id_xmss-cert type -1
debug1: identity file /home/tigran/.ssh/id_dsa type -1
debug1: identity file /home/tigran/.ssh/id_dsa-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_9.0
debug1: Remote protocol version 2.0, remote software version APACHE-SSHD-2.7.0
debug1: compat_banner: no match: APACHE-SSHD-2.7.0
debug1: Authenticating to dcache-lab007:22224 as 'admin'
debug1: load_hostkeys: fopen /home/tigran/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: ecdh-sha2-nistp256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: ecdh-sha2-nistp256 need=32 dh_need=32
debug1: kex: ecdh-sha2-nistp256 need=32 dh_need=32
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: SSH2_MSG_KEX_ECDH_REPLY received
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:cID0/VG8InAUHfTJ+rWCaGfX1FVSbVeKqGJWY0I8PNw
debug1: load_hostkeys: fopen /home/tigran/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: Host '[dcache-lab007]:22224' is known and matches the ECDSA host key.
debug1: Found key in /home/tigran/.ssh/known_hosts:884
debug1: rekey out after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 4294967296 blocks
debug1: Will attempt key: /home/tigran/.ssh/id_rsa RSA SHA256:al9RPdXETJBEfFQsVqsIWXSFCofUCxkzVjlkfXexBQ8
debug1: Will attempt key: /home/tigran/.ssh/id_ecdsa
debug1: Will attempt key: /home/tigran/.ssh/id_ecdsa_sk ECDSA-SK SHA256:du0xYHLXRVjJSZZ6ew8FS4FF+TjuSmpMh7E50ADQUUY authenticator
debug1: Will attempt key: /home/tigran/.ssh/id_ed25519
debug1: Will attempt key: /home/tigran/.ssh/id_ed25519_sk
debug1: Will attempt key: /home/tigran/.ssh/id_xmss
debug1: Will attempt key: /home/tigran/.ssh/id_dsa
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: password,keyboard-interactive,publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /home/tigran/.ssh/id_rsa RSA SHA256:al9RPdXETJBEfFQsVqsIWXSFCofUCxkzVjlkfXexBQ8
debug1: send_pubkey_test: no mutual signature algorithm
debug1: Trying private key: /home/tigran/.ssh/id_ecdsa
debug1: Offering public key: /home/tigran/.ssh/id_ecdsa_sk ECDSA-SK SHA256:du0xYHLXRVjJSZZ6ew8FS4FF+TjuSmpMh7E50ADQUUY authenticator
debug1: Server accepts key: /home/tigran/.ssh/id_ecdsa_sk ECDSA-SK SHA256:du0xYHLXRVjJSZZ6ew8FS4FF+TjuSmpMh7E50ADQUUY authenticator
Confirm user presence for key ECDSA-SK SHA256:du0xYHLXRVjJSZZ6ew8FS4FF+TjuSmpMh7E50ADQUUY
debug1: start_helper: starting /usr/libexec/openssh/ssh-sk-helper
debug1: process_sign: ready to sign with key ECDSA-SK, provider internal: msg len 247, compat 0x0
debug1: sshsk_sign: provider "internal", key ECDSA-SK, flags 0x01
debug1: sk_probe: 1 device(s) detected
debug1: sk_probe: selecting sk by cred
debug1: check_sk_options: device is not fido2
debug1: sk_try: fido_dev_get_assert: FIDO_ERR_USER_PRESENCE_REQUIRED
debug1: sk_select_by_cred: found key in /dev/hidraw1
debug1: main: reply len 128
User presence confirmed
Authenticated to dcache-lab007 ([131.169.191.144]:22224) using "publickey".
debug1: pkcs11_del_provider: called, provider_id = (null)
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: pledge: filesystem
dCache (9.2.0-SNAPSHOT)
Type "\?" for help.
Which key type have you tried?
The key type shouldn't matter there, as the change is about the signature algorithm,... but anyway it's RSA keys for both, server and client sides.
Maybe your built of ssh has changed upstream defaults? Or your ssh_config has?
If you do something like:
ssh -G admin@localhost | grep -i ^PubkeyAcceptedAlgorithms
you should see the actually used algo preference string, if that contains ssh-rsa at some point it will work, but not for any OpenSSH built with upstream defaults.
Cheers, Chris.
See also https://www.openssh.com/txt/release-8.8, and there the “Potentially-incompatible changes” section.
$ ssh -G ***@***.*** | grep -i ^PubkeyAcceptedAlgorithms
pubkeyacceptedalgorithms ecdsa-sha2-nistp256,
***@***.******@***.***,
***@***.***,ecdsa-sha2-nistp384,
***@***.***,ecdsa-sha2-nistp521,
***@***.***,ssh-ed25519,
***@***.******@***.***,
***@***.***,rsa-sha2-256,
***@***.***,rsa-sha2-512,
***@***.***
-kofemann /** caffeinated mutations of the core personality */
On Tue, Aug 22, 2023 at 5:39 PM Christoph Anton Mitterer < @.***> wrote:
See also https://www.openssh.com/txt/release-8.8, and there the “Potentially-incompatible changes” section.
— Reply to this email directly, view it on GitHub https://github.com/dCache/dcache/issues/7273#issuecomment-1688454990, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEMTXMIK6E6GMUOXTNARQLXWTHBPANCNFSM6AAAAAA3CBUXFI . You are receiving this because you commented.Message ID: @.***>
That output looks unusual... mine looks like.
# ssh -p 59999 -G admin@localhost | grep -i ^PubkeyAcceptedAlgorithms
pubkeyacceptedalgorithms ssh-ed25519,[email protected],ecdsa-sha2-nistp521,[email protected],ecdsa-sha2-nistp384,[email protected],ecdsa-sha2-nistp256,[email protected],rsa-sha2-512,[email protected],rsa-sha2-256,[email protected],[email protected],[email protected],[email protected],[email protected]
Anyway... meanwhile I tried with an ed25519 server key... there the admin domain fails to start with some error. With ecdsa it starts, but same as with rsa key, I need to specify -o PubkeyAcceptedAlgorithms=+ssh-rsa or the connection fails.
It does however work, if I also replace the client key with an ecdsa one.
So I guess you need to try with all RSA keys and will then see the failure.
Hi,
the problem has a several causes "working" together to make it hard (at least on AlmaLinux9 and likes):
The rsa keys are considered obsolete so you need to allow them explicitly:
on cli:
ssh -p 22224 -l admin localhost -o PubkeyAcceptedKeyTypes=+ssh-rsa -o HostKeyAlgorithms=+ssh-rsa
or in config (~/.ssh/config):
Host localhost
HostName localhost
PubkeyAcceptedKeyTypes +ssh-rsa
HostKeyAlgorithms +ssh-rsa
Next you need to explicitly allow usage of SHA1 in libcyrpto
/usr/bin/update-crypto-policies --set DEFAULT:SHA1
And then you are good to go.
But all this point to need to update dcache supported keys to something more modern like ecdsa-* or better ssh-ed25519
Cheers
S
