Is SSH secure against MiTM if server fingerprint is not checked, public key authentication is used and confidentiality is not needed for that service?
In short: it is not a design flaw. You've just had a misunderstanding of the design.
The authentication protocol is that the client signs the challenge provided by the server, the server verifies it and then allows access.
The client does not sign a challenge provided by the server. Instead the client signs a structure defined in RFC 4252 section 7 which includes as a major component the session identifier. This session identifier itself is a result of the key exchange as described in RFC 4253 section 7.2.
... a malicious server can impersonate a user to a legitimate server by doing MiTM and proxying user's responses to the original server.
Since the MITM does not have access to the clients private key it cannot create a new signature with this key. Thus it needs to find a way to make the server accept the original signature by the client. And since the signature depends on the session identifier the MITM would need to establish a SSH connection between client and MITM and another between MITM and server which both have the same session identifier.
But in the Diffie Hellman key exchange the result of the key exchange depends both on client data unknown to the server and server data unknown to the client. Since the MITM has only control over one side of each connection it cannot control the result of the key exchange and thus cannot control the session identifier.
Therefore the attack you describe will not work. The MITM cannot simply impersonate the client as long as the server properly authenticates the client. Either the authentication will fail because the signature is broken (does not match the session identifier) or it will fail because the public key is not the one expected by the server (in case MITM made up its own client key).
Is it a design flaw in SSH that a user is required to check fingerprint manually?
It has pros and cons (surprise!).
Websites use a 'trusted' third party for HTTPS. We all trust the Staat Der Nederlanden, Chunghwa, Atos, and the China Financial Certification Authority to verify your connection between you and your bank, right? Because that's exactly what they're doing, and this has been known to go wrong in the past. But it's the best we got: we can't expect our moms to ring up the bank to ask their fingerprint, so we need to use these semi-trusted certificate authorities.
For SSH, it is mainly used by system administrators or other power users, so it is more reasonable to expect that they check the fingerprint, or at least understand what it is. A security-aware admin can check it, if they wish to do so (for example, I work for an IT security consultancy and we check the fingerprints before connecting). Otherwise, at least it's trust on first use as Sjoerd already mentioned, so it can't just change without you noticing. An attack would have to be present from the start, and has to go on indefinitely, for it to go unnoticed.
It feels like a design flaw: a malicious server can impersonate a user to a legitimate server by doing MiTM and proxying user's responses to the original server.
Same with any other scheme, right? You can always MitM and proxy the traffic. In ssh's case you get a wrong fingerprint the first time or a fat alert upon any subsequent connections, and in https' case you get a certificate warning.
The way to fix that would be to sign not only challenge, but also server's fingerprint. Then the server can detect MiTM server-side.
Think this through:
A: Hello there, SSH server of bob.example.com!
B: Greetings, stranger. Here is my public key: abcdef
M: intercepts the message and changes abcdef to 123456
A: Hi server bob with public key 123456, I'm Alice with password bz8iuqw45.
M: intercepts the message and changes 123456 to abcdef
B: Hi Alice! You logged in successfully!
An attacker will use their own public key, so they can decrypt the traffic. When forwarding the data, they can replace the fingerprint. You would have to do mutual authentication, where the client supplies a public key that is already trusted by the server. Only then does the server know for sure that the client is using the right key and is not being man-in-the-middled. But now you reversed the problem: now the server has to know the right fingerprint (of the user's public key) instead of the user of the server. The issue, key distribution, remains.
Let's assume that the client is unwiling to check the fingerprint because in order to do it it should get the true fingerprint somehow.
Do you mean it's impossible to get the fingerprint, without trusting the fingerprint when connecting? Because you could grab the real fingerprint when installing the server, before connecting via ssh.
I feel like some clients don't check fingerprints at all
That would be a vulnerability in the client. If you want to check fingerprints but your client does not support that, then you can't use those clients. It's a little easy to say "the authors of the ssh protocol did it all wrong, this is causing clients to ignore security", because as I said, there are pros and cons to this default scheme. If you want to change it, SSH supports certificate authorities as paj28 mentioned.