Not to be confused with OpenSSL.

OpenSSH is a free, open source implementation of the SSH (Secure SHell) protocols.


By default the primary configuration file for the SSH daemon should be located at /etc/ssh/sshd_config.

Lines beginning with a '#' will be treated by the daemon as comments.

Configuration lines are of the form: [OptionName] This will prevent the root user from logging in remotely. In order for a user to acquire remote access to your system remotely, he or she will first have to acquire access as a non-root user who is permitted to log in remotely. A logged-in, remote, non-root user must then use a command such as [[sudo or su to promote himself or herself to the root user. This practice ensures that a remote attacker must discover not one, but two passwords in order to acquire remote root access, if at all: a user permitted to login remotely and escalate himself or herself to root, and the password of the root user to effect this promotion.

SSH to use Protocol 2 only :There are many floors in using the protocol 1 for the sshd suite, there are many automated rootkits out there, just google it for more information. Find the line #Protocol 2, 1 and change it to Protocol 2

AllowUsers [[user] ...] :This will ensure that only users you explicitly grant permission will be allowed to login remotely, and will help you keep track of which users you presently permit remote login. Multiple users may be specified, each seperated by a space.

Port [n] :By default the SSH daemon will listen on port 22. You may wish to change this to an alternative, non-standard port. Using an alternative port will make it more difficult for a potential attacker or malicious user attempt to communicate with the SSH daemon without first either monitoring traffic or executing a port scan against the target machine. If you have taken precautions on your network against traffic monitoring and port scanning, it becomes more likely that you will be alerted to the presence and intent of the potential attacker.

:Consider putting ssh on a port number higher than 1024, this will prevent typical scans (such as a standard nmap scan) picking up ssh.

ListenAddress[n] :A server may have more than one IP address attached to it, i.e. using a range such as

:If we configure SSH to ListenAddress we ensure that SSH can only be accessed by only on IP address from that range.

See also


OpenSSH (also known as OpenBSD Secure Shell

startup scripts.}}) is a suite of security-related network-level utilities based on the Secure Shell (SSH) protocol, which help to secure network communications via the encryption of network traffic over multiple authentication methods and by providing secure tunneling capabilities.<ref name=“OpenSSH Under the Hood”>


OpenSSH started as a fork of the free SSH program, developed by Tatu Ylönen; later versions of Ylönen's SSH were proprietary software, offered by SSH Communications Security.

OpenSSH was first released as part of the OpenBSD operating system in 1999.

OpenSSH is not a single computer program, but rather a suite of programs that serve as alternatives to unencrypted network communication protocols like FTP and rlogin. Active development primarily takes place within the OpenBSD source tree. OpenSSH is integrated into the base system of several other BSD projects,<ref>



</ref> while the portable version is available as a package in other Unix-like systems.<ref>





OpenSSH was created by the OpenBSD team as an alternative to the original SSH software by Tatu Ylönen, which is now proprietary software.<ref name=“alternative”>

</ref> Although source code is available for the original SSH, various restrictions are imposed on its use and distribution. OpenSSH was created as a fork of Björn Grönvall's OSSH that itself was a fork of Tatu Ylönen's original free SSH 1.2.12 release, which was the last one having a license suitable for forking.<ref>

</ref> The OpenSSH developers claim that their application is more secure than the original, due to their policy of producing clean and audited code and because it is released under the BSD license, the open source license to which the word open in the name refers.

OpenSSH first appeared in OpenBSD 2.6. The first portable release was made in October 1999.<ref>

</ref> Developments since then have included the addition of ciphers (e.g., chacha20-poly1305 in 6.5 of January 2014<ref>

</ref>), cutting the dependency on OpenSSL (6.7, October 2014<ref>

</ref>) and an extension to facilitate public key discovery and rotation for trusted hosts (for transition from DSA to Ed25519 public host keys, version 6.8 of March 2015<ref>


On 19 October 2015, Microsoft announced that OpenSSH will be natively supported on Windows and accessible through Windows PowerShell, releasing an early implementation and making the code publicly available.<ref>


Development and structure

OpenSSH is developed as part of the OpenBSD operating system. Rather than including changes for other operating systems directly into OpenSSH, a separate portability infrastructure is maintained by the OpenSSH Portability Team and “portable releases” are made periodically. This infrastructure is substantial, partly because OpenSSH is required to perform authentication, a capability that has many varying implementations. This model is also used for other OpenBSD projects such as OpenNTPD.

The OpenSSH suite includes the following command-line utilities and daemons:

  • , a replacement for



    to allow shell access to a remote machine.

  • , a replacement for

  • , a replacement for

    to copy files between computers

  • , the SSH server daemon

  • , a tool to inspect and generate the RSA, DSA and Elliptic Curve keys that are used for user and host authentication

  • and

    , utilities to ease authentication by holding keys ready and avoid the need to enter passphrases every time they are used

  • , which scans a list of hosts and collects their public keys

The OpenSSH server can authenticate users using the standard methods supported by the ssh protocol: with a password; public-key authentication, using per-user keys; host-based authentication, which is a secure version of

's host trust relationships using public keys; keyboard-interactive, a generic challenge-response mechanism that is often used for simple password authentication but which can also make use of stronger authenticators such as tokens; and Kerberos/GSSAPI. The server makes use of authentication methods native to the host operating system; this can include using the BSD Authentication system or Pluggable authentication modules (PAM) to enable additional authentication through methods such as one-time passwords. However, this occasionally has side-effects: when using PAM with OpenSSH it must be run as root, as root privileges are typically required to operate PAM. OpenSSH versions after 3.7 (16 September 2003) allow PAM to be disabled at run-time, so regular users can run sshd instances.

On OpenBSD, OpenSSH utilizes a dedicated

user by default to drop privileges and perform privilege separation in accordance to OpenBSDs least privilege policy that has been applied throughout the operating system such as for their X server (see Xenocara).


OpenSSH includes the ability to forward remote TCP ports over a secure tunnel, allowing that way arbitrary TCP ports on the server side and on the client side to be connected through an SSH tunnel.<ref>

</ref> This is used to multiplex additional TCP connections over a single SSH connection, to conceal connections and encrypting protocols that are otherwise unsecured, and to circumvent firewalls what opens up space for potential security issues. An X Window System tunnel may be created automatically when using OpenSSH to connect to a remote host, and other protocols, such as HTTP and VNC, may be forwarded easily.<ref>


In addition, some third-party software includes support for tunnelling over SSH. These include DistCC, CVS, rsync, and Fetchmail. On some operating systems, remote file systems can be mounted over SSH using tools such as sshfs (using FUSE).

An ad hoc SOCKS proxy server may be created using OpenSSH. This allows more flexible proxying than is possible with ordinary port forwarding.

Beginning with version 4.3, OpenSSH implements an OSI layer 2/3 tun-based VPN. This is the most flexible of OpenSSH's tunnelling capabilities, allowing applications to transparently access remote network resources without modifications to make use of SOCKS.<ref>



In the case of using default configuration, the attacker's success probability for recovering 14 bits of plaintext is 2−14.<ref>OpenSSH Security Advisory CBC Attack</ref> The OpenSSH&nbsp;5.2 release modified the behavior of the OpenSSH server<ref>OpenSSH 5.2 Release Notes</ref><ref> Redhat Bug 472068 - (CVE-2008-5161) CVE-2008-5161 OpenSSH: Plaintext Recovery Attack against CBC ciphers</ref> to further mitigate against this vulnerability.

Malicious or compromised OpenSSH servers can steal private login keys for other systems, using a vulnerability that relies on the undocumented connection-resuming feature of the OpenSSH client, which is called roaming, enabled by default on the client, but not supported on the OpenSSH server. This applies to versions 5.4 (released on 8 March 2010<ref>OpenSSH 5.4 released</ref>) to 7.1 of the OpenSSH client, and was fixed in OpenSSH&nbsp;7.1p2, released on 14 January 2016. CVE numbers associated to this vulnerability are CVE-2016-0777 (information leak) and CVE-2016-0778 (buffer overflow).<ref>

</ref><ref>OpenSSH 7.1p2 has just been released.</ref>


In February 2001, Tatu Ylönen, Chairman and CTO of SSH Communications Security informed the OpenSSH development mailing list, that the company intended to assert its ownership of the “SSH” and “Secure Shell” trademarks,<ref>

</ref> and sought to change references to the protocol to “SecSH” or “secsh”, in order to maintain control of the “SSH” name. He proposed that OpenSSH change its name in order to avoid a lawsuit, a suggestion that developers resisted. OpenSSH developer Damien Miller replied urged Ylönen to reconsider, arguing that “SSH” had since long been a generic trademark.<ref>


At the time, “SSH,” “Secure Shell” and “ssh” had appeared in documents proposing the protocol as an open standard and it was hypothesised

that by doing so, without marking these within the proposal as registered trademarks, Ylönen was relinquishing all exclusive rights to the name as a means of describing the protocol. Improper use of a trademark, or allowing others to use a trademark incorrectly, results in the trademark becoming a generic term, like Kleenex or Aspirin, which opens the mark to use by others.<ref>

</ref> After study of the USPTO trademark database, many online pundits opined that the term “ssh” was not trademarked, merely the logo using the lower case letters “ssh.” In addition, the six years between the company's creation and the time when it began to defend its trademark, and that only OpenSSH was receiving threats of legal repercussions, weighed against the trademark's validity.<ref>

Ylönen: We own ssh trademark, but here's a proposal|last=Ylonen|first=Tatu|date=1 March 2002|website=NewsForge|archive-url=|archive-date=1 March 2002|access-date=20 May 2016}}</ref>

Both developers of OpenSSH and Ylönen himself were members of the IETF working group developing the new standard; after several meetings this group denied Ylönen's request to rename the protocol, citing concerns that it would set a bad precedent for other trademark claims against the IETF. The participants argued that both “Secure Shell” and “SSH” were generic terms and could not be trademarks.<ref name=“itworld”>


See also



External links

openssh.txt · Last modified: 2016/10/25 16:36 by Cloud Monk Losang Jinpa PhD MCSE MCT Microsoft Cloud Ecosystem DevOps Engineer