SSH server is always verified, see "SSH host keys".
SSH is often used with corporate certificates, this way there is no need to verify each server's key's fingerprint on first connection (or to just trust on first use) because the server's host key is signed by corporate CA. The same CA signs your client key and server trusts your key without adding it explicitly to ~/.ssh/authorized_keys.
SSH key exchange is FFDHE, ECDHE over P-256 and X25519 (ECDHE over Curve25519, this is the recommended method).
SSH host key can be DSA-1024 (deprecated), RSA with PKCS#1v1.5 with SHA1 (deprecated), RSA with PKCS#1v1.5 with SHA2 (most supported secure method), RSA PSS with SHA2 (I don't know how much support this has), ECDSA with P-256, Ed25519 (this is the recommended method).
SSH symmetric cipher can be 3DES, AES-CBC, AES-CTR, AES-GCM, CHACHA20-POLY1305.
SSH symmetric MAC can be AEAD (GCM, Poly1305) or HMAC or UMAC.
If you compare this to TLS, especially the modern options, you'll see they are the same. ECDHE over P-256 and Curve25519 is the same and the recommended key exchange in both. AES-GCM and ChaPoly are the recommended AEAD in both.
TLS is mostly stuck with RSA "host keys", with Ed25519 "Host keys" unlikely to become popular any time soon (they have to wait for HSMs with support for those keys to come out, and this won't happen before post quantum standardization, so they are basically waiting for that).
TLSv1.3 upgraded RSA from PKCS#1v1.5 to PSS while SSH mostly didn't, because they upgraded to Ed25519. Both upgraded legacy PKCS#1v1.5 from SHA1 to SHA2, but at different times.
The algorithms are basically the same, but the ecosystems are different, and this leads to the upgrades being deployed at different rates.
We can add IKEv2 for IPSec to the comparison, and we will see that in the space too, the exact same conclusion holds.