OpenSSH

From openSUSE

Contents 1 History 2 Trademark 3 Portability 4 Programs included 5 Configuration 5.1 Configure SSH for SSH2-only Access 5.2 Limit by users 5.3 Limit by hosts 5.4 SFTP chroot with ChrootDirectory 6 Secure tunnels 6.1 Port forwarding 6.2 SOCKS 6.3 tun-based VPN 6.4 Authentication 7 See also 8 External links	OpenSSH Developer: The OpenBSD Project Package Info (pin) openSUSE 11.2 openSUSE 11.1 openSUSE 11.0 License: BSD License Website: http://www.openssh.com

OpenSSH (Open Secure Shell) is a set of computer programs providing encrypted communication sessions over a computer network using the Secure Shell protocol. It was created as an open alternative to the proprietary Secure Shell software. The project is led by Theo de Raadt.

History

OpenSSH was created by the OpenBSD team as an alternative to SSH, which is now proprietary software. The OpenSSH developers claim that it is more secure than the original, due to their policy of producing clean and audited code and the fact, to which the word open in the name refers, that it is released under the open source BSD license. Although source code is available for the original SSH, various restrictions are imposed on its use and distribution, making OpenSSH a more attractive project for many software developers.

OpenSSH first appeared in OpenBSD 2.6. OpenSSH 4.3 was released on February 1, 2006 [1].

Trademark

In February of 2001, Tatu Ylönen, Chairman and CTO of SSH Communications Security informed the OpenSSH development mailing list, openssh-unix-dev@mindrot.org, that after speaking with key OpenSSH developers Markus Friedl, Theo de Raadt, and Niels Provos, the company would have to assert its ownership of the SSH and Secure Shell trademarks in order to protect them. Tatu also sought to change references to the protocol to SecSH or secsh, in order to maintain control of the name, he proposed having OpenSSH change it's name in order to avoid a lawsuit. Theo de Raadt refused outright to consider changing the project's name.

At the time, "SSH", "Secure Shell" and "ssh" were used in the documents proposing the protocol as an open standard and it was hypothesized by many that by doing so, without marking these within the proposal as registered trademarks, Tatu was relinquishing all exclusive rights to the name as a means of describing the protocol. This is because in the United States it is imperative that trademarks be used in advertising copy as adjectives, never as nouns or verbs. Improper use of a trademark, or allowing others to use a trademark incorrectly, results in the trademark becoming generic a generic term, like Kleenex or Aspirin, which opens the mark to use by others, via the public domain.

Also brought into question was if the name "ssh" was trademarked, or merely the logo using the lower case letters "ssh", many on-line pundits believed the latter, after study of the USPTO trademark database and also bringing doubt to the validity of the claim was the 6 years between the company's creation and the point in time when it began defending its trademark from free alternatives such as OpenSSH, and that only OpenSSH was receiving these threats of legal repercussions.

Both developers of OpenSSH and Ylönen himself were members of the IETF work-group developing the new standard, which after several meetings, denied Ylonen's request for a renaming of the protocol, citing concerns that it would set a bad precedent for other trademark claims against the IETF. The working group participants argued that both Secure Shell SSH were generic terms and that they could not be trademarks.

Portability

Partly because OpenSSH is required to perform authentication, a capability that has many varying implementations between different operating systems, it requires a substantial portability infrastructure. Rather than including this directly into OpenBSD and OpenSSH, it is developed separately as an addition under the auspices of the OpenSSH Portability Team and released as what are known as "portable releases". This model is also used for other OpenBSD projects such as OpenNTPD.

Programs included

The OpenSSH suite includes the following tools:

• ssh, a replacement for rlogin and telnet:

ssh (Secure Shell) is a program for logging into and executing commands on a remote machine. It is intended to replace rlogin, rsh, and telnet. SSH provides secure encrypted communication between two untrusted hosts over an insecure network.

$ ssh user@example.com

• scp, a replacement for rcp:

$ scp user@example.com:~/somefile .

• sftp, a replacement for ftp:

$ sftp user@example.com

• sshd, the SSH daemon:

# sshd

Configuration

The whole configuration of the openSSH client is done by editing the file /etc/ssh/sshd_config. With openSUSE, optional parameters can be added to the ssh-daemon by the file /etc/sysconfig/ssh (see man 8 ssh for details).

You need to reload the configuration each time you change something in the files listed above. Do this by calling

 # rcsshd reload

as user root. YaST does this automatically, if you change the settings via YaST.

Configure SSH for SSH2-only Access

Version: 10.2 or below

Modify the /etc/ssh/sshd_config file to change the PROTOCOL line from: PROTOCOL 1,2 to: PROTOCOL 2

Limit by users

SSH allows to limit the login only for special users or groups. Wherever possible, use groups to enable/disable access. This way, it's much simpler to edit the access rights afterwards.

The allow/deny directives are processed in the following order,

• DenyUsers
• AllowUsers
• DenyGroups, and
• AllowGroups.

As it's very easy to add or remove a user from or to a group, we explain just the Allow/DenyGroups options.

The following options exist:

• AllowGroups

This keyword can be followed by a list of group name patterns, separated by spaces. If specified, login is allowed only for users whose primary group or supplementary group list matches one of the patterns. Only group names are valid; a numerical group ID is not recognized. By default, login is allowed for all groups.

• DenyGroups

This keyword can be followed by a list of group name patterns, separated by spaces. Login is disallowed for users whose primary group or supplementary group list matches one of the patterns. Only group names are valid; a numerical group ID is not recognized.

Here's a simple example how to proceed:

1. Start YaST
2. Go to "Security & Users" -> "Edit and create groups"
3. Add a new group named "sshlogin" (if it doesn't exist already)
4. Make all normal users (except root), whom you allow to use ssh to access the system member of this group.

Afterwards add the line:

AllowGroups sshlogin

to /etc/ssh/sshd_config and reload the configuration.

Limit by hosts

In /etc/hosts.allow you enter the following lines for the hosts you specifically allow, e.g.:

sshd : 127.0.0.1   : allow
sshd : 192.168.    : allow
sshd : 130.57.5.70 : allow
sshd : 10.         : allow

Next enter all that need to be denied in /etc/hosts.deny,

sshd : ALL         : deny

SFTP chroot with ChrootDirectory

Since OpenSSH 4.8p1 (and therefore available for each openSUSE distribution), it's possible to easily restrict users to their home directory, if they should just be able to transfer files via sftp.

This makes it easy to replace a basic FTP service without the hassle of configuring encryption and/or bothering with FTP passive and active modes when operating through a NAT router. This is also simpler than packages such as rsh, scp only or other patches because it does not require setting up and maintaining (i.e. security updates) a chroot environment.

To enable it, you need to add/edit some lines in /etc/ssh/sshd_config:

1) Configure OpenSSH to use its internal SFTP subsystem and not the real sftp-server:

# override default of no subsystems
#Subsystem  sftp    /usr/lib64/ssh/sftp-server
Subsystem   sftp    internal-sftp

2) Now configure a "match rule" to restrict the sftp access only to users in your "sftponly" group (see Limt SSH-Access by users for details):

Match group sftponly
   ChrootDirectory /home/%u 
   X11Forwarding no
   AllowTcpForwarding no
   ForceCommand internal-sftp

%h is replaced by the home directory of the user being authenticated. You can also use %u as replacement for the user name of that user.

3) Prepare the chroot directory and user settings. After the call to chroot(), sshd changes directory to the home directory relative to the new root directory. That's why you should use / as home directory for those users.

Here's a simple example which prepares the physical home directory of a user, adapts his home directory settings in /etc/passwd and adds him to the sftponly group (which must exist).

Please replace the "username" in the first line with the name of the user you want to restrict.

$ export USERNAME="username";
$ usermod -d / $USERNAME; 
$ adduser $USERNAME sftponly;

Secure tunnels

Port forwarding

Most programs making use of TCP connections can be passed over a secure tunnel using OpenSSH. This is used to multiplex additional TCP connections over a single ssh connection. It is useful for concealing connections and encrypting protocols which are otherwise unsecured, and for circumventing firewalls. UDP connections may sometimes be tunneled with the aid of programs such as netcat. Examples of easily tunneled programs include the X Window System, HTTP using a proxy and VNC. An X Window System tunnel is often created automatically between two Unix computers, so GUI programs from remote computers can be run simply by typing their names:

 $ ssh -Y user@example.com
 password:
 $ xclock

In addition, some software can be set to automatically make use of OpenSSH to create a tunnel. Examples include DistCC, CVS, rsync, and fetchmail. Programs where tunneling is possible but complex are FTP, which can often be replaced with sftp in any case, and SMB. On some operating systems, remote file system can be mounted over ssh using shfs, lufs or podfuk.

SOCKS

OpenSSH is capable of creating an ad hoc SOCKS proxy server to support more flexible proxying than is possible with ordinary port forwarding. For example:

 $ ssh -D1080 user@example.com

establishes a local SOCKS server that listens on "localhost:1080".

tun-based VPN

Beginning with version 4.3, OpenSSH implements an OSI layer 2/3 "tun"-based VPN. This is the most flexible of OpenSSH's tunneling capabilities, allowing applications to transparently access remote network resources without "socksification."

Authentication

OpenSSH server can authenticate users using its built-in authentication systems:

• public key,
• keyboard-interactive (passwords and challenge-response), and
• Kerberos/GSSAPI.

In addition, OpenSSH can often make use of additional authentication methods available on its host operating system. This can include using the BSD authentication system (bsd_auth) or PAM to enable authentication through methods such as one time passwords.

An unfortunate side-effect of using PAM with OpenSSH is that it must be run as root when PAM support is enabled, as root privileges are typically required to operate PAM. OpenSSH versions after 3.7 allow the usage of PAM to be disabled at run-time, so regular users can run sshd instances.

See also

• Manual pages

 $ man hosts_access
 $ man ssh
 $ man sshd
 $ man sshd_config

• Denyhosts
• Public Key Authentication
• Remote Access to SUSE
• SDB:Exporting the Graphical Output to a Remote Computer
• SUSE Security Lockdown - Hardening Your Linux System

External links

• OpenSSH home page
• OpenSSH for Windows
• Portable releases
• Darren Tucker's OpenSSH Page
• Privilege Separation of OpenSSH