search

pterodactyl / panel

Pterodactyl® is a free, open-source game server management panel built with PHP, React, and Go. Designed with security in mind, Pterodactyl runs all game servers in isolated Docker containers while exposing a beautiful and intuitive UI to end users.
https://pterodactyl.io
Other
6.76k stars 1.72k forks source link

Pterodactyl SFTP does not support any host key algorithms compatible with the latest OpenSSH — Add support for ed25519 or rsa-sha2-256 #3658

Closed lordofpipes closed 3 years ago

lordofpipes commented 3 years ago

Is there an existing issue for this?

Current Behavior

Just a week ago, OpenSSH published an update that causes clients to immediately disconnect when encountering a server that only supports the ssh-rsa algorithm, which represents RSA key exchange based on SHA1 hashes.

Excerpt:

Potentially-incompatible changes

This release disables RSA signatures using the SHA-1 hash algorithm by default. This change has been made as the SHA-1 hash algorithm is cryptographically broken, and it is possible to create chosen-prefix hash collisions for <USD$50K [1]

For most users, this change should be invisible and there is no need to replace ssh-rsa keys. OpenSSH has supported RFC8332 RSA/SHA-256/512 signatures since release 7.2 and existing ssh-rsa keys will automatically use the stronger algorithm where possible.

Incompatibility is more likely when connecting to older SSH implementations that have not been upgraded or have not closely tracked improvements in the SSH protocol. For these cases, it may be necessary to selectively re-enable RSA/SHA1 to allow connection and/or user authentication via the HostkeyAlgorithms and PubkeyAcceptedAlgorithms options. For example, the following stanza in ~/.ssh/config will enable RSA/SHA1 for host and user authentication for a single destination host:

   Host old-host
       HostkeyAlgorithms +ssh-rsa
       PubkeyAcceptedAlgorithms +ssh-rsa

We recommend enabling RSA/SHA1 only as a stopgap measure until legacy implementations can be upgraded or reconfigured with another key type (such as ECDSA or Ed25519).

[1] "SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1 and Application to the PGP Web of Trust" Leurent, G and Peyrin, T (2020) https://eprint.iacr.org/2020/014.pdf

As a result of Wings' use of a Go SSH library, its builtin SFTP server does not support any of these alternative algorithms. I believe that this code has its origin in the original Pterodactyl 0.7 SFTP daemon written in Javascript, as the Go code looks like it was transliterated from the original but using different libraries. I've tested and both 0.7 and 1.6.2 have this issue.

This is not a major security flaw (busting SHA1 still costs $50k worth of computing power, and busting SSH even more) but it has caused breakage and inability to connect, and Wings really should have supported the alt algorithms in the first place.

Symptoms, for googleability:

When using SSHFS

 🌌 lordpipe@winter : ~ » sshfs username@host:/ -p 2022 /mnt/
read: Connection reset by peer

When using SFTP command

🌌 lordpipe@winter : ~ » sftp -P 2022 username@host
Unable to negotiate with host port 2022: no matching host key type found. Their offer: ssh-rsa
Connection closed.
Connection closed

There is a workaround. OpenSSH can still be configured with HostKeyAlgorithms=+ssh-rsa, which can be done at the command line by appending -oHostKeyAlgorithms=+ssh-rsa to any sshfs/sftp/ssh command.

Expected Behavior

To fix this, the Wings SFTP daemon should be updated to support and manage its own ssh-ed25519 and/or rsa-sha2-256 host keys. The SHA1 algorithm has been known to be broken for many years and should be dropped.

When connecting to a default-configured OpenSSH server, the server is willing to negotiate four different host key algorithm options, and also refuses to negotiate a SHA1 RSA key. In this example, the server and the client are both OpenSSH, so they immediately settle on ssh-ed25519, which is considered secure.

🌌 lordpipe@winter : ~ » sftp -v -v username@host
OpenSSH_8.8p1, OpenSSL 1.1.1l  24 Aug 2021
[.. truncated ..]
debug1: Local version string SSH-2.0-OpenSSH_8.8
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.8
debug1: compat_banner: match: OpenSSH_8.8 pat OpenSSH* compat 0x04000000
[.. truncated ..]
debug2: host key algorithms: rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519
[.. truncated ..]
debug1: kex: host key algorithm: ssh-ed25519
[.. truncated ..]
debug1: Next authentication method: password
username@host's password:

Steps to Reproduce

To test for this problem — OpenSSH will show the algorithms supported by the host when adding two verbose flags, i.e. sftp -v -v

🌌 lordpipe@winter : ~ » sftp -v -v -P 2022 username@host
OpenSSH_8.8p1, OpenSSL 1.1.1l  24 Aug 2021
[.. truncated ..]
debug1: Local version string SSH-2.0-OpenSSH_8.8
debug1: Remote protocol version 2.0, remote software version Go
debug1: compat_banner: no match: Go
[.. truncated ..]
debug2: host key algorithms: ssh-rsa
[.. truncated ..]
debug1: kex: host key algorithm: (no match)
Unable to negotiate with host port 2022: no matching host key type found. Their offer: ssh-rsa
Connection closed
Connection closed.
 🌌 lordpipe@winter : ~ »

Panel Version

1.6.2

Wings Version

1.5.1

Error Logs

No response

parkervcp commented 3 years ago

We aren't allowing ssh but sftp via ssh auth key. The keys are only used for sftp.

I'm not saying we shouldn't update to support more modern keys. I am saying that this won't expose a host to an ssh login.

Most users won't be using the cli sftp but an sftp tool like filezilla or winscp.

lordofpipes commented 3 years ago

Most users won't be using the cli sftp but an sftp tool like filezilla or winscp.

These tools are largely based on OpenSSH source code, so this change is coming and it's coming fast. I discovered this issue because it affected sshfs, which is used by several file managers. I know that a lot of GVfs based things will both be affected by this and also not have the HostKeyAlgorithms workaround exposed in any UI.

lordofpipes commented 3 years ago

I am saying that this won't expose a host to an ssh login.

Of course, I'm not reporting a security issue. The risk of decryption and modification of Minecraft data in transit off of some crazy SHA1 attack is absurd. These are OpenBSD devs who made this deprecation decision, so they're coming from a totally different world of security threat modelling :)

But it does affect functionality, I had to rewrite some scripts after being puzzled by this issue for a few hours.

matthewpi commented 3 years ago

https://github.com/pterodactyl/wings/blob/v2/sftp/server.go

Already added other keys in v2

DaneEveritt commented 3 years ago

There is a distinct difference here between allowing a user to connect with a SSH key, and negotiation using a host key @matthewpi @parkervcp. This is an issue with the implementation of the server itself, and not how we handle user authentication.

matthewpi commented 3 years ago

There is a distinct difference here between allowing a user to connect with a SSH key, and negotiation using a host key matthewpi parkervcp. This is an issue with the implementation of the server itself, and not how we handle user authentication.

I added other types of host keys, I'm not referring to allowing clients to authenticate with SSH keys.

https://github.com/pterodactyl/wings/blob/v2/sftp/server.go#L149-L209

This was ran on the v2 version of wings. This is using SSH Keys for auth, but that shouldn't affect any of this.

sftp -P 2022 -vv <REDACTED>@<REDACTED> https://ptero.co/ibacuhezin

DaneEveritt commented 3 years ago

@matthewpi gotcha, I'm pushing an update to the 1.x branch to just generate ED25519 keys. I don't think we need to be supporting a bunch of different types, this is all handled internally anyways, so long as we generate a better key to begin with.

matthewpi commented 3 years ago

@matthewpi gotcha, I'm pushing an update to the 1.x branch to just generate ED25519 keys. I don't think we need to be supporting a bunch of different types, this is all handled internally anyways, so long as we generate a better key to begin with.

I only added ecdsa and ed25519. If you want to only add ed25519, that's fine but it is easy to backport the changes from v2. It's only in the sftp/server.go file. Just loadPrivateKeys, generate*, https://github.com/pterodactyl/wings/blob/v2/sftp/server.go#L57-L60, and https://github.com/pterodactyl/wings/blob/v2/sftp/server.go#L69-L71

DaneEveritt commented 3 years ago

@matthewpi I removed generation of RSA keys, basically just keeping the existing logic but switching to ssh-ed25519 rather than ssh-rsa. Was there a specific reason you had to supporting multiple?

matthewpi commented 3 years ago

@matthewpi I removed generation of RSA keys, basically just keeping the existing logic but switching to ssh-ed25519 rather than ssh-rsa. Was there a specific reason you had to supporting multiple?

That's what OpenSSH usually does, the client will pick whatever one it prefers or supports. I believe the only reason to keep rsa would be compatibility but I'm not aware of any clients that wouldn't support ed25519. If you want to just use ed25519 in v1 for now go for it and I'll worry about getting rsa-sha256 and other keys for v2 when I get a chance.

DaneEveritt commented 3 years ago

This will be fixed in the next Wings release. No additional work is required to get this change running, it'll automatically generate a new host key since it will see there is not currently one present.

~/Sites/development/code master ❯ sftp -P 2022 -vv test@wings.pterodactyl.test                             15s 11:30:38
OpenSSH_8.1p1, LibreSSL 2.7.3
[...]
debug1: Connecting to wings.pterodactyl.test port 2022.
debug1: Connection established.
[...]
debug1: Authenticating to wings.pterodactyl.test:2022 as 'test'
[...]
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group14-sha1
debug2: host key algorithms: ssh-ed25519
debug2: ciphers ctos: aes128-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr
debug2: ciphers stoc: aes128-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr
[...]
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ssh-ed25519 SHA256:T8w759i1BQy4YbFjMrYXpHtkx63wTu9VxdZumGUuy2w
debug1: checking without port identifier
The authenticity of host '[wings.pterodactyl.test]:2022 ([192.168.50.3]:2022)' can't be established.
ED25519 key fingerprint is SHA256:T8w759i1BQy4YbFjMrYXpHtkx63wTu9VxdZumGUuy2w.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '[wings.pterodactyl.test]:2022' (ED25519) to the list of known hosts.