How to Check SSH Protocol Version: SSH1 vs SSH2 in OpenSSH

OpenSSH_7.4p1 names the OpenSSH software release. SSH-2.0 tells you which SSH protocol is being used for the network connection. The p1 suffix identifies a portable OpenSSH release — it has nothing to do with SSH protocol 1.

This guide shows how to read both numbers, confirm whether a live connection uses SSH protocol 2, and avoid the common mistakes that come from grepping sshd_config for a Protocol line that modern OpenSSH no longer needs.

Quick answer: check whether SSH is using version 1 or 2

For a remote server, run:

ssh -vv user@server 2>&1 | grep 'Remote protocol version'

On a modern OpenSSH server, you should see a line like:

debug1: Remote protocol version 2.0, remote software version OpenSSH_9.9

Remote protocol version 2.0 confirms that the server is speaking SSH protocol 2.

Do not use ssh -V for this check. ssh -V reports the OpenSSH software version installed on your local machine, not the protocol used by the remote connection.

OpenSSH version vs SSH protocol version

These are two different version numbers on the wire and in package names.

A typical server identification string combines both parts:

SSH-2.0-OpenSSH_7.4p1
│          │
│          └── OpenSSH software version
│
└── SSH protocol version

The token after OpenSSH_ identifies the SSH implementation and its release. The SSH-2.0 prefix tells you which SSH protocol the peer is using during the initial connection setup (the SSH handshake).

What does OpenSSH_7.4p1 mean?

Break the string into three pieces:

OpenSSH_7.4p1
│       │  │
│       │  └── portable release suffix (p1)
│       └───── OpenSSH release version (7.4)
└──────────── implementation name (OpenSSH)

• OpenSSH is the SSH implementation
• 7.4 is the upstream OpenSSH release number
• p1 identifies the portable OpenSSH release. Portable releases are the OpenSSH builds intended for operating systems other than OpenBSD, including Linux. It has nothing to do with SSH protocol version 1

None of those fields identify SSH protocol 1. Other common examples follow the same pattern:

OpenSSH_8.7p1
OpenSSH_9.6p1
OpenSSH_9.9p1

The output may also show the OpenSSL version used by the OpenSSH build. Distribution-specific package revisions are separate. For example, in openssh-server-9.9p1-27.el10_2.x86_64, 27.el10_2 identifies the RHEL package release — not the SSH protocol.

How to check the installed OpenSSH version

The local client reports its build with -V (capital V):

ssh -V

Sample output:

OpenSSH_9.9p1, OpenSSL 3.5.5 27 Jan 2026

That line is the OpenSSH client version on the machine where you ran the command. The part after the comma is the OpenSSL version this build uses — not a distribution package suffix. It does not, by itself, prove which SSH protocol a remote server will use.

On RHEL-family systems you can also query the server package:

rpm -q openssh-server

Sample output:

openssh-server-9.9p1-27.el10_2.x86_64

The RPM package version confirms which OpenSSH server build is installed. To determine the SSH protocol used by a connection, check the SSH banner or ssh -vv output instead.

On Debian or Ubuntu, dpkg -l openssh-server lists the installed server package in the version column.

The server binary prints its own version string:

sshd -V

Sample output:

OpenSSH_9.9p1, OpenSSL 3.5.5 27 Jan 2026

Again, that names the software — not the SSH1 vs SSH2 choice for an active session.

How to check whether SSH is using protocol 1 or 2

Verbose client output shows the protocol exchange during the initial connection setup (the SSH handshake). Run ssh with two -v flags:

ssh -vv localhost true

Even when authentication later fails, the protocol lines appear early in the trace. Filter for them:

ssh -vv localhost true 2>&1 | grep -E 'Local version string|Remote protocol version'

Sample output:

debug1: Local version string SSH-2.0-OpenSSH_9.9
debug1: Remote protocol version 2.0, remote software version OpenSSH_9.9

Read each field:

• Local version string SSH-2.0-... — your client advertises SSH protocol 2
• Remote protocol version 2.0 — the remote server identifies itself as an SSH protocol 2 server. Because modern OpenSSH supports only SSH2, this is the protocol used for the connection
• remote software version OpenSSH_9.9 — the server's OpenSSH build string, not the protocol number

When you see Remote protocol version 2.0, the connection is using SSH protocol 2.

OpenSSH also exposes supported protocol versions through -Q:

ssh -Q protocol-version

Sample output:

2

On current releases the answer is 2 only — there is no SSH protocol 1 to select.

Does ssh -V tell you whether SSH1 or SSH2 is being used?

No. ssh -V reports the OpenSSH software version installed on the local machine. It does not tell you what protocol a remote connection uses.

To check a server, run:

ssh -vv user@server

and look for Remote protocol version 2.0.

How to read an SSH identification string

Before authentication, each side sends a one-line identification string. A common server banner looks like:

SSH-2.0-OpenSSH_7.4

Break it down:

SSH-2.0-OpenSSH_7.4
│       │
│       └── implementation and software version
└────────── SSH protocol version

• SSH-2.0 means SSH protocol 2
• OpenSSH_7.4 identifies the server software family and release

This banner is not the same as a login or legal notice configured with the Banner directive in sshd_config. The identification string is sent during the SSH handshake; a Banner file is shown later, after SSH has established the connection.

How to check the SSH protocol without logging in

The identification string is sent before user authentication, so you can often read it with a plain TCP client.

Using netcat

Connect to port 22 and read the first line the server sends:

nc -w 2 localhost 22

Sample output:

SSH-2.0-OpenSSH_9.9

nc only opens the TCP connection and reads the banner; it does not continue with the SSH handshake. The server closed the connection after sending the identification string — you already saw the SSH-2.0 prefix.

Using ssh-keyscan

ssh-keyscan connects to the SSH server and retrieves its public host keys without requiring login. Its output can also show the server's SSH identification string:

ssh-keyscan -T 3 localhost

Sample output:

# localhost:22 SSH-2.0-OpenSSH_9.9
localhost ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBDQHLcJTNC7dCKmEZSAy19w5V9U9o9dVWXbPyuf3KJNdAjcc+i4NEmzL29mINPWjXqusZhQoVbD8R/lnZH42Lxg=

The # localhost:22 SSH-2.0-OpenSSH_9.9 comment confirms SSH protocol 2 and the server software line.

Using telnet (optional)

telnet host 22 shows the same first line on many networks. On minimal server images telnet may not be installed; nc or ssh-keyscan is usually simpler for a quick banner read.

How SSH1 and SSH2 were configured on older systems

Historically, sshd_config could include a Protocol directive:

Protocol 2

or:

Protocol 1,2

Meaning:

• Protocol 2 — SSH protocol 2 only
• Protocol 1 — SSH protocol 1 only
• Protocol 1,2 — offer both (legacy)

That knob mattered when SSH protocol 1 was still a realistic client option. Do not add Protocol lines to modern OpenSSH — current releases speak SSH protocol 2 only.

Why is Protocol 2 missing from sshd_config on modern systems?

Current OpenSSH supports SSH protocol 2 only, so modern OpenSSH no longer recognizes or needs the Protocol setting.

On this RHEL 10.2 host, a direct check shows no active directive:

grep -i '^Protocol' /etc/ssh/sshd_config

On this host the command returns no lines, which is expected when the directive is absent.

Missing Protocol 2 does not mean SSH1 is enabled. It usually means the server cannot fall back to protocol 1 at all, so the setting would be redundant.

Was SSH1 still supported in OpenSSH 7.4?

OpenSSH 7.4 removed SSH protocol 1 support from sshd, the OpenSSH server. Some SSH1 client code still remained, but it was disabled at compile time by default. OpenSSH 7.6 removed the remaining SSH1 client support completely.

Practical takeaway for interviews and audits:

• A host running OpenSSH 7.4 or newer as sshd cannot offer an SSH1 server session
• Enterprise Linux releases that ship OpenSSH 7.4 and later follow the same server behavior

This page focuses on reading version strings, not the full history of SSH1 cryptography.

SSH1 vs SSH2: what is the practical difference?

On systems you manage today, the practical question is usually how to confirm SSH2 — not which protocol to enable.

Common mistakes when checking the SSH protocol version

Mistake 1: Assuming OpenSSH_7.4p1 means SSH1

The p1 suffix identifies a portable OpenSSH release. It does not mean SSH protocol 1. Only the SSH-1.x or SSH-2.0 prefix in an identification string names the protocol in use.

Mistake 2: Using only ssh -V

ssh -V answers which OpenSSH package is installed locally. To see what protocol a particular remote server uses, run ssh -vv or read the banner with nc or ssh-keyscan.

Mistake 3: Looking only for Protocol 2 in sshd_config

Modern sshd_config files often omit Protocol because SSH2 is the only supported mode. Absence of the directive is not uncertainty — it is the current default.

Mistake 4: Confusing the SSH identification string with the login banner

Identification string (protocol handshake):

SSH-2.0-OpenSSH_9.9

Configured login banner (example only):

Authorized access only

The first appears immediately on TCP port 22. The second is optional text from sshd after SSH has established the connection.

Quick reference

Summary

OpenSSH_7.4p1 identifies an OpenSSH software release. It does not mean the host is using SSH protocol 1.

To see the protocol for a real connection, run ssh -vv against the server and read Remote protocol version 2.0. You can also inspect the identification banner with nc server 22 or the comment line from ssh-keyscan — both expose SSH-2.0 before authentication.

Modern OpenSSH uses SSH protocol 2 exclusively. Older directives such as Protocol 1,2 belong to legacy configurations, and a missing Protocol line in sshd_config is normal on current releases.

References

• OpenSSH Release Notes 7.4 — removal of SSH protocol 1 server support
• OpenSSH Release Notes 7.6 — removal of remaining SSH protocol 1 client support
• sshd_config(5) — current server configuration keywords
• ssh(1) — client options including -V, -v, and -Q