README
1 See https://www.openssh.com/releasenotes.html#7.5p1 for the release notes.
2
3 Please read https://www.openssh.com/report.html for bug reporting
4 instructions and note that we do not use Github for bug reporting or
5 patch/pull-request management.
6
7 - A Japanese translation of this document and of the release notes is
8 - available at http://www.unixuser.org/~haruyama/security/openssh/index.html
9 - Thanks to HARUYAMA Seigo <haruyama (a] unixuser.org>
10
11 This is the port of OpenBSD's excellent OpenSSH[0] to Linux and other
12 Unices.
13
14 OpenSSH is based on the last free version of Tatu Ylonen's sample
15 implementation with all patent-encumbered algorithms removed (to
16 external libraries), all known security bugs fixed, new features
17 reintroduced and many other clean-ups. OpenSSH has been created by
18 Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos, Theo de Raadt,
19 and Dug Song. It has a homepage at https://www.openssh.com/
20
21 This port consists of the re-introduction of autoconf support, PAM
22 support, EGD[1]/PRNGD[2] support and replacements for OpenBSD library
23 functions that are (regrettably) absent from other unices. This port
24 has been best tested on AIX, Cygwin, HP-UX, Linux, MacOS/X,
25 NetBSD, OpenBSD, OpenServer, Solaris, Unicos, and UnixWare.
26
27 This version actively tracks changes in the OpenBSD CVS repository.
28
29 The PAM support is now more functional than the popular packages of
30 commercial ssh-1.2.x. It checks "account" and "session" modules for
31 all logins, not just when using password authentication.
32
33 OpenSSH depends on Zlib[3], OpenSSL[4] and optionally PAM[5].
34
35 There is now several mailing lists for this port of OpenSSH. Please
36 refer to https://www.openssh.com/list.html for details on how to join.
37
38 Please send bug reports and patches to the mailing list
39 openssh-unix-dev (a] mindrot.org. The list is open to posting by unsubscribed
40 users. Code contribution are welcomed, but please follow the OpenBSD
41 style guidelines[6].
42
43 Please refer to the INSTALL document for information on how to install
44 OpenSSH on your system.
45
46 Damien Miller <djm (a] mindrot.org>
47
48 Miscellania -
49
50 This version of OpenSSH is based upon code retrieved from the OpenBSD
51 CVS repository which in turn was based on the last free sample
52 implementation released by Tatu Ylonen.
53
54 References -
55
56 [0] https://www.openssh.com/
57 [1] http://www.lothar.com/tech/crypto/
58 [2] http://www.aet.tu-cottbus.de/personen/jaenicke/postfix_tls/prngd.html
59 [3] http://www.gzip.org/zlib/
60 [4] http://www.openssl.org/
61 [5] http://www.openpam.org
62 http://www.kernel.org/pub/linux/libs/pam/
63 (PAM also is standard on Solaris and HP-UX 11)
64 [6] http://man.openbsd.org/style.9
65
README.dns
1 How to verify host keys using OpenSSH and DNS
2 ---------------------------------------------
3
4 OpenSSH contains support for verifying host keys using DNS as described in
5 draft-ietf-secsh-dns-05.txt. The document contains very brief instructions
6 on how to use this feature. Configuring DNS is out of the scope of this
7 document.
8
9
10 (1) Server: Generate and publish the DNS RR
11
12 To create a DNS resource record (RR) containing a fingerprint of the
13 public host key, use the following command:
14
15 ssh-keygen -r hostname -f keyfile -g
16
17 where "hostname" is your fully qualified hostname and "keyfile" is the
18 file containing the public host key file. If you have multiple keys,
19 you should generate one RR for each key.
20
21 In the example above, ssh-keygen will print the fingerprint in a
22 generic DNS RR format parsable by most modern name server
23 implementations. If your nameserver has support for the SSHFP RR
24 you can omit the -g flag and ssh-keygen will print a standard SSHFP RR.
25
26 To publish the fingerprint using the DNS you must add the generated RR
27 to your DNS zone file and sign your zone.
28
29
30 (2) Client: Enable ssh to verify host keys using DNS
31
32 To enable the ssh client to verify host keys using DNS, you have to
33 add the following option to the ssh configuration file
34 ($HOME/.ssh/config or /etc/ssh/ssh_config):
35
36 VerifyHostKeyDNS yes
37
38 Upon connection the client will try to look up the fingerprint RR
39 using DNS. If the fingerprint received from the DNS server matches
40 the remote host key, the user will be notified.
41
42
43 Jakob Schlyter
44 Wesley Griffin
45
46
47 $OpenBSD: README.dns,v 1.2 2003/10/14 19:43:23 jakob Exp $
48
README.platform
1 This file contains notes about OpenSSH on specific platforms.
2
3 AIX
4 ---
5 As of OpenSSH 3.8p1, sshd will now honour an accounts password expiry
6 settings, where previously it did not. Because of this, it's possible for
7 sites that have used OpenSSH's sshd exclusively to have accounts which
8 have passwords expired longer than the inactive time (ie the "Weeks between
9 password EXPIRATION and LOCKOUT" setting in SMIT or the maxexpired
10 chuser attribute).
11
12 Accounts in this state must have their passwords reset manually by the
13 administrator. As a precaution, it is recommended that the administrative
14 passwords be reset before upgrading from OpenSSH <3.8.
15
16 As of OpenSSH 4.0, configure will attempt to detect if your version
17 and maintenance level of AIX has a working getaddrinfo, and will use it
18 if found. This will enable IPv6 support. If for some reason configure
19 gets it wrong, or if you want to build binaries to work on earlier MLs
20 than the build host then you can add "-DBROKEN_GETADDRINFO" to CFLAGS
21 to force the previous IPv4-only behaviour.
22
23 IPv6 known to work: 5.1ML7 5.2ML2 5.2ML5
24 IPv6 known broken: 4.3.3ML11 5.1ML4
25
26 If you wish to use dynamic libraries that aren't in the normal system
27 locations (eg IBM's OpenSSL and zlib packages) then you will need to
28 define the environment variable blibpath before running configure, eg
29
30 blibpath=/lib:/usr/lib:/opt/freeware/lib ./configure \
31 --with-ssl-dir=/opt/freeware --with-zlib=/opt/freeware
32
33 If sshd is built with the WITH_AIXAUTHENTICATE option (which is enabled
34 by default) then sshd checks that users are permitted via the
35 loginrestrictions() function, in particular that the user has the
36 "rlogin" attribute set. This check is not done for the root account,
37 instead the PermitRootLogin setting in sshd_config is used.
38
39 If you are using the IBM compiler you probably want to use CC=xlc rather
40 than the default of cc.
41
42
43 Cygwin
44 ------
45 To build on Cygwin, OpenSSH requires the following packages:
46 gcc, gcc-mingw-core, mingw-runtime, binutils, make, openssl,
47 openssl-devel, zlib, minres, minires-devel.
48
49
50 Darwin and MacOS X
51 ------------------
52 Darwin does not provide a tun(4) driver required for OpenSSH-based
53 virtual private networks. The BSD manpage still exists, but the driver
54 has been removed in recent releases of Darwin and MacOS X.
55
56 Nevertheless, tunnel support is known to work with Darwin 8 and
57 MacOS X 10.4 in Point-to-Point (Layer 3) and Ethernet (Layer 2) mode
58 using a third party driver. More information is available at:
59 http://www-user.rhrk.uni-kl.de/~nissler/tuntap/
60
61
62 Linux
63 -----
64
65 Some Linux distributions (including Red Hat/Fedora/CentOS) include
66 headers and library links in the -devel RPMs rather than the main
67 binary RPMs. If you get an error about headers, or complaining about a
68 missing prerequisite then you may need to install the equivalent
69 development packages. On Redhat based distros these may be openssl-devel,
70 zlib-devel and pam-devel, on Debian based distros these may be
71 libssl-dev, libz-dev and libpam-dev.
72
73
74 Solaris
75 -------
76 If you enable BSM auditing on Solaris, you need to update audit_event(4)
77 for praudit(1m) to give sensible output. The following line needs to be
78 added to /etc/security/audit_event:
79
80 32800:AUE_openssh:OpenSSH login:lo
81
82 The BSM audit event range available for third party TCB applications is
83 32768 - 65535. Event number 32800 has been choosen for AUE_openssh.
84 There is no official registry of 3rd party event numbers, so if this
85 number is already in use on your system, you may change it at build time
86 by configure'ing --with-cflags=-DAUE_openssh=32801 then rebuilding.
87
88
89 Platforms using PAM
90 -------------------
91 As of OpenSSH 4.3p1, sshd will no longer check /etc/nologin itself when
92 PAM is enabled. To maintain existing behaviour, pam_nologin should be
93 added to sshd's session stack which will prevent users from starting shell
94 sessions. Alternatively, pam_nologin can be added to either the auth or
95 account stacks which will prevent authentication entirely, but will still
96 return the output from pam_nologin to the client.
97
README.privsep
1 Privilege separation, or privsep, is method in OpenSSH by which
2 operations that require root privilege are performed by a separate
3 privileged monitor process. Its purpose is to prevent privilege
4 escalation by containing corruption to an unprivileged process.
5 More information is available at:
6 http://www.citi.umich.edu/u/provos/ssh/privsep.html
7
8 Privilege separation is now enabled by default; see the
9 UsePrivilegeSeparation option in sshd_config(5).
10
11 When privsep is enabled, during the pre-authentication phase sshd will
12 chroot(2) to "/var/empty" and change its privileges to the "sshd" user
13 and its primary group. sshd is a pseudo-account that should not be
14 used by other daemons, and must be locked and should contain a
15 "nologin" or invalid shell.
16
17 You should do something like the following to prepare the privsep
18 preauth environment:
19
20 # mkdir /var/empty
21 # chown root:sys /var/empty
22 # chmod 755 /var/empty
23 # groupadd sshd
24 # useradd -g sshd -c 'sshd privsep' -d /var/empty -s /bin/false sshd
25
26 /var/empty should not contain any files.
27
28 configure supports the following options to change the default
29 privsep user and chroot directory:
30
31 --with-privsep-path=xxx Path for privilege separation chroot
32 --with-privsep-user=user Specify non-privileged user for privilege separation
33
34 PAM-enabled OpenSSH is known to function with privsep on AIX, FreeBSD,
35 HP-UX (including Trusted Mode), Linux, NetBSD and Solaris.
36
37 On Cygwin, Tru64 Unix, OpenServer, and Unicos only the pre-authentication
38 part of privsep is supported. Post-authentication privsep is disabled
39 automatically (so you won't see the additional process mentioned below).
40
41 Note that for a normal interactive login with a shell, enabling privsep
42 will require 1 additional process per login session.
43
44 Given the following process listing (from HP-UX):
45
46 UID PID PPID C STIME TTY TIME COMMAND
47 root 1005 1 0 10:45:17 ? 0:08 /opt/openssh/sbin/sshd -u0
48 root 6917 1005 0 15:19:16 ? 0:00 sshd: stevesk [priv]
49 stevesk 6919 6917 0 15:19:17 ? 0:03 sshd: stevesk@2
50 stevesk 6921 6919 0 15:19:17 pts/2 0:00 -bash
51
52 process 1005 is the sshd process listening for new connections.
53 process 6917 is the privileged monitor process, 6919 is the user owned
54 sshd process and 6921 is the shell process.
55
README.tun
1 How to use OpenSSH-based virtual private networks
2 -------------------------------------------------
3
4 OpenSSH contains support for VPN tunneling using the tun(4) network
5 tunnel pseudo-device which is available on most platforms, either for
6 layer 2 or 3 traffic.
7
8 The following brief instructions on how to use this feature use
9 a network configuration specific to the OpenBSD operating system.
10
11 (1) Server: Enable support for SSH tunneling
12
13 To enable the ssh server to accept tunnel requests from the client, you
14 have to add the following option to the ssh server configuration file
15 (/etc/ssh/sshd_config):
16
17 PermitTunnel yes
18
19 Restart the server or send the hangup signal (SIGHUP) to let the server
20 reread it's configuration.
21
22 (2) Server: Restrict client access and assign the tunnel
23
24 The OpenSSH server simply uses the file /root/.ssh/authorized_keys to
25 restrict the client to connect to a specified tunnel and to
26 automatically start the related interface configuration command. These
27 settings are optional but recommended:
28
29 tunnel="1",command="sh /etc/netstart tun1" ssh-rsa ... reyk (a] openbsd.org
30
31 (3) Client: Configure the local network tunnel interface
32
33 Use the hostname.if(5) interface-specific configuration file to set up
34 the network tunnel configuration with OpenBSD. For example, use the
35 following configuration in /etc/hostname.tun0 to set up the layer 3
36 tunnel on the client:
37
38 inet 192.168.5.1 255.255.255.252 192.168.5.2
39
40 OpenBSD also supports layer 2 tunneling over the tun device by adding
41 the link0 flag:
42
43 inet 192.168.1.78 255.255.255.0 192.168.1.255 link0
44
45 Layer 2 tunnels can be used in combination with an Ethernet bridge(4)
46 interface, like the following example for /etc/bridgename.bridge0:
47
48 add tun0
49 add sis0
50 up
51
52 (4) Client: Configure the OpenSSH client
53
54 To establish tunnel forwarding for connections to a specified
55 remote host by default, use the following ssh client configuration for
56 the privileged user (in /root/.ssh/config):
57
58 Host sshgateway
59 Tunnel yes
60 TunnelDevice 0:any
61 PermitLocalCommand yes
62 LocalCommand sh /etc/netstart tun0
63
64 A more complicated configuration is possible to establish a tunnel to
65 a remote host which is not directly accessible by the client.
66 The following example describes a client configuration to connect to
67 the remote host over two ssh hops in between. It uses the OpenSSH
68 ProxyCommand in combination with the nc(1) program to forward the final
69 ssh tunnel destination over multiple ssh sessions.
70
71 Host access.somewhere.net
72 User puffy
73 Host dmzgw
74 User puffy
75 ProxyCommand ssh access.somewhere.net nc dmzgw 22
76 Host sshgateway
77 Tunnel Ethernet
78 TunnelDevice 0:any
79 PermitLocalCommand yes
80 LocalCommand sh /etc/netstart tun0
81 ProxyCommand ssh dmzgw nc sshgateway 22
82
83 The following network plan illustrates the previous configuration in
84 combination with layer 2 tunneling and Ethernet bridging.
85
86 +--------+ ( ) +----------------------+
87 | Client |------( Internet )-----| access.somewhere.net |
88 +--------+ ( ) +----------------------+
89 : 192.168.1.78 |
90 :............................. +-------+
91 Forwarded ssh connection : | dmzgw |
92 Layer 2 tunnel : +-------+
93 : |
94 : |
95 : +------------+
96 :......| sshgateway |
97 | +------------+
98 --- real connection Bridge -> | +----------+
99 ... "virtual connection" [ X ]--------| somehost |
100 [X] switch +----------+
101 192.168.1.25
102
103 (5) Client: Connect to the server and establish the tunnel
104
105 Finally connect to the OpenSSH server to establish the tunnel by using
106 the following command:
107
108 ssh sshgateway
109
110 It is also possible to tell the client to fork into the background after
111 the connection has been successfully established:
112
113 ssh -f sshgateway true
114
115 Without the ssh configuration done in step (4), it is also possible
116 to use the following command lines:
117
118 ssh -fw 0:1 sshgateway true
119 ifconfig tun0 192.168.5.1 192.168.5.2 netmask 255.255.255.252
120
121 Using OpenSSH tunnel forwarding is a simple way to establish secure
122 and ad hoc virtual private networks. Possible fields of application
123 could be wireless networks or administrative VPN tunnels.
124
125 Nevertheless, ssh tunneling requires some packet header overhead and
126 runs on top of TCP. It is still suggested to use the IP Security
127 Protocol (IPSec) for robust and permanent VPN connections and to
128 interconnect corporate networks.
129
130 Reyk Floeter
131
132 $OpenBSD: README.tun,v 1.4 2006/03/28 00:12:31 deraadt Exp $
133
README.version