Who Decides the SSH Cipher? Why the Client's Preference Matters

A common misconception is that the SSH server unilaterally chooses the encryption algorithm for a connection. In reality, the negotiation follows a strict rule: the server picks the first algorithm from the client's list that it also supports. This means the client's preference order directly determines the final cipher — and putting the best algorithm first can significantly improve performance in your gbase database environment.

What the Standards Say

The OpenSSH documentation states:

The first algorithm in the list (that the client offers to the server) that matches an offer from the server, is what will be selected.

RFC 4253, the SSH Transport Layer Protocol, is even more explicit:

The first algorithm on the client's name-list that satisfies the requirements and is also supported by the server MUST be chosen.

How It Plays Out

Imagine a client sends this cipher list (in order of preference): A, B, C, D, E
The server supports these ciphers: B, C, D, E, A

Both sides support A and B. According to the rule, the first match in the client's list is A — so A becomes the session cipher. The server's own preferred order (B first) is irrelevant; the decision is client‑driven.

Practical Impact for GBase 8a

In a GBase 8a cluster, SSH underpins remote management and SFTP data loading. If you want to prioritise a modern, fast cipher like [e-mail] or aes128-ctr over slower legacy ones, adjust the Ciphers directive in your client's ~/.ssh/config or /etc/ssh/ssh_config and place the preferred algorithm first. This simple ordering can measurably improve throughput for large data transfers.

Host *
    Ciphers [e-mail],aes128-ctr,aes192-ctr,aes256-ctr

By controlling the cipher preference on the client side, you keep your gbase database operations both secure and fast — no server‑side changes required.