Added Cyg-Win
This commit is contained in:
parent
82cbc206eb
commit
413c315806
10586 changed files with 3806249 additions and 0 deletions
102
Agent-Windows/OGP64/usr/share/doc/openssh/CREDITS
Normal file
102
Agent-Windows/OGP64/usr/share/doc/openssh/CREDITS
Normal file
|
|
@ -0,0 +1,102 @@
|
|||
Tatu Ylonen <ylo@cs.hut.fi> - Creator of SSH
|
||||
|
||||
Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos,
|
||||
Theo de Raadt, and Dug Song - Creators of OpenSSH
|
||||
|
||||
Ahsan Rashid <arms@sco.com> - UnixWare long passwords
|
||||
Alain St-Denis <Alain.St-Denis@ec.gc.ca> - Irix fix
|
||||
Alexandre Oliva <oliva@lsd.ic.unicamp.br> - AIX fixes
|
||||
Andre Lucas <andre@ae-35.com> - new login code, many fixes
|
||||
Andreas Steinmetz <ast@domdv.de> - Shadow password expiry support
|
||||
Andrew McGill <andrewm@datrix.co.za> - SCO fixes
|
||||
Andrew Morgan <morgan@transmeta.com> - PAM bugfixes
|
||||
Andrew Stribblehill <a.d.stribblehill@durham.ac.uk> - Bugfixes
|
||||
Andy Sloane <andy@guildsoftware.com> - bugfixes
|
||||
Aran Cox <acox@cv.telegroup.com> - SCO bugfixes
|
||||
Arkadiusz Miskiewicz <misiek@pld.org.pl> - IPv6 compat fixes
|
||||
Ben Lindstrom <mouring@eviladmin.org> - NeXT support
|
||||
Ben Taylor <bent@clark.net> - Solaris debugging and fixes
|
||||
Bratislav ILICH <bilic@zepter.ru> - Configure fix
|
||||
Charles Levert <charles@comm.polymtl.ca> - SunOS 4 & bug fixes
|
||||
Chip Salzenberg <chip@valinux.com> - Assorted patches
|
||||
Chris Adams <cmadams@hiwaay.net> - OSF SIA support
|
||||
Chris Saia <csaia@wtower.com> - SuSE packaging
|
||||
Chris, the Young One <cky@pobox.com> - Password auth fixes
|
||||
Christos Zoulas <christos@zoulas.com> - Autoconf fixes
|
||||
Chun-Chung Chen <cjj@u.washington.edu> - RPM fixes
|
||||
Corinna Vinschen <vinschen@redhat.com> - Cygwin support
|
||||
Chad Mynhier <mynhier@interstel.net> - Solaris Process Contract support
|
||||
Dan Brosemer <odin@linuxfreak.com> - Autoconf support, build fixes
|
||||
Darren Hall <dhall@virage.org> - AIX patches
|
||||
Darren Tucker <dtucker@zip.com.au> - AIX BFF package scripts
|
||||
David Agraz <dagraz@jahoopa.com> - Build fixes
|
||||
David Del Piero <David.DelPiero@qed.qld.gov.au> - bug fixes
|
||||
David Hesprich <darkgrue@gue-tech.org> - Configure fixes
|
||||
David Rankin <drankin@bohemians.lexington.ky.us> - libwrap, AIX, NetBSD fixes
|
||||
Dag-Erling Smørgrav <des at freebsd.org> - Challenge-Response PAM code.
|
||||
Dhiraj Gulati <dgulati@sco.com> - UnixWare long passwords
|
||||
Ed Eden <ede370@stl.rural.usda.gov> - configure fixes
|
||||
Garrick James <garrick@james.net> - configure fixes
|
||||
Gary E. Miller <gem@rellim.com> - SCO support
|
||||
Ged Lodder <lodder@yacc.com.au> - HPUX fixes and enhancements
|
||||
Gert Doering <gd@hilb1.medat.de> - bug and portability fixes
|
||||
HARUYAMA Seigo <haruyama@unixuser.org> - Translations & doc fixes
|
||||
Hideaki YOSHIFUJI <yoshfuji@ecei.tohoku.ac.jp> - IPv6 and bug fixes
|
||||
Hiroshi Takekawa <takekawa@sr3.t.u-tokyo.ac.jp> - Configure fixes
|
||||
Holger Trapp <Holger.Trapp@Informatik.TU-Chemnitz.DE> - KRB4/AFS config patch
|
||||
IWAMURO Motonori <iwa@mmp.fujitsu.co.jp> - bugfixes
|
||||
Jani Hakala <jahakala@cc.jyu.fi> - Patches
|
||||
Jarno Huuskonen <jhuuskon@hytti.uku.fi> - Bugfixes
|
||||
Jim Knoble <jmknoble@pobox.com> - Many patches
|
||||
Jonchen (email unknown) - the original author of PAM support of SSH
|
||||
Juergen Keil <jk@tools.de> - scp bugfixing
|
||||
KAMAHARA Junzo <kamahara@cc.kshosen.ac.jp> - Configure fixes
|
||||
Kees Cook <cook@cpoint.net> - scp fixes
|
||||
Kenji Miyake <kenji@miyake.org> - Configure fixes
|
||||
Kevin Cawlfield <cawlfiel@us.ibm.com> - AIX fixes.
|
||||
Kevin O'Connor <kevin_oconnor@standardandpoors.com> - RSAless operation
|
||||
Kevin Steves <stevesk@pobox.com> - HP support, bugfixes, improvements
|
||||
Kiyokazu SUTO <suto@ks-and-ks.ne.jp> - Bugfixes
|
||||
Larry Jones <larry.jones@sdrc.com> - Bugfixes
|
||||
Lutz Jaenicke <Lutz.Jaenicke@aet.TU-Cottbus.DE> - Bugfixes
|
||||
Marc G. Fournier <marc.fournier@acadiau.ca> - Solaris patches
|
||||
Mark D. Baushke <mdb@juniper.net> - bug fixes
|
||||
Martin Johansson <fatbob@acc.umu.se> - Linux fixes
|
||||
Mark D. Roth <roth+openssh@feep.net> - Features, bug fixes
|
||||
Mark Miller <markm@swoon.net> - Bugfixes
|
||||
Matt Richards <v2matt@btv.ibm.com> - AIX patches
|
||||
Michael Steffens <michael_steffens at hp.com> - HP-UX fixes
|
||||
Michael Stone <mstone@cs.loyola.edu> - Irix enhancements
|
||||
Nakaji Hiroyuki <nakaji@tutrp.tut.ac.jp> - Sony News-OS patch
|
||||
Nalin Dahyabhai <nalin.dahyabhai@pobox.com> - PAM environment patch
|
||||
Nate Itkin <nitkin@europa.com> - SunOS 4.1.x fixes
|
||||
Niels Kristian Bech Jensen <nkbj@image.dk> - Assorted patches
|
||||
Pavel Kankovsky <peak@argo.troja.mff.cuni.cz> - Security fixes
|
||||
Pavel Troller <patrol@omni.sinus.cz> - Bugfixes
|
||||
Pekka Savola <pekkas@netcore.fi> - Bugfixes
|
||||
Peter Kocks <peter.kocks@baygate.com> - Makefile fixes
|
||||
Peter Stuge <stuge@cdy.org> - mdoc2man.awk script
|
||||
Phil Hands <phil@hands.com> - Debian scripts, assorted patches
|
||||
Phil Karn <karn@ka9q.ampr.org> - Autoconf fixes
|
||||
Philippe WILLEM <Philippe.WILLEM@urssaf.fr> - Bugfixes
|
||||
Phill Camp <P.S.S.Camp@ukc.ac.uk> - login code fix
|
||||
Rip Loomis <loomisg@cist.saic.com> - Solaris package support, fixes
|
||||
Robert Dahlem <Robert.Dahlem at siemens.com> - Reliant Unix fixes
|
||||
Roumen Petrov <openssh@roumenpetrov.info> - Compile & configure fixes
|
||||
SAKAI Kiyotaka <ksakai@kso.netwk.ntt-at.co.jp> - Multiple bugfixes
|
||||
Simon Wilkinson <sxw@dcs.ed.ac.uk> - PAM fixes, Compat with MIT KrbV
|
||||
Solar Designer <solar@openwall.com> - many patches and technical assistance
|
||||
Svante Signell <svante.signell@telia.com> - Bugfixes
|
||||
Thomas Neumann <tom@smart.ruhr.de> - Shadow passwords
|
||||
Tim Rice <tim@multitalents.net> - Portability & SCO fixes
|
||||
Tobias Oetiker <oetiker@ee.ethz.ch> - Bugfixes
|
||||
Tom Bertelson's <tbert@abac.com> - AIX auth fixes
|
||||
Tor-Ake Fransson <torake@hotmail.com> - AIX support
|
||||
Tudor Bosman <tudorb@jm.nu> - MD5 password support
|
||||
Udo Schweigert <ust@cert.siemens.de> - ReliantUNIX support
|
||||
Wendy Palm <wendyp at cray.com> - Cray support.
|
||||
Zack Weinberg <zack@wolery.cumb.org> - GNOME askpass enhancement
|
||||
|
||||
Apologies to anyone I have missed.
|
||||
|
||||
Damien Miller <djm@mindrot.org>
|
||||
10627
Agent-Windows/OGP64/usr/share/doc/openssh/ChangeLog
Normal file
10627
Agent-Windows/OGP64/usr/share/doc/openssh/ChangeLog
Normal file
File diff suppressed because it is too large
Load diff
412
Agent-Windows/OGP64/usr/share/doc/openssh/LICENCE
Normal file
412
Agent-Windows/OGP64/usr/share/doc/openssh/LICENCE
Normal file
|
|
@ -0,0 +1,412 @@
|
|||
This file is part of the OpenSSH software.
|
||||
|
||||
The licences which components of this software fall under are as
|
||||
follows. First, we will summarize and say that all components
|
||||
are under a BSD licence, or a licence more free than that.
|
||||
|
||||
OpenSSH contains no GPL code.
|
||||
|
||||
1)
|
||||
* Copyright (c) 1995 Tatu Ylonen <ylo@cs.hut.fi>, Espoo, Finland
|
||||
* All rights reserved
|
||||
*
|
||||
* As far as I am concerned, the code I have written for this software
|
||||
* can be used freely for any purpose. Any derived versions of this
|
||||
* software must be clearly marked as such, and if the derived work is
|
||||
* incompatible with the protocol description in the RFC file, it must be
|
||||
* called by a name other than "ssh" or "Secure Shell".
|
||||
|
||||
[Tatu continues]
|
||||
* However, I am not implying to give any licenses to any patents or
|
||||
* copyrights held by third parties, and the software includes parts that
|
||||
* are not under my direct control. As far as I know, all included
|
||||
* source code is used in accordance with the relevant license agreements
|
||||
* and can be used freely for any purpose (the GNU license being the most
|
||||
* restrictive); see below for details.
|
||||
|
||||
[However, none of that term is relevant at this point in time. All of
|
||||
these restrictively licenced software components which he talks about
|
||||
have been removed from OpenSSH, i.e.,
|
||||
|
||||
- RSA is no longer included, found in the OpenSSL library
|
||||
- IDEA is no longer included, its use is deprecated
|
||||
- DES is now external, in the OpenSSL library
|
||||
- GMP is no longer used, and instead we call BN code from OpenSSL
|
||||
- Zlib is now external, in a library
|
||||
- The make-ssh-known-hosts script is no longer included
|
||||
- TSS has been removed
|
||||
- MD5 is now external, in the OpenSSL library
|
||||
- RC4 support has been replaced with ARC4 support from OpenSSL
|
||||
- Blowfish is now external, in the OpenSSL library
|
||||
|
||||
[The licence continues]
|
||||
|
||||
Note that any information and cryptographic algorithms used in this
|
||||
software are publicly available on the Internet and at any major
|
||||
bookstore, scientific library, and patent office worldwide. More
|
||||
information can be found e.g. at "http://www.cs.hut.fi/crypto".
|
||||
|
||||
The legal status of this program is some combination of all these
|
||||
permissions and restrictions. Use only at your own responsibility.
|
||||
You will be responsible for any legal consequences yourself; I am not
|
||||
making any claims whether possessing or using this is legal or not in
|
||||
your country, and I am not taking any responsibility on your behalf.
|
||||
|
||||
|
||||
NO WARRANTY
|
||||
|
||||
BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
|
||||
FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
|
||||
OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
|
||||
PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
|
||||
OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
|
||||
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS
|
||||
TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
|
||||
PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
|
||||
REPAIR OR CORRECTION.
|
||||
|
||||
IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
|
||||
WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
|
||||
REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
|
||||
INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
|
||||
OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
|
||||
TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
|
||||
YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
|
||||
PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
|
||||
POSSIBILITY OF SUCH DAMAGES.
|
||||
|
||||
3)
|
||||
ssh-keyscan was contributed by David Mazieres under a BSD-style
|
||||
license.
|
||||
|
||||
* Copyright 1995, 1996 by David Mazieres <dm@lcs.mit.edu>.
|
||||
*
|
||||
* Modification and redistribution in source and binary forms is
|
||||
* permitted provided that due credit is given to the author and the
|
||||
* OpenBSD project by leaving this copyright notice intact.
|
||||
|
||||
4)
|
||||
The Rijndael implementation by Vincent Rijmen, Antoon Bosselaers
|
||||
and Paulo Barreto is in the public domain and distributed
|
||||
with the following license:
|
||||
|
||||
* @version 3.0 (December 2000)
|
||||
*
|
||||
* Optimised ANSI C code for the Rijndael cipher (now AES)
|
||||
*
|
||||
* @author Vincent Rijmen <vincent.rijmen@esat.kuleuven.ac.be>
|
||||
* @author Antoon Bosselaers <antoon.bosselaers@esat.kuleuven.ac.be>
|
||||
* @author Paulo Barreto <paulo.barreto@terra.com.br>
|
||||
*
|
||||
* This code is hereby placed in the public domain.
|
||||
*
|
||||
* THIS SOFTWARE IS PROVIDED BY THE AUTHORS ''AS IS'' AND ANY EXPRESS
|
||||
* OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
|
||||
* WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
|
||||
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE
|
||||
* LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
|
||||
* CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
|
||||
* SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
|
||||
* BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
|
||||
* WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
|
||||
* OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
|
||||
* EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
||||
|
||||
5)
|
||||
One component of the ssh source code is under a 3-clause BSD license,
|
||||
held by the University of California, since we pulled these parts from
|
||||
original Berkeley code.
|
||||
|
||||
* Copyright (c) 1983, 1990, 1992, 1993, 1995
|
||||
* The Regents of the University of California. All rights reserved.
|
||||
*
|
||||
* Redistribution and use in source and binary forms, with or without
|
||||
* modification, are permitted provided that the following conditions
|
||||
* are met:
|
||||
* 1. Redistributions of source code must retain the above copyright
|
||||
* notice, this list of conditions and the following disclaimer.
|
||||
* 2. Redistributions in binary form must reproduce the above copyright
|
||||
* notice, this list of conditions and the following disclaimer in the
|
||||
* documentation and/or other materials provided with the distribution.
|
||||
* 3. Neither the name of the University nor the names of its contributors
|
||||
* may be used to endorse or promote products derived from this software
|
||||
* without specific prior written permission.
|
||||
*
|
||||
* THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
|
||||
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
||||
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
|
||||
* ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
|
||||
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
|
||||
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
|
||||
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
|
||||
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
|
||||
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
|
||||
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
|
||||
* SUCH DAMAGE.
|
||||
|
||||
6)
|
||||
Remaining components of the software are provided under a standard
|
||||
2-term BSD licence with the following names as copyright holders:
|
||||
|
||||
Markus Friedl
|
||||
Theo de Raadt
|
||||
Niels Provos
|
||||
Dug Song
|
||||
Aaron Campbell
|
||||
Damien Miller
|
||||
Kevin Steves
|
||||
Daniel Kouril
|
||||
Wesley Griffin
|
||||
Per Allansson
|
||||
Nils Nordman
|
||||
Simon Wilkinson
|
||||
|
||||
Portable OpenSSH additionally includes code from the following copyright
|
||||
holders, also under the 2-term BSD license:
|
||||
|
||||
Ben Lindstrom
|
||||
Tim Rice
|
||||
Andre Lucas
|
||||
Chris Adams
|
||||
Corinna Vinschen
|
||||
Cray Inc.
|
||||
Denis Parker
|
||||
Gert Doering
|
||||
Jakob Schlyter
|
||||
Jason Downs
|
||||
Juha Yrjölä
|
||||
Michael Stone
|
||||
Networks Associates Technology, Inc.
|
||||
Solar Designer
|
||||
Todd C. Miller
|
||||
Wayne Schroeder
|
||||
William Jones
|
||||
Darren Tucker
|
||||
Sun Microsystems
|
||||
The SCO Group
|
||||
Daniel Walsh
|
||||
Red Hat, Inc
|
||||
Simon Vallet / Genoscope
|
||||
|
||||
* Redistribution and use in source and binary forms, with or without
|
||||
* modification, are permitted provided that the following conditions
|
||||
* are met:
|
||||
* 1. Redistributions of source code must retain the above copyright
|
||||
* notice, this list of conditions and the following disclaimer.
|
||||
* 2. Redistributions in binary form must reproduce the above copyright
|
||||
* notice, this list of conditions and the following disclaimer in the
|
||||
* documentation and/or other materials provided with the distribution.
|
||||
*
|
||||
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
|
||||
* IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
|
||||
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
|
||||
* IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
|
||||
* INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
|
||||
* NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
|
||||
* DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
|
||||
* THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
|
||||
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
|
||||
* THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
||||
|
||||
8) Portable OpenSSH contains the following additional licenses:
|
||||
|
||||
a) snprintf replacement
|
||||
|
||||
* Copyright Patrick Powell 1995
|
||||
* This code is based on code written by Patrick Powell
|
||||
* (papowell@astart.com) It may be used for any purpose as long as this
|
||||
* notice remains intact on all source code distributions
|
||||
|
||||
b) Compatibility code (openbsd-compat)
|
||||
|
||||
Apart from the previously mentioned licenses, various pieces of code
|
||||
in the openbsd-compat/ subdirectory are licensed as follows:
|
||||
|
||||
Some code is licensed under a 3-term BSD license, to the following
|
||||
copyright holders:
|
||||
|
||||
Todd C. Miller
|
||||
Theo de Raadt
|
||||
Damien Miller
|
||||
Eric P. Allman
|
||||
The Regents of the University of California
|
||||
Constantin S. Svintsoff
|
||||
Kungliga Tekniska Högskolan
|
||||
|
||||
* Redistribution and use in source and binary forms, with or without
|
||||
* modification, are permitted provided that the following conditions
|
||||
* are met:
|
||||
* 1. Redistributions of source code must retain the above copyright
|
||||
* notice, this list of conditions and the following disclaimer.
|
||||
* 2. Redistributions in binary form must reproduce the above copyright
|
||||
* notice, this list of conditions and the following disclaimer in the
|
||||
* documentation and/or other materials provided with the distribution.
|
||||
* 3. Neither the name of the University nor the names of its contributors
|
||||
* may be used to endorse or promote products derived from this software
|
||||
* without specific prior written permission.
|
||||
*
|
||||
* THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
|
||||
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
||||
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
|
||||
* ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
|
||||
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
|
||||
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
|
||||
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
|
||||
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
|
||||
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
|
||||
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
|
||||
* SUCH DAMAGE.
|
||||
|
||||
Some code is licensed under an ISC-style license, to the following
|
||||
copyright holders:
|
||||
|
||||
Internet Software Consortium.
|
||||
Todd C. Miller
|
||||
Reyk Floeter
|
||||
Chad Mynhier
|
||||
|
||||
* Permission to use, copy, modify, and distribute this software for any
|
||||
* purpose with or without fee is hereby granted, provided that the above
|
||||
* copyright notice and this permission notice appear in all copies.
|
||||
*
|
||||
* THE SOFTWARE IS PROVIDED "AS IS" AND TODD C. MILLER DISCLAIMS ALL
|
||||
* WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES
|
||||
* OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL TODD C. MILLER BE LIABLE
|
||||
* FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
|
||||
* WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION
|
||||
* OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
|
||||
* CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
|
||||
|
||||
Some code is licensed under a MIT-style license to the following
|
||||
copyright holders:
|
||||
|
||||
Free Software Foundation, Inc.
|
||||
|
||||
* Permission is hereby granted, free of charge, to any person obtaining a *
|
||||
* copy of this software and associated documentation files (the *
|
||||
* "Software"), to deal in the Software without restriction, including *
|
||||
* without limitation the rights to use, copy, modify, merge, publish, *
|
||||
* distribute, distribute with modifications, sublicense, and/or sell *
|
||||
* copies of the Software, and to permit persons to whom the Software is *
|
||||
* furnished to do so, subject to the following conditions: *
|
||||
* *
|
||||
* The above copyright notice and this permission notice shall be included *
|
||||
* in all copies or substantial portions of the Software. *
|
||||
* *
|
||||
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS *
|
||||
* OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF *
|
||||
* MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. *
|
||||
* IN NO EVENT SHALL THE ABOVE COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, *
|
||||
* DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR *
|
||||
* OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR *
|
||||
* THE USE OR OTHER DEALINGS IN THE SOFTWARE. *
|
||||
* *
|
||||
* Except as contained in this notice, the name(s) of the above copyright *
|
||||
* holders shall not be used in advertising or otherwise to promote the *
|
||||
* sale, use or other dealings in this Software without prior written *
|
||||
* authorization. *
|
||||
****************************************************************************/
|
||||
|
||||
The Blowfish cipher implementation is licensed by Niels Provos under
|
||||
a 3-clause BSD license:
|
||||
|
||||
* Blowfish - a fast block cipher designed by Bruce Schneier
|
||||
*
|
||||
* Copyright 1997 Niels Provos <provos@physnet.uni-hamburg.de>
|
||||
* All rights reserved.
|
||||
*
|
||||
* Redistribution and use in source and binary forms, with or without
|
||||
* modification, are permitted provided that the following conditions
|
||||
* are met:
|
||||
* 1. Redistributions of source code must retain the above copyright
|
||||
* notice, this list of conditions and the following disclaimer.
|
||||
* 2. Redistributions in binary form must reproduce the above copyright
|
||||
* notice, this list of conditions and the following disclaimer in the
|
||||
* documentation and/or other materials provided with the distribution.
|
||||
* 3. The name of the author may not be used to endorse or promote products
|
||||
* derived from this software without specific prior written permission.
|
||||
*
|
||||
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
|
||||
* IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
|
||||
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
|
||||
* IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
|
||||
* INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
|
||||
* NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
|
||||
* DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
|
||||
* THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
|
||||
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
|
||||
* THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
||||
|
||||
Some replacement code is licensed by the NetBSD foundation under a
|
||||
2-clause BSD license:
|
||||
|
||||
* Copyright (c) 2001 The NetBSD Foundation, Inc.
|
||||
* All rights reserved.
|
||||
*
|
||||
* This code is derived from software contributed to The NetBSD Foundation
|
||||
* by Todd Vierling.
|
||||
*
|
||||
* Redistribution and use in source and binary forms, with or without
|
||||
* modification, are permitted provided that the following conditions
|
||||
* are met:
|
||||
* 1. Redistributions of source code must retain the above copyright
|
||||
* notice, this list of conditions and the following disclaimer.
|
||||
* 2. Redistributions in binary form must reproduce the above copyright
|
||||
* notice, this list of conditions and the following disclaimer in the
|
||||
* documentation and/or other materials provided with the distribution.
|
||||
*
|
||||
* THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS
|
||||
* ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
|
||||
* TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
|
||||
* PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS
|
||||
* BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
|
||||
* CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
|
||||
* SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
|
||||
* INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
|
||||
* CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
|
||||
* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
|
||||
* POSSIBILITY OF SUCH DAMAGE.
|
||||
|
||||
The replacement base64 implementation has the following MIT-style
|
||||
licenses:
|
||||
|
||||
* Copyright (c) 1996 by Internet Software Consortium.
|
||||
*
|
||||
* Permission to use, copy, modify, and distribute this software for any
|
||||
* purpose with or without fee is hereby granted, provided that the above
|
||||
* copyright notice and this permission notice appear in all copies.
|
||||
*
|
||||
* THE SOFTWARE IS PROVIDED "AS IS" AND INTERNET SOFTWARE CONSORTIUM DISCLAIMS
|
||||
* ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES
|
||||
* OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL INTERNET SOFTWARE
|
||||
* CONSORTIUM BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
|
||||
* DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
|
||||
* PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
|
||||
* ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
|
||||
* SOFTWARE.
|
||||
|
||||
* Portions Copyright (c) 1995 by International Business Machines, Inc.
|
||||
*
|
||||
* International Business Machines, Inc. (hereinafter called IBM) grants
|
||||
* permission under its copyrights to use, copy, modify, and distribute this
|
||||
* Software with or without fee, provided that the above copyright notice and
|
||||
* all paragraphs of this notice appear in all copies, and that the name of IBM
|
||||
* not be used in connection with the marketing of any product incorporating
|
||||
* the Software or modifications thereof, without specific, written prior
|
||||
* permission.
|
||||
*
|
||||
* To the extent it has a right to do so, IBM grants an immunity from suit
|
||||
* under its patents, if any, for the use, sale or manufacture of products to
|
||||
* the extent that such products are used for performing Domain Name System
|
||||
* dynamic updates in TCP/IP networks by means of the Software. No immunity is
|
||||
* granted for any product per se or for any other function of any product.
|
||||
*
|
||||
* THE SOFTWARE IS PROVIDED "AS IS", AND IBM DISCLAIMS ALL WARRANTIES,
|
||||
* INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
|
||||
* PARTICULAR PURPOSE. IN NO EVENT SHALL IBM BE LIABLE FOR ANY SPECIAL,
|
||||
* DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER ARISING
|
||||
* OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE, EVEN
|
||||
* IF IBM IS APPRISED OF THE POSSIBILITY OF SUCH DAMAGES.
|
||||
|
||||
------
|
||||
$OpenBSD: LICENCE,v 1.20 2017/04/30 23:26:16 djm Exp $
|
||||
162
Agent-Windows/OGP64/usr/share/doc/openssh/OVERVIEW
Normal file
162
Agent-Windows/OGP64/usr/share/doc/openssh/OVERVIEW
Normal file
|
|
@ -0,0 +1,162 @@
|
|||
[Note: This file has not been updated for OpenSSH versions after
|
||||
OpenSSH-1.2 and should be considered OBSOLETE. It has been left in
|
||||
the distribution because some of its information may still be useful
|
||||
to developers.]
|
||||
|
||||
This document is intended for those who wish to read the ssh source
|
||||
code. This tries to give an overview of the structure of the code.
|
||||
|
||||
Copyright (c) 1995 Tatu Ylonen <ylo@cs.hut.fi>
|
||||
Updated 17 Nov 1995.
|
||||
Updated 19 Oct 1999 for OpenSSH-1.2
|
||||
Updated 20 May 2001 note obsolete for > OpenSSH-1.2
|
||||
|
||||
The software consists of ssh (client), sshd (server), scp, sdist, and
|
||||
the auxiliary programs ssh-keygen, ssh-agent, ssh-add, and
|
||||
make-ssh-known-hosts. The main program for each of these is in a .c
|
||||
file with the same name.
|
||||
|
||||
There are some subsystems/abstractions that are used by a number of
|
||||
these programs.
|
||||
|
||||
Buffer manipulation routines
|
||||
|
||||
- These provide an arbitrary size buffer, where data can be appended.
|
||||
Data can be consumed from either end. The code is used heavily
|
||||
throughout ssh. The buffer manipulation functions are in
|
||||
sshbuf*.c (header sshbuf.h).
|
||||
|
||||
Compression Library
|
||||
|
||||
- Ssh uses the GNU GZIP compression library (ZLIB).
|
||||
|
||||
Encryption/Decryption
|
||||
|
||||
- Ssh contains several encryption algorithms. These are all
|
||||
accessed through the cipher.h interface. The interface code is
|
||||
in cipher.c, and the implementations are either in libc or
|
||||
LibreSSL.
|
||||
|
||||
Multiple Precision Integer Library
|
||||
|
||||
- Uses the LibreSSL BIGNUM sublibrary.
|
||||
|
||||
Random Numbers
|
||||
|
||||
- Uses arc4random() and such.
|
||||
|
||||
RSA key generation, encryption, decryption
|
||||
|
||||
- Ssh uses the RSA routines in libssl.
|
||||
|
||||
RSA key files
|
||||
|
||||
- RSA keys are stored in files with a special format. The code to
|
||||
read/write these files is in authfile.c. The files are normally
|
||||
encrypted with a passphrase. The functions to read passphrases
|
||||
are in readpass.c (the same code is used to read passwords).
|
||||
|
||||
Binary packet protocol
|
||||
|
||||
- The ssh binary packet protocol is implemented in packet.c. The
|
||||
code in packet.c does not concern itself with packet types or their
|
||||
execution; it contains code to build packets, to receive them and
|
||||
extract data from them, and the code to compress and/or encrypt
|
||||
packets.
|
||||
|
||||
- The code in packet.c calls the buffer manipulation routines
|
||||
(buffer.c, bufaux.c), compression routines (zlib), and the
|
||||
encryption routines.
|
||||
|
||||
X11, TCP/IP, and Agent forwarding
|
||||
|
||||
- Code for various types of channel forwarding is in channels.c.
|
||||
The file defines a generic framework for arbitrary communication
|
||||
channels inside the secure channel, and uses this framework to
|
||||
implement X11 forwarding, TCP/IP forwarding, and authentication
|
||||
agent forwarding.
|
||||
The new, Protocol 1.5, channel close implementation is in nchan.c
|
||||
|
||||
Authentication agent
|
||||
|
||||
- Code to communicate with the authentication agent is in authfd.c.
|
||||
|
||||
Authentication methods
|
||||
|
||||
- Code for various authentication methods resides in auth-*.c
|
||||
(auth-passwd.c, auth-rh-rsa.c, auth-rhosts.c, auth-rsa.c). This
|
||||
code is linked into the server. The routines also manipulate
|
||||
known hosts files using code in hostfile.c. Code in canohost.c
|
||||
is used to retrieve the canonical host name of the remote host.
|
||||
Code in match.c is used to match host names.
|
||||
|
||||
- In the client end, authentication code is in sshconnect.c. It
|
||||
reads Passwords/passphrases using code in readpass.c. It reads
|
||||
RSA key files with authfile.c. It communicates the
|
||||
authentication agent using authfd.c.
|
||||
|
||||
The ssh client
|
||||
|
||||
- The client main program is in ssh.c. It first parses arguments
|
||||
and reads configuration (readconf.c), then calls ssh_connect (in
|
||||
sshconnect.c) to open a connection to the server (possibly via a
|
||||
proxy), and performs authentication (ssh_login in sshconnect.c).
|
||||
It then makes any pty, forwarding, etc. requests. It may call
|
||||
code in ttymodes.c to encode current tty modes. Finally it
|
||||
calls client_loop in clientloop.c. This does the real work for
|
||||
the session.
|
||||
|
||||
Pseudo-tty manipulation and tty modes
|
||||
|
||||
- Code to allocate and use a pseudo tty is in pty.c. Code to
|
||||
encode and set terminal modes is in ttymodes.c.
|
||||
|
||||
Logging in (updating utmp, lastlog, etc.)
|
||||
|
||||
- The code to do things that are done when a user logs in are in
|
||||
login.c. This includes things such as updating the utmp, wtmp,
|
||||
and lastlog files. Some of the code is in sshd.c.
|
||||
|
||||
Writing to the system log and terminal
|
||||
|
||||
- The programs use the functions fatal(), log(), debug(), error()
|
||||
in many places to write messages to system log or user's
|
||||
terminal. The implementation that logs to system log is in
|
||||
log-server.c; it is used in the server program. The other
|
||||
programs use an implementation that sends output to stderr; it
|
||||
is in log-client.c. The definitions are in ssh.h.
|
||||
|
||||
The sshd server (daemon)
|
||||
|
||||
- The sshd daemon starts by processing arguments and reading the
|
||||
configuration file (servconf.c). It then reads the host key,
|
||||
starts listening for connections, and generates the server key.
|
||||
The server key will be regenerated every hour by an alarm.
|
||||
|
||||
- When the server receives a connection, it forks, disables the
|
||||
regeneration alarm, and starts communicating with the client.
|
||||
They first perform identification string exchange, then
|
||||
negotiate encryption, then perform authentication, preparatory
|
||||
operations, and finally the server enters the normal session
|
||||
mode by calling server_loop in serverloop.c. This does the real
|
||||
work, calling functions in other modules.
|
||||
|
||||
- The code for the server is in sshd.c. It contains a lot of
|
||||
stuff, including:
|
||||
- server main program
|
||||
- waiting for connections
|
||||
- processing new connection
|
||||
- authentication
|
||||
- preparatory operations
|
||||
- building up the execution environment for the user program
|
||||
- starting the user program.
|
||||
|
||||
Auxiliary files
|
||||
|
||||
- There are several other files in the distribution that contain
|
||||
various auxiliary routines:
|
||||
ssh.h the main header file for ssh (various definitions)
|
||||
uidswap.c uid-swapping
|
||||
xmalloc.c "safe" malloc routines
|
||||
|
||||
$OpenBSD: OVERVIEW,v 1.15 2018/10/23 05:56:35 djm Exp $
|
||||
721
Agent-Windows/OGP64/usr/share/doc/openssh/PROTOCOL
Normal file
721
Agent-Windows/OGP64/usr/share/doc/openssh/PROTOCOL
Normal file
|
|
@ -0,0 +1,721 @@
|
|||
This documents OpenSSH's deviations and extensions to the published SSH
|
||||
protocol.
|
||||
|
||||
Note that OpenSSH's sftp and sftp-server implement revision 3 of the SSH
|
||||
filexfer protocol described in:
|
||||
|
||||
https://www.openssh.com/txt/draft-ietf-secsh-filexfer-02.txt
|
||||
|
||||
Newer versions of the draft will not be supported, though some features
|
||||
are individually implemented as extensions described below.
|
||||
|
||||
The protocol used by OpenSSH's ssh-agent is described in the file
|
||||
PROTOCOL.agent
|
||||
|
||||
1. Transport protocol changes
|
||||
|
||||
1.1. transport: Protocol 2 MAC algorithm "umac-64@openssh.com"
|
||||
|
||||
This is a new transport-layer MAC method using the UMAC algorithm
|
||||
(rfc4418). This method is identical to the "umac-64" method documented
|
||||
in:
|
||||
|
||||
https://www.openssh.com/txt/draft-miller-secsh-umac-01.txt
|
||||
|
||||
1.2. transport: Protocol 2 compression algorithm "zlib@openssh.com"
|
||||
|
||||
This transport-layer compression method uses the zlib compression
|
||||
algorithm (identical to the "zlib" method in rfc4253), but delays the
|
||||
start of compression until after authentication has completed. This
|
||||
avoids exposing compression code to attacks from unauthenticated users.
|
||||
|
||||
The method is documented in:
|
||||
|
||||
https://www.openssh.com/txt/draft-miller-secsh-compression-delayed-00.txt
|
||||
|
||||
1.3. transport: Certificate key algorithms
|
||||
|
||||
OpenSSH introduces new public key algorithms to support certificate
|
||||
authentication for users and host keys. These methods are documented
|
||||
in at https://datatracker.ietf.org/doc/draft-miller-ssh-cert/
|
||||
|
||||
1.4. transport: Elliptic Curve cryptography
|
||||
|
||||
OpenSSH supports ECC key exchange and public key authentication as
|
||||
specified in RFC5656. Only the ecdsa-sha2-nistp256, ecdsa-sha2-nistp384
|
||||
and ecdsa-sha2-nistp521 curves over GF(p) are supported. Elliptic
|
||||
curve points encoded using point compression are NOT accepted or
|
||||
generated.
|
||||
|
||||
1.5 transport: Protocol 2 Encrypt-then-MAC MAC algorithms
|
||||
|
||||
OpenSSH supports MAC algorithms, whose names contain "-etm", that
|
||||
perform the calculations in a different order to that defined in RFC
|
||||
4253. These variants use the so-called "encrypt then MAC" ordering,
|
||||
calculating the MAC over the packet ciphertext rather than the
|
||||
plaintext. This ordering closes a security flaw in the SSH transport
|
||||
protocol, where decryption of unauthenticated ciphertext provided a
|
||||
"decryption oracle" that could, in conjunction with cipher flaws, reveal
|
||||
session plaintext.
|
||||
|
||||
Specifically, the "-etm" MAC algorithms modify the transport protocol
|
||||
to calculate the MAC over the packet ciphertext and to send the packet
|
||||
length unencrypted. This is necessary for the transport to obtain the
|
||||
length of the packet and location of the MAC tag so that it may be
|
||||
verified without decrypting unauthenticated data.
|
||||
|
||||
As such, the MAC covers:
|
||||
|
||||
mac = MAC(key, sequence_number || packet_length || encrypted_packet)
|
||||
|
||||
where "packet_length" is encoded as a uint32 and "encrypted_packet"
|
||||
contains:
|
||||
|
||||
byte padding_length
|
||||
byte[n1] payload; n1 = packet_length - padding_length - 1
|
||||
byte[n2] random padding; n2 = padding_length
|
||||
|
||||
1.6 transport: AES-GCM
|
||||
|
||||
OpenSSH supports the AES-GCM algorithm as specified in RFC 5647.
|
||||
Because of problems with the design of the algorithm negotiation in this
|
||||
RFC, OpenSSH (and other SSH implementations) use different rules as
|
||||
described in:
|
||||
|
||||
https://datatracker.ietf.org/doc/draft-miller-sshm-aes-gcm/
|
||||
|
||||
1.7 transport: chacha20-poly1305@openssh.com authenticated encryption
|
||||
|
||||
OpenSSH supports authenticated encryption using ChaCha20 and Poly1305
|
||||
as described in:
|
||||
|
||||
https://datatracker.ietf.org/doc/draft-ietf-sshm-chacha20-poly1305/
|
||||
|
||||
1.8 transport: ping facility
|
||||
|
||||
OpenSSH implements a transport level ping message SSH2_MSG_PING
|
||||
and a corresponding SSH2_MSG_PONG reply.
|
||||
|
||||
#define SSH2_MSG_PING 192
|
||||
#define SSH2_MSG_PONG 193
|
||||
|
||||
The ping message is simply:
|
||||
|
||||
byte SSH_MSG_PING
|
||||
string data
|
||||
|
||||
The reply copies the data (which may be the empty string) from the
|
||||
ping:
|
||||
|
||||
byte SSH_MSG_PONG
|
||||
string data
|
||||
|
||||
Replies are sent in order. They are sent immediately except when rekeying
|
||||
is in progress, in which case they are queued until rekeying completes.
|
||||
|
||||
The server advertises support for these messages using the
|
||||
SSH2_MSG_EXT_INFO mechanism (RFC8308), with the following message:
|
||||
|
||||
string "ping@openssh.com"
|
||||
string "0" (version)
|
||||
|
||||
The ping/reply message is implemented at the transport layer rather
|
||||
than as a named global or channel request to allow pings with very
|
||||
short packet lengths, which would not be possible with other
|
||||
approaches.
|
||||
|
||||
1.9 transport: strict key exchange extension
|
||||
|
||||
OpenSSH supports a number of transport-layer hardening measures
|
||||
designed to thwart the so-called "Terrapin" attack against the
|
||||
early SSH protocol. These are collectively referred to as
|
||||
"strict KEX" and documented in an Internet-Draft:
|
||||
|
||||
https://datatracker.ietf.org/doc/draft-miller-sshm-strict-kex/
|
||||
|
||||
1.10 transport: SSH2_MSG_EXT_INFO during user authentication
|
||||
|
||||
This protocol extension allows the SSH2_MSG_EXT_INFO to be sent
|
||||
during user authentication. RFC8308 does allow a second
|
||||
SSH2_MSG_EXT_INFO notification, but it may only be sent at the end
|
||||
of user authentication and this is too late to signal per-user
|
||||
server signature algorithms.
|
||||
|
||||
Support for receiving the SSH2_MSG_EXT_INFO message during user
|
||||
authentication is signalled by the client including a
|
||||
"ext-info-in-auth@openssh.com" key via its initial SSH2_MSG_EXT_INFO
|
||||
set after the SSH2_MSG_NEWKEYS message.
|
||||
|
||||
A server that supports this extension MAY send a second
|
||||
SSH2_MSG_EXT_INFO message any time after the client's first
|
||||
SSH2_MSG_USERAUTH_REQUEST, regardless of whether it succeed or fails.
|
||||
The client SHOULD be prepared to update the server-sig-algs that
|
||||
it received during an earlier SSH2_MSG_EXT_INFO with the later one.
|
||||
|
||||
2. Connection protocol changes
|
||||
|
||||
2.1. connection: Channel write close extension "eow@openssh.com"
|
||||
|
||||
The SSH connection protocol (rfc4254) provides the SSH_MSG_CHANNEL_EOF
|
||||
message to allow an endpoint to signal its peer that it will send no
|
||||
more data over a channel. Unfortunately, there is no symmetric way for
|
||||
an endpoint to request that its peer should cease sending data to it
|
||||
while still keeping the channel open for the endpoint to send data to
|
||||
the peer.
|
||||
|
||||
This is desirable, since it saves the transmission of data that would
|
||||
otherwise need to be discarded and it allows an endpoint to signal local
|
||||
processes of the condition, e.g. by closing the corresponding file
|
||||
descriptor.
|
||||
|
||||
OpenSSH implements a channel extension message to perform this
|
||||
signalling: "eow@openssh.com" (End Of Write). This message is sent by
|
||||
an endpoint when the local output of a session channel is closed or
|
||||
experiences a write error. The message is formatted as follows:
|
||||
|
||||
byte SSH_MSG_CHANNEL_REQUEST
|
||||
uint32 recipient channel
|
||||
string "eow@openssh.com"
|
||||
boolean FALSE
|
||||
|
||||
On receiving this message, the peer SHOULD cease sending data of
|
||||
the channel and MAY signal the process from which the channel data
|
||||
originates (e.g. by closing its read file descriptor).
|
||||
|
||||
As with the symmetric SSH_MSG_CHANNEL_EOF message, the channel does
|
||||
remain open after a "eow@openssh.com" has been sent and more data may
|
||||
still be sent in the other direction. This message does not consume
|
||||
window space and may be sent even if no window space is available.
|
||||
|
||||
NB. due to certain broken SSH implementations aborting upon receipt
|
||||
of this message (in contravention of RFC4254 section 5.4), this
|
||||
message is only sent to OpenSSH peers (identified by banner).
|
||||
Other SSH implementations may be listed to receive this message
|
||||
upon request.
|
||||
|
||||
2.2. connection: disallow additional sessions extension
|
||||
"no-more-sessions@openssh.com"
|
||||
|
||||
Most SSH connections will only ever request a single session, but a
|
||||
attacker may abuse a running ssh client to surreptitiously open
|
||||
additional sessions under their control. OpenSSH provides a global
|
||||
request "no-more-sessions@openssh.com" to mitigate this attack.
|
||||
|
||||
When an OpenSSH client expects that it will never open another session
|
||||
(i.e. it has been started with connection multiplexing disabled), it
|
||||
will send the following global request:
|
||||
|
||||
byte SSH_MSG_GLOBAL_REQUEST
|
||||
string "no-more-sessions@openssh.com"
|
||||
char want-reply
|
||||
|
||||
On receipt of such a message, an OpenSSH server will refuse to open
|
||||
future channels of type "session" and instead immediately abort the
|
||||
connection.
|
||||
|
||||
Note that this is not a general defence against compromised clients
|
||||
(that is impossible), but it thwarts a simple attack.
|
||||
|
||||
NB. due to certain broken SSH implementations aborting upon receipt
|
||||
of this message, the no-more-sessions request is only sent to OpenSSH
|
||||
servers (identified by banner). Other SSH implementations may be
|
||||
listed to receive this message upon request.
|
||||
|
||||
2.3. connection: Tunnel forward extension "tun@openssh.com"
|
||||
|
||||
OpenSSH supports layer 2 and layer 3 tunnelling via the "tun@openssh.com"
|
||||
channel type. This channel type supports forwarding of network packets
|
||||
with datagram boundaries intact between endpoints equipped with
|
||||
interfaces like the BSD tun(4) device. Tunnel forwarding channels are
|
||||
requested by the client with the following packet:
|
||||
|
||||
byte SSH_MSG_CHANNEL_OPEN
|
||||
string "tun@openssh.com"
|
||||
uint32 sender channel
|
||||
uint32 initial window size
|
||||
uint32 maximum packet size
|
||||
uint32 tunnel mode
|
||||
uint32 remote unit number
|
||||
|
||||
The "tunnel mode" parameter specifies whether the tunnel should forward
|
||||
layer 2 frames or layer 3 packets. It may take one of the following values:
|
||||
|
||||
SSH_TUNMODE_POINTOPOINT 1 /* layer 3 packets */
|
||||
SSH_TUNMODE_ETHERNET 2 /* layer 2 frames */
|
||||
|
||||
The "tunnel unit number" specifies the remote interface number, or may
|
||||
be 0x7fffffff to allow the server to automatically choose an interface. A
|
||||
server that is not willing to open a client-specified unit should refuse
|
||||
the request with a SSH_MSG_CHANNEL_OPEN_FAILURE error. On successful
|
||||
open, the server should reply with SSH_MSG_CHANNEL_OPEN_SUCCESS.
|
||||
|
||||
Once established the client and server may exchange packet or frames
|
||||
over the tunnel channel by encapsulating them in SSH protocol strings
|
||||
and sending them as channel data. This ensures that packet boundaries
|
||||
are kept intact. Specifically, packets are transmitted using normal
|
||||
SSH_MSG_CHANNEL_DATA packets:
|
||||
|
||||
byte SSH_MSG_CHANNEL_DATA
|
||||
uint32 recipient channel
|
||||
string data
|
||||
|
||||
The contents of the "data" field for layer 3 packets is:
|
||||
|
||||
uint32 packet length
|
||||
uint32 address family
|
||||
byte[packet length - 4] packet data
|
||||
|
||||
The "address family" field identifies the type of packet in the message.
|
||||
It may be one of:
|
||||
|
||||
SSH_TUN_AF_INET 2 /* IPv4 */
|
||||
SSH_TUN_AF_INET6 24 /* IPv6 */
|
||||
|
||||
The "packet data" field consists of the IPv4/IPv6 datagram itself
|
||||
without any link layer header.
|
||||
|
||||
The contents of the "data" field for layer 2 packets is:
|
||||
|
||||
uint32 packet length
|
||||
byte[packet length] frame
|
||||
|
||||
The "frame" field contains an IEEE 802.3 Ethernet frame, including
|
||||
header.
|
||||
|
||||
2.4. connection: Unix domain socket forwarding
|
||||
|
||||
OpenSSH supports local and remote Unix domain socket forwarding
|
||||
using the "streamlocal" extension. Forwarding is initiated as per
|
||||
TCP sockets but with a single path instead of a host and port.
|
||||
|
||||
Similar to direct-tcpip, direct-streamlocal is sent by the client
|
||||
to request that the server make a connection to a Unix domain socket.
|
||||
|
||||
byte SSH_MSG_CHANNEL_OPEN
|
||||
string "direct-streamlocal@openssh.com"
|
||||
uint32 sender channel
|
||||
uint32 initial window size
|
||||
uint32 maximum packet size
|
||||
string socket path
|
||||
string reserved
|
||||
uint32 reserved
|
||||
|
||||
Similar to forwarded-tcpip, forwarded-streamlocal is sent by the
|
||||
server when the client has previously send the server a streamlocal-forward
|
||||
GLOBAL_REQUEST.
|
||||
|
||||
byte SSH_MSG_CHANNEL_OPEN
|
||||
string "forwarded-streamlocal@openssh.com"
|
||||
uint32 sender channel
|
||||
uint32 initial window size
|
||||
uint32 maximum packet size
|
||||
string socket path
|
||||
string reserved for future use
|
||||
|
||||
The reserved field is not currently defined and is ignored on the
|
||||
remote end. It is intended to be used in the future to pass
|
||||
information about the socket file, such as ownership and mode.
|
||||
The client currently sends the empty string for this field.
|
||||
|
||||
Similar to tcpip-forward, streamlocal-forward is sent by the client
|
||||
to request remote forwarding of a Unix domain socket.
|
||||
|
||||
byte SSH2_MSG_GLOBAL_REQUEST
|
||||
string "streamlocal-forward@openssh.com"
|
||||
boolean TRUE
|
||||
string socket path
|
||||
|
||||
Similar to cancel-tcpip-forward, cancel-streamlocal-forward is sent
|
||||
by the client cancel the forwarding of a Unix domain socket.
|
||||
|
||||
byte SSH2_MSG_GLOBAL_REQUEST
|
||||
string "cancel-streamlocal-forward@openssh.com"
|
||||
boolean FALSE
|
||||
string socket path
|
||||
|
||||
2.5. connection: hostkey update and rotation "hostkeys-00@openssh.com"
|
||||
and "hostkeys-prove-00@openssh.com"
|
||||
|
||||
OpenSSH supports a protocol extension allowing a server to inform
|
||||
a client of all its protocol v.2 host keys after user-authentication
|
||||
has completed. This is documented in an Internet-Draft
|
||||
|
||||
https://datatracker.ietf.org/doc/draft-miller-sshm-hostkey-update/
|
||||
|
||||
2.6. connection: SIGINFO support for "signal" channel request
|
||||
|
||||
The SSH channels protocol (RFC4254 section 6.9) supports sending a
|
||||
signal to a session attached to a channel. OpenSSH supports one
|
||||
extension signal "INFO@openssh.com" that allows sending SIGINFO on
|
||||
BSD-derived systems.
|
||||
|
||||
3. Authentication protocol changes
|
||||
|
||||
3.1. Host-bound public key authentication
|
||||
|
||||
This is trivial change to the traditional "publickey" authentication
|
||||
method. The authentication request is identical to the original method
|
||||
but for the name and one additional field:
|
||||
|
||||
byte SSH2_MSG_USERAUTH_REQUEST
|
||||
string username
|
||||
string "ssh-connection"
|
||||
string "publickey-hostbound-v00@openssh.com"
|
||||
bool has_signature
|
||||
string pkalg
|
||||
string public key
|
||||
string server host key
|
||||
|
||||
Because the entire SSH2_MSG_USERAUTH_REQUEST message is included in
|
||||
the signed data, this ensures that a binding between the destination
|
||||
user, the server identity and the session identifier is visible to the
|
||||
signer. OpenSSH uses this binding via signed data to implement per-key
|
||||
restrictions in ssh-agent.
|
||||
|
||||
A server may advertise this method using the SSH2_MSG_EXT_INFO
|
||||
mechanism (RFC8308), with the following message:
|
||||
|
||||
string "publickey-hostbound@openssh.com"
|
||||
string "0" (version)
|
||||
|
||||
Clients should prefer host-bound authentication when advertised by
|
||||
server.
|
||||
|
||||
4. SFTP protocol changes
|
||||
|
||||
4.1. sftp: Reversal of arguments to SSH_FXP_SYMLINK
|
||||
|
||||
When OpenSSH's sftp-server was implemented, the order of the arguments
|
||||
to the SSH_FXP_SYMLINK method was inadvertently reversed. Unfortunately,
|
||||
the reversal was not noticed until the server was widely deployed. Since
|
||||
fixing this to follow the specification would cause incompatibility, the
|
||||
current order was retained. For correct operation, clients should send
|
||||
SSH_FXP_SYMLINK as follows:
|
||||
|
||||
uint32 id
|
||||
string targetpath
|
||||
string linkpath
|
||||
|
||||
4.2. sftp: Server extension announcement in SSH_FXP_VERSION
|
||||
|
||||
OpenSSH's sftp-server lists the extensions it supports using the
|
||||
standard extension announcement mechanism in the SSH_FXP_VERSION server
|
||||
hello packet:
|
||||
|
||||
uint32 3 /* protocol version */
|
||||
string ext1-name
|
||||
string ext1-version
|
||||
string ext2-name
|
||||
string ext2-version
|
||||
...
|
||||
string extN-name
|
||||
string extN-version
|
||||
|
||||
Each extension reports its integer version number as an ASCII encoded
|
||||
string, e.g. "1". The version will be incremented if the extension is
|
||||
ever changed in an incompatible way. The server MAY advertise the same
|
||||
extension with multiple versions (though this is unlikely). Clients MUST
|
||||
check the version number before attempting to use the extension.
|
||||
|
||||
4.3. sftp: Extension request "posix-rename@openssh.com"
|
||||
|
||||
This operation provides a rename operation with POSIX semantics, which
|
||||
are different to those provided by the standard SSH_FXP_RENAME in
|
||||
draft-ietf-secsh-filexfer-02.txt. This request is implemented as a
|
||||
SSH_FXP_EXTENDED request with the following format:
|
||||
|
||||
uint32 id
|
||||
string "posix-rename@openssh.com"
|
||||
string oldpath
|
||||
string newpath
|
||||
|
||||
On receiving this request the server will perform the POSIX operation
|
||||
rename(oldpath, newpath) and will respond with a SSH_FXP_STATUS message.
|
||||
This extension is advertised in the SSH_FXP_VERSION hello with version
|
||||
"1".
|
||||
|
||||
4.4. sftp: Extension requests "statvfs@openssh.com" and
|
||||
"fstatvfs@openssh.com"
|
||||
|
||||
These requests correspond to the statvfs and fstatvfs POSIX system
|
||||
interfaces. The "statvfs@openssh.com" request operates on an explicit
|
||||
pathname, and is formatted as follows:
|
||||
|
||||
uint32 id
|
||||
string "statvfs@openssh.com"
|
||||
string path
|
||||
|
||||
The "fstatvfs@openssh.com" operates on an open file handle:
|
||||
|
||||
uint32 id
|
||||
string "fstatvfs@openssh.com"
|
||||
string handle
|
||||
|
||||
These requests return a SSH_FXP_STATUS reply on failure. On success they
|
||||
return the following SSH_FXP_EXTENDED_REPLY reply:
|
||||
|
||||
uint32 id
|
||||
uint64 f_bsize /* file system block size */
|
||||
uint64 f_frsize /* fundamental fs block size */
|
||||
uint64 f_blocks /* number of blocks (unit f_frsize) */
|
||||
uint64 f_bfree /* free blocks in file system */
|
||||
uint64 f_bavail /* free blocks for non-root */
|
||||
uint64 f_files /* total file inodes */
|
||||
uint64 f_ffree /* free file inodes */
|
||||
uint64 f_favail /* free file inodes for to non-root */
|
||||
uint64 f_fsid /* file system id */
|
||||
uint64 f_flag /* bit mask of f_flag values */
|
||||
uint64 f_namemax /* maximum filename length */
|
||||
|
||||
The values of the f_flag bitmask are as follows:
|
||||
|
||||
#define SSH_FXE_STATVFS_ST_RDONLY 0x1 /* read-only */
|
||||
#define SSH_FXE_STATVFS_ST_NOSUID 0x2 /* no setuid */
|
||||
|
||||
Both the "statvfs@openssh.com" and "fstatvfs@openssh.com" extensions are
|
||||
advertised in the SSH_FXP_VERSION hello with version "2".
|
||||
|
||||
4.5. sftp: Extension request "hardlink@openssh.com"
|
||||
|
||||
This request is for creating a hard link to a regular file. This
|
||||
request is implemented as a SSH_FXP_EXTENDED request with the
|
||||
following format:
|
||||
|
||||
uint32 id
|
||||
string "hardlink@openssh.com"
|
||||
string oldpath
|
||||
string newpath
|
||||
|
||||
On receiving this request the server will perform the operation
|
||||
link(oldpath, newpath) and will respond with a SSH_FXP_STATUS message.
|
||||
This extension is advertised in the SSH_FXP_VERSION hello with version
|
||||
"1".
|
||||
|
||||
4.6. sftp: Extension request "fsync@openssh.com"
|
||||
|
||||
This request asks the server to call fsync(2) on an open file handle.
|
||||
|
||||
uint32 id
|
||||
string "fsync@openssh.com"
|
||||
string handle
|
||||
|
||||
On receiving this request, a server will call fsync(handle_fd) and will
|
||||
respond with a SSH_FXP_STATUS message.
|
||||
|
||||
This extension is advertised in the SSH_FXP_VERSION hello with version
|
||||
"1".
|
||||
|
||||
4.7. sftp: Extension request "lsetstat@openssh.com"
|
||||
|
||||
This request is like the "setstat" command, but sets file attributes on
|
||||
symlinks. It is implemented as a SSH_FXP_EXTENDED request with the
|
||||
following format:
|
||||
|
||||
uint32 id
|
||||
string "lsetstat@openssh.com"
|
||||
string path
|
||||
ATTRS attrs
|
||||
|
||||
See the "setstat" command for more details.
|
||||
|
||||
This extension is advertised in the SSH_FXP_VERSION hello with version
|
||||
"1".
|
||||
|
||||
4.8. sftp: Extension request "limits@openssh.com"
|
||||
|
||||
This request is used to determine various limits the server might impose.
|
||||
Clients should not attempt to exceed these limits as the server might sever
|
||||
the connection immediately.
|
||||
|
||||
uint32 id
|
||||
string "limits@openssh.com"
|
||||
|
||||
The server will respond with a SSH_FXP_EXTENDED_REPLY reply:
|
||||
|
||||
uint32 id
|
||||
uint64 max-packet-length
|
||||
uint64 max-read-length
|
||||
uint64 max-write-length
|
||||
uint64 max-open-handles
|
||||
|
||||
The 'max-packet-length' applies to the total number of bytes in a
|
||||
single SFTP packet. Servers SHOULD set this at least to 34000.
|
||||
|
||||
The 'max-read-length' is the largest length in a SSH_FXP_READ packet.
|
||||
Even if the client requests a larger size, servers will usually respond
|
||||
with a shorter SSH_FXP_DATA packet. Servers SHOULD set this at least to
|
||||
32768.
|
||||
|
||||
The 'max-write-length' is the largest length in a SSH_FXP_WRITE packet
|
||||
the server will accept. Servers SHOULD set this at least to 32768.
|
||||
|
||||
The 'max-open-handles' is the maximum number of active handles that the
|
||||
server allows (e.g. handles created by SSH_FXP_OPEN and SSH_FXP_OPENDIR
|
||||
packets). Servers MAY count internal file handles against this limit
|
||||
(e.g. system logging or stdout/stderr), so clients SHOULD NOT expect to
|
||||
open this many handles in practice.
|
||||
|
||||
If the server doesn't enforce a specific limit, then the field may be
|
||||
set to 0. This implies the server relies on the OS to enforce limits
|
||||
(e.g. available memory or file handles), and such limits might be
|
||||
dynamic. The client SHOULD take care to not try to exceed reasonable
|
||||
limits.
|
||||
|
||||
This extension is advertised in the SSH_FXP_VERSION hello with version
|
||||
"1".
|
||||
|
||||
4.9. sftp: Extension request "expand-path@openssh.com"
|
||||
|
||||
This request supports canonicalisation of relative paths and
|
||||
those that need tilde-expansion, i.e. "~", "~/..." and "~user/..."
|
||||
These paths are expanded using shell-like rules and the resultant
|
||||
path is canonicalised similarly to SSH2_FXP_REALPATH.
|
||||
|
||||
It is implemented as a SSH_FXP_EXTENDED request with the following
|
||||
format:
|
||||
|
||||
uint32 id
|
||||
string "expand-path@openssh.com"
|
||||
string path
|
||||
|
||||
Its reply is the same format as that of SSH2_FXP_REALPATH.
|
||||
|
||||
This extension is advertised in the SSH_FXP_VERSION hello with version
|
||||
"1".
|
||||
|
||||
4.10. sftp: Extension request "copy-data"
|
||||
|
||||
This request asks the server to copy data from one open file handle and
|
||||
write it to a different open file handle. This avoids needing to transfer
|
||||
the data across the network twice (a download followed by an upload).
|
||||
|
||||
byte SSH_FXP_EXTENDED
|
||||
uint32 id
|
||||
string "copy-data"
|
||||
string read-from-handle
|
||||
uint64 read-from-offset
|
||||
uint64 read-data-length
|
||||
string write-to-handle
|
||||
uint64 write-to-offset
|
||||
|
||||
The server will copy read-data-length bytes starting from
|
||||
read-from-offset from the read-from-handle and write them to
|
||||
write-to-handle starting from write-to-offset, and then respond with a
|
||||
SSH_FXP_STATUS message.
|
||||
|
||||
It's equivalent to issuing a series of SSH_FXP_READ requests on
|
||||
read-from-handle and a series of requests of SSH_FXP_WRITE on
|
||||
write-to-handle.
|
||||
|
||||
If read-from-handle and write-to-handle are the same, the server will
|
||||
fail the request and respond with a SSH_FX_INVALID_PARAMETER message.
|
||||
|
||||
If read-data-length is 0, then the server will read data from the
|
||||
read-from-handle until EOF is reached.
|
||||
|
||||
This extension is advertised in the SSH_FXP_VERSION hello with version
|
||||
"1".
|
||||
|
||||
This request is identical to the "copy-data" request documented in:
|
||||
|
||||
https://tools.ietf.org/html/draft-ietf-secsh-filexfer-extensions-00#section-7
|
||||
|
||||
4.11. sftp: Extension request "home-directory"
|
||||
|
||||
This request asks the server to expand the specified user's home directory.
|
||||
An empty username implies the current user. This can be used by the client
|
||||
to expand ~/ type paths locally.
|
||||
|
||||
byte SSH_FXP_EXTENDED
|
||||
uint32 id
|
||||
string "home-directory"
|
||||
string username
|
||||
|
||||
This extension is advertised in the SSH_FXP_VERSION hello with version
|
||||
"1".
|
||||
|
||||
This provides similar information as the "expand-path@openssh.com" extension.
|
||||
|
||||
This request is identical to the "home-directory" request documented in:
|
||||
|
||||
https://datatracker.ietf.org/doc/html/draft-ietf-secsh-filexfer-extensions-00#section-5
|
||||
|
||||
4.12. sftp: Extension request "users-groups-by-id@openssh.com"
|
||||
|
||||
This request asks the server to return user and/or group names that
|
||||
correspond to one or more IDs (e.g. as returned from a SSH_FXP_STAT
|
||||
request). This may be used by the client to provide usernames in
|
||||
directory listings.
|
||||
|
||||
byte SSH_FXP_EXTENDED
|
||||
uint32 id
|
||||
string "users-groups-by-id@openssh.com"
|
||||
string uids
|
||||
string gids
|
||||
|
||||
Where "uids" and "gids" consists of one or more integer user or group
|
||||
identifiers:
|
||||
|
||||
uint32 id-0
|
||||
...
|
||||
|
||||
The server will reply with a SSH_FXP_EXTENDED_REPLY:
|
||||
|
||||
byte SSH_FXP_EXTENDED_REPLY
|
||||
uint32 id
|
||||
string usernames
|
||||
string groupnames
|
||||
|
||||
Where "username" and "groupnames" consists of names in identical request
|
||||
order to "uids" and "gids" respectively:
|
||||
|
||||
string name-0
|
||||
...
|
||||
|
||||
If a name cannot be identified for a given user or group ID, an empty
|
||||
string will be returned in its place.
|
||||
|
||||
It is acceptable for either "uids" or "gids" to be an empty set, in
|
||||
which case the respective "usernames" or "groupnames" list will also
|
||||
be empty.
|
||||
|
||||
This extension is advertised in the SSH_FXP_VERSION hello with version
|
||||
"1".
|
||||
|
||||
5. Miscellaneous changes
|
||||
|
||||
5.1 Public key format
|
||||
|
||||
OpenSSH public keys, as generated by ssh-keygen(1) and appearing in
|
||||
authorized_keys files, are formatted as a single line of text consisting
|
||||
of the public key algorithm name followed by a base64-encoded key blob.
|
||||
The public key blob (before base64 encoding) is the same format used for
|
||||
the encoding of public keys sent on the wire: as described in RFC4253
|
||||
section 6.6 for RSA keys, RFC5656 section 3.1 for ECDSA keys and
|
||||
https://datatracker.ietf.org/doc/draft-miller-ssh-cert/
|
||||
for the OpenSSH certificate formats.
|
||||
|
||||
5.2 Private key format
|
||||
|
||||
OpenSSH private keys, as generated by ssh-keygen(1) use the format
|
||||
described in PROTOCOL.key by default. As a legacy option, PEM format
|
||||
(RFC7468) private keys are also supported for RSA and ECDSA keys
|
||||
and were the default format before OpenSSH 7.8.
|
||||
|
||||
5.3 KRL format
|
||||
|
||||
OpenSSH supports a compact format for Key Revocation Lists (KRLs). This
|
||||
format is described in the PROTOCOL.krl file.
|
||||
|
||||
5.4 Connection multiplexing
|
||||
|
||||
OpenSSH's connection multiplexing uses messages as described in
|
||||
PROTOCOL.mux over a Unix domain socket for communications between a
|
||||
master instance and later clients.
|
||||
|
||||
5.5. Agent protocol extensions
|
||||
|
||||
OpenSSH extends the usual agent protocol. These changes are documented
|
||||
in the PROTOCOL.agent file.
|
||||
|
||||
$OpenBSD: PROTOCOL,v 1.60 2026/02/09 22:09:48 dtucker Exp $
|
||||
107
Agent-Windows/OGP64/usr/share/doc/openssh/PROTOCOL.agent
Normal file
107
Agent-Windows/OGP64/usr/share/doc/openssh/PROTOCOL.agent
Normal file
|
|
@ -0,0 +1,107 @@
|
|||
The SSH agent protocol is described in
|
||||
https://datatracker.ietf.org/doc/draft-ietf-sshm-ssh-agent/
|
||||
|
||||
This file documents OpenSSH's extensions to the agent protocol.
|
||||
|
||||
1. session-bind@openssh.com extension
|
||||
|
||||
This extension allows a ssh client to bind an agent connection to a
|
||||
particular SSH session identifier as derived from the initial key
|
||||
exchange (as per RFC4253 section 7.2) and the host key used for that
|
||||
exchange. This binding is verifiable at the agent by including the
|
||||
initial KEX signature made by the host key.
|
||||
|
||||
The message format is:
|
||||
|
||||
byte SSH_AGENTC_EXTENSION (0x1b)
|
||||
string session-bind@openssh.com
|
||||
string hostkey
|
||||
string session identifier
|
||||
string signature
|
||||
bool is_forwarding
|
||||
|
||||
Where 'hostkey' is the encoded server host public key, 'session
|
||||
identifier' is the exchange hash derived from the initial key
|
||||
exchange, 'signature' is the server's signature of the session
|
||||
identifier using the private hostkey, as sent in the final
|
||||
SSH2_MSG_KEXDH_REPLY/SSH2_MSG_KEXECDH_REPLY message of the initial key
|
||||
exchange. 'is_forwarding' is a flag indicating whether this connection
|
||||
should be bound for user authentication or forwarding.
|
||||
|
||||
When an agent received this message, it will verify the signature and
|
||||
check the consistency of its contents, including refusing to accept
|
||||
a duplicate session identifier, or any attempt to bind a connection
|
||||
previously bound for authentication. It will then record the
|
||||
binding for the life of the connection for use later in testing per-key
|
||||
destination constraints.
|
||||
|
||||
2. restrict-destination-v00@openssh.com key constraint extension
|
||||
|
||||
The key constraint extension supports destination- and forwarding path-
|
||||
restricted keys. It may be attached as a constraint when keys or
|
||||
smartcard keys are added to an agent.
|
||||
|
||||
byte SSH_AGENT_CONSTRAIN_EXTENSION (0xff)
|
||||
string restrict-destination-v00@openssh.com
|
||||
constraint[] constraints
|
||||
|
||||
Where a constraint consists of:
|
||||
|
||||
string from_username (must be empty)
|
||||
string from_hostname
|
||||
string reserved
|
||||
keyspec[] from_hostkeys
|
||||
string to_username
|
||||
string to_hostname
|
||||
string reserved
|
||||
keyspec[] to_hostkeys
|
||||
string reserved
|
||||
|
||||
And a keyspec consists of:
|
||||
|
||||
string keyblob
|
||||
bool is_ca
|
||||
|
||||
When receiving this message, the agent will ensure that the
|
||||
'from_username' field is empty, and that 'to_hostname' and 'to_hostkeys'
|
||||
have been supplied (empty 'from_hostname' and 'from_hostkeys' are valid
|
||||
and signify the initial hop from the host running ssh-agent). The agent
|
||||
will then record the constraint against the key.
|
||||
|
||||
Subsequent operations on this key including add/remove/request
|
||||
identities and, in particular, signature requests will check the key
|
||||
constraints against the session-bind@openssh.com bindings recorded for
|
||||
the agent connection over which they were received.
|
||||
|
||||
3. associated-certs-v00@openssh.com key constraint extension
|
||||
|
||||
The key constraint extension allows certificates to be associated
|
||||
with private keys as they are loaded from a PKCS#11 token.
|
||||
|
||||
byte SSH_AGENT_CONSTRAIN_EXTENSION (0xff)
|
||||
string associated-certs-v00@openssh.com
|
||||
bool certs_only
|
||||
string certsblob
|
||||
|
||||
Where "certsblob" consists of one or more certificates encoded as public
|
||||
key blobs:
|
||||
|
||||
string[] certificates
|
||||
|
||||
This extension is only valid for SSH_AGENTC_ADD_SMARTCARD_KEY_CONSTRAINED
|
||||
requests. When an agent receives this extension, it will attempt to match
|
||||
each certificate in the request with a corresponding private key loaded
|
||||
from the requested PKCS#11 token. When a matching key is found, the
|
||||
agent will graft the certificate contents to the token-hosted private key
|
||||
and store the result for subsequent use by regular agent operations.
|
||||
|
||||
If the "certs_only" flag is set, then this extension will cause ONLY
|
||||
the resultant certificates to be loaded to the agent. The default
|
||||
behaviour is to load the PKCS#11-hosted private key as well as the
|
||||
resultant certificate.
|
||||
|
||||
A SSH_AGENTC_ADD_SMARTCARD_KEY_CONSTRAINED will return SSH_AGENT_SUCCESS
|
||||
if any key (plain private or certificate) was successfully loaded, or
|
||||
SSH_AGENT_FAILURE if no key was loaded.
|
||||
|
||||
$OpenBSD: PROTOCOL.agent,v 1.25 2025/08/29 03:50:38 djm Exp $
|
||||
296
Agent-Windows/OGP64/usr/share/doc/openssh/PROTOCOL.mux
Normal file
296
Agent-Windows/OGP64/usr/share/doc/openssh/PROTOCOL.mux
Normal file
|
|
@ -0,0 +1,296 @@
|
|||
This document describes the multiplexing protocol used by ssh(1)'s
|
||||
ControlMaster connection-sharing.
|
||||
|
||||
Multiplexing starts with a ssh(1) configured to act as a multiplexing
|
||||
master. This will cause ssh(1) to listen on a Unix domain socket for
|
||||
requests from clients. Clients communicate over this socket using a
|
||||
simple packetised protocol, where each message is proceeded with
|
||||
a length and message type in SSH uint32 wire format:
|
||||
|
||||
uint32 packet length
|
||||
uint32 packet type
|
||||
... packet body
|
||||
|
||||
Most messages from the client to the server contain a "request id"
|
||||
field. This field is returned in replies as "client request id" to
|
||||
facilitate matching of responses to requests.
|
||||
|
||||
Many multiplexing (mux) client requests yield immediate responses from
|
||||
the mux process; requesting a forwarding, performing an alive check or
|
||||
requesting the master terminate itself fall in to this category.
|
||||
|
||||
The most common use of multiplexing however is to maintain multiple
|
||||
concurrent sessions. These are supported via two separate modes:
|
||||
|
||||
"Passenger" clients start by requesting a new session with a
|
||||
MUX_C_NEW_SESSION message and passing stdio file descriptors over the
|
||||
Unix domain control socket. The passenger client then waits until it is
|
||||
signaled or the mux server closes the session. This mode is so named as
|
||||
the client waits around while the mux server does all the driving.
|
||||
|
||||
Stdio forwarding (requested using MUX_C_NEW_STDIO_FWD) is another
|
||||
example of passenger mode; the client passes the stdio file descriptors
|
||||
and passively waits for something to happen.
|
||||
|
||||
"Proxy" clients, requested using MUX_C_PROXY, work quite differently. In
|
||||
this mode, the mux client/server connection socket will stop speaking
|
||||
the multiplexing protocol and start proxying SSH connection protocol
|
||||
messages between the client and server. The client therefore must
|
||||
speak a significant subset of the SSH protocol, but in return is able
|
||||
to access basically the full suite of connection protocol features.
|
||||
Moreover, as no file descriptor passing is required, the connection
|
||||
supporting a proxy client may itself be forwarded or relayed to another
|
||||
host if necessary.
|
||||
|
||||
1. Connection setup
|
||||
|
||||
When a multiplexing connection is made to a ssh(1) operating as a
|
||||
ControlMaster from a client ssh(1), the first action of each is send
|
||||
a hello messages to its peer:
|
||||
|
||||
uint32 MUX_MSG_HELLO
|
||||
uint32 protocol version
|
||||
string extension name [optional]
|
||||
string extension value [optional]
|
||||
...
|
||||
|
||||
The current version of the mux protocol is 4. A client should refuse
|
||||
to connect to a master that speaks an unsupported protocol version.
|
||||
|
||||
Following the version identifier are zero or more extensions represented
|
||||
as a name/value pair. No extensions are currently defined.
|
||||
|
||||
2. Opening a passenger mode session
|
||||
|
||||
To open a new multiplexed session in passenger mode, a client sends the
|
||||
following request:
|
||||
|
||||
uint32 MUX_C_NEW_SESSION
|
||||
uint32 request id
|
||||
string reserved
|
||||
bool want tty flag
|
||||
bool want X11 forwarding flag
|
||||
bool want agent flag
|
||||
bool subsystem flag
|
||||
uint32 escape char
|
||||
string terminal type
|
||||
string command
|
||||
string environment string 0 [optional]
|
||||
...
|
||||
|
||||
To disable the use of an escape character, "escape char" may be set
|
||||
to 0xffffffff. "terminal type" is generally set to the value of
|
||||
$TERM. zero or more environment strings may follow the command.
|
||||
|
||||
The client then sends its standard input, output and error file
|
||||
descriptors (in that order) using Unix domain socket control messages.
|
||||
|
||||
The contents of "reserved" are currently ignored.
|
||||
|
||||
If successful, the server will reply with MUX_S_SESSION_OPENED
|
||||
|
||||
uint32 MUX_S_SESSION_OPENED
|
||||
uint32 client request id
|
||||
uint32 session id
|
||||
|
||||
Otherwise it will reply with an error: MUX_S_PERMISSION_DENIED or
|
||||
MUX_S_FAILURE.
|
||||
|
||||
Once the server has received the fds, it will respond with MUX_S_OK
|
||||
indicating that the session is up. The client now waits for the
|
||||
session to end. When it does, the server will send an exit status
|
||||
message:
|
||||
|
||||
uint32 MUX_S_EXIT_MESSAGE
|
||||
uint32 session id
|
||||
uint32 exit value
|
||||
|
||||
The client should exit with this value to mimic the behaviour of a
|
||||
non-multiplexed ssh(1) connection. Two additional cases that the
|
||||
client must cope with are it receiving a signal itself and the
|
||||
server disconnecting without sending an exit message.
|
||||
|
||||
A master may also send a MUX_S_TTY_ALLOC_FAIL before MUX_S_EXIT_MESSAGE
|
||||
if remote TTY allocation was unsuccessful. The client may use this to
|
||||
return its local tty to "cooked" mode.
|
||||
|
||||
uint32 MUX_S_TTY_ALLOC_FAIL
|
||||
uint32 session id
|
||||
|
||||
3. Requesting passenger-mode stdio forwarding
|
||||
|
||||
A client may request the master to establish a stdio forwarding:
|
||||
|
||||
uint32 MUX_C_NEW_STDIO_FWD
|
||||
uint32 request id
|
||||
string reserved
|
||||
string connect host
|
||||
string connect port
|
||||
|
||||
The client then sends its standard input and output file descriptors
|
||||
(in that order) using Unix domain socket control messages.
|
||||
|
||||
The contents of "reserved" are currently ignored.
|
||||
|
||||
A server may reply with a MUX_S_SESSION_OPENED, a MUX_S_PERMISSION_DENIED
|
||||
or a MUX_S_FAILURE.
|
||||
|
||||
4. Health checks
|
||||
|
||||
The client may request a health check/PID report from a server:
|
||||
|
||||
uint32 MUX_C_ALIVE_CHECK
|
||||
uint32 request id
|
||||
|
||||
The server replies with:
|
||||
|
||||
uint32 MUX_S_ALIVE
|
||||
uint32 client request id
|
||||
uint32 server pid
|
||||
|
||||
5. Remotely terminating a master
|
||||
|
||||
A client may request that a master terminate immediately:
|
||||
|
||||
uint32 MUX_C_TERMINATE
|
||||
uint32 request id
|
||||
|
||||
The server will reply with one of MUX_S_OK or MUX_S_PERMISSION_DENIED.
|
||||
|
||||
6. Requesting establishment of port forwards
|
||||
|
||||
A client may request the master to establish a port forward:
|
||||
|
||||
uint32 MUX_C_OPEN_FWD
|
||||
uint32 request id
|
||||
uint32 forwarding type
|
||||
string listen host
|
||||
uint32 listen port
|
||||
string connect host
|
||||
uint32 connect port
|
||||
|
||||
forwarding type may be MUX_FWD_LOCAL, MUX_FWD_REMOTE, MUX_FWD_DYNAMIC.
|
||||
|
||||
If listen port is (unsigned int) -2, then the listen host is treated as
|
||||
a unix socket path name.
|
||||
|
||||
If connect port is (unsigned int) -2, then the connect host is treated
|
||||
as a unix socket path name.
|
||||
|
||||
A server may reply with a MUX_S_OK, a MUX_S_REMOTE_PORT, a
|
||||
MUX_S_PERMISSION_DENIED or a MUX_S_FAILURE.
|
||||
|
||||
For dynamically allocated listen port the server replies with
|
||||
|
||||
uint32 MUX_S_REMOTE_PORT
|
||||
uint32 client request id
|
||||
uint32 allocated remote listen port
|
||||
|
||||
7. Requesting closure of port forwards
|
||||
|
||||
A client may request the master to close a port forward:
|
||||
|
||||
uint32 MUX_C_CLOSE_FWD
|
||||
uint32 request id
|
||||
uint32 forwarding type
|
||||
string listen host
|
||||
uint32 listen port
|
||||
string connect host
|
||||
uint32 connect port
|
||||
|
||||
A server may reply with a MUX_S_OK, a MUX_S_PERMISSION_DENIED or a
|
||||
MUX_S_FAILURE.
|
||||
|
||||
8. Requesting shutdown of mux listener
|
||||
|
||||
A client may request the master to stop accepting new multiplexing requests
|
||||
and remove its listener socket.
|
||||
|
||||
uint32 MUX_C_STOP_LISTENING
|
||||
uint32 request id
|
||||
|
||||
A server may reply with a MUX_S_OK, a MUX_S_PERMISSION_DENIED or a
|
||||
MUX_S_FAILURE.
|
||||
|
||||
9. Requesting proxy mode
|
||||
|
||||
A client may request that the control connection be placed in proxy
|
||||
mode:
|
||||
|
||||
uint32 MUX_C_PROXY
|
||||
uint32 request id
|
||||
|
||||
When a mux master receives this message, it will reply with a
|
||||
confirmation:
|
||||
|
||||
uint32 MUX_S_PROXY
|
||||
uint32 request id
|
||||
|
||||
And go into proxy mode. All subsequent data over the connection will
|
||||
be formatted as unencrypted, unpadded, SSH transport messages:
|
||||
|
||||
uint32 packet length
|
||||
byte 0 (padding length)
|
||||
byte packet type
|
||||
byte[packet length - 2] ...
|
||||
|
||||
The mux master will accept most connection messages and global requests,
|
||||
and will translate channel identifiers to ensure that the proxy client has
|
||||
globally unique channel numbers (i.e. a proxy client need not worry about
|
||||
collisions with other clients).
|
||||
|
||||
10. Status messages
|
||||
|
||||
The MUX_S_OK message is empty:
|
||||
|
||||
uint32 MUX_S_OK
|
||||
uint32 client request id
|
||||
|
||||
The MUX_S_PERMISSION_DENIED and MUX_S_FAILURE include a reason:
|
||||
|
||||
uint32 MUX_S_PERMISSION_DENIED
|
||||
uint32 client request id
|
||||
string reason
|
||||
|
||||
uint32 MUX_S_FAILURE
|
||||
uint32 client request id
|
||||
string reason
|
||||
|
||||
11. Protocol numbers
|
||||
|
||||
#define MUX_MSG_HELLO 0x00000001
|
||||
#define MUX_C_NEW_SESSION 0x10000002
|
||||
#define MUX_C_ALIVE_CHECK 0x10000004
|
||||
#define MUX_C_TERMINATE 0x10000005
|
||||
#define MUX_C_OPEN_FWD 0x10000006
|
||||
#define MUX_C_CLOSE_FWD 0x10000007
|
||||
#define MUX_C_NEW_STDIO_FWD 0x10000008
|
||||
#define MUX_C_STOP_LISTENING 0x10000009
|
||||
#define MUX_S_OK 0x80000001
|
||||
#define MUX_S_PERMISSION_DENIED 0x80000002
|
||||
#define MUX_S_FAILURE 0x80000003
|
||||
#define MUX_S_EXIT_MESSAGE 0x80000004
|
||||
#define MUX_S_ALIVE 0x80000005
|
||||
#define MUX_S_SESSION_OPENED 0x80000006
|
||||
#define MUX_S_REMOTE_PORT 0x80000007
|
||||
#define MUX_S_TTY_ALLOC_FAIL 0x80000008
|
||||
|
||||
#define MUX_FWD_LOCAL 1
|
||||
#define MUX_FWD_REMOTE 2
|
||||
#define MUX_FWD_DYNAMIC 3
|
||||
|
||||
XXX TODO
|
||||
XXX extended status (e.g. report open channels / forwards)
|
||||
XXX lock (maybe)
|
||||
XXX watch in/out traffic (pre/post crypto)
|
||||
XXX inject packet (what about replies)
|
||||
XXX server->client error/warning notifications
|
||||
XXX send signals via mux
|
||||
XXX ^Z support in passengers
|
||||
XXX extensions for multi-agent
|
||||
XXX extensions for multi-X11
|
||||
XXX session inspection via master
|
||||
XXX signals via mux request
|
||||
XXX list active connections via mux
|
||||
|
||||
$OpenBSD: PROTOCOL.mux,v 1.14 2024/01/08 05:11:18 djm Exp $
|
||||
49
Agent-Windows/OGP64/usr/share/doc/openssh/README
Normal file
49
Agent-Windows/OGP64/usr/share/doc/openssh/README
Normal file
|
|
@ -0,0 +1,49 @@
|
|||
See https://www.openssh.com/releasenotes.html#10.3p1 for the release
|
||||
notes.
|
||||
|
||||
Please read https://www.openssh.com/report.html for bug reporting
|
||||
instructions and note that we do not use Github for bug reporting.
|
||||
|
||||
This is the port of OpenBSD's excellent OpenSSH[0] to Linux and other
|
||||
Unices.
|
||||
|
||||
OpenSSH is based on the last free version of Tatu Ylonen's sample
|
||||
implementation with all patent-encumbered algorithms removed (to external
|
||||
libraries), all known security bugs fixed, new features reintroduced and
|
||||
many other clean-ups. OpenSSH was created by Aaron Campbell, Bob Beck,
|
||||
Markus Friedl, Niels Provos, Theo de Raadt, and Dug Song, and has been
|
||||
developed and maintained by Andre Lucas, Ben Lindstom, Damien Miller,
|
||||
Darren Tucker and Tim Rice. It has a homepage at https://www.openssh.com/
|
||||
|
||||
This port consists of the re-introduction of autoconf support, PAM
|
||||
support, EGD/PRNGD support and replacements for OpenBSD library
|
||||
functions that are (regrettably) absent from other unices. This port
|
||||
has been best tested on AIX, Cygwin, HP-UX, Linux, MacOS/X,
|
||||
FreeBSD, NetBSD, OpenBSD, OpenServer, Solaris and UnixWare.
|
||||
|
||||
This version actively tracks changes in the OpenBSD CVS repository.
|
||||
|
||||
There is now several mailing lists for this port of OpenSSH. Please
|
||||
refer to https://www.openssh.com/list.html for details on how to join.
|
||||
|
||||
Please send bug reports and patches to https://bugzilla.mindrot.org or
|
||||
the mailing list openssh-unix-dev@mindrot.org. To mitigate spam, the
|
||||
list only allows posting from subscribed addresses. Code contribution
|
||||
are welcomed, but please follow the OpenBSD style guidelines[1].
|
||||
|
||||
Please refer to the INSTALL document for information on dependencies and
|
||||
how to install OpenSSH on your system.
|
||||
|
||||
Damien Miller <djm@mindrot.org>
|
||||
|
||||
Miscellania -
|
||||
|
||||
This version of OpenSSH is based upon code retrieved from the OpenBSD CVS
|
||||
repository which in turn was based on the last free sample implementation
|
||||
released by Tatu Ylonen.
|
||||
|
||||
References -
|
||||
|
||||
[0] https://www.openssh.com/
|
||||
[1] https://man.openbsd.org/style.9
|
||||
|
||||
47
Agent-Windows/OGP64/usr/share/doc/openssh/README.dns
Normal file
47
Agent-Windows/OGP64/usr/share/doc/openssh/README.dns
Normal file
|
|
@ -0,0 +1,47 @@
|
|||
How to verify host keys using OpenSSH and DNS
|
||||
---------------------------------------------
|
||||
|
||||
OpenSSH contains support for verifying host keys using DNS as described
|
||||
in https://tools.ietf.org/html/rfc4255. The document contains very brief
|
||||
instructions on how to use this feature. Configuring DNS is out of the
|
||||
scope of this document.
|
||||
|
||||
|
||||
(1) Server: Generate and publish the DNS RR
|
||||
|
||||
To create a DNS resource record (RR) containing a fingerprint of the
|
||||
public host key, use the following command:
|
||||
|
||||
ssh-keygen -r hostname -f keyfile -g
|
||||
|
||||
where "hostname" is your fully qualified hostname and "keyfile" is the
|
||||
file containing the public host key file. If you have multiple keys,
|
||||
you should generate one RR for each key.
|
||||
|
||||
In the example above, ssh-keygen will print the fingerprint in a
|
||||
generic DNS RR format parsable by most modern name server
|
||||
implementations. If your nameserver has support for the SSHFP RR
|
||||
you can omit the -g flag and ssh-keygen will print a standard SSHFP RR.
|
||||
|
||||
To publish the fingerprint using the DNS you must add the generated RR
|
||||
to your DNS zone file and sign your zone.
|
||||
|
||||
|
||||
(2) Client: Enable ssh to verify host keys using DNS
|
||||
|
||||
To enable the ssh client to verify host keys using DNS, you have to
|
||||
add the following option to the ssh configuration file
|
||||
($HOME/.ssh/config or /etc/ssh/ssh_config):
|
||||
|
||||
VerifyHostKeyDNS yes
|
||||
|
||||
Upon connection the client will try to look up the fingerprint RR
|
||||
using DNS. If the fingerprint received from the DNS server matches
|
||||
the remote host key, the user will be notified.
|
||||
|
||||
|
||||
Jakob Schlyter
|
||||
Wesley Griffin
|
||||
|
||||
|
||||
$OpenBSD: README.dns,v 1.2 2003/10/14 19:43:23 jakob Exp $
|
||||
89
Agent-Windows/OGP64/usr/share/doc/openssh/README.md
Normal file
89
Agent-Windows/OGP64/usr/share/doc/openssh/README.md
Normal file
|
|
@ -0,0 +1,89 @@
|
|||
# Portable OpenSSH
|
||||
|
||||
[](../../actions/workflows/c-cpp.yml)
|
||||
[](../../actions/workflows/vm.yml)
|
||||
[](https://github.com/openssh/openssh-portable-selfhosted/actions/workflows/selfhosted.yml)
|
||||
[](../../actions/workflows/cifuzz.yml)
|
||||
[](https://issues.oss-fuzz.com/issues?q="Project:+openssh"+is:open)
|
||||
[](https://scan.coverity.com/projects/openssh-portable)
|
||||
|
||||
OpenSSH is a complete implementation of the SSH protocol (version 2) for secure remote login, command execution and file transfer. It includes a client ``ssh`` and server ``sshd``, file transfer utilities ``scp`` and ``sftp`` as well as tools for key generation (``ssh-keygen``), run-time key storage (``ssh-agent``) and a number of supporting programs.
|
||||
|
||||
This is a port of OpenBSD's [OpenSSH](https://openssh.com) to most Unix-like operating systems, including Linux, OS X and Cygwin. Portable OpenSSH polyfills OpenBSD APIs that are not available elsewhere, adds sshd sandboxing for more operating systems and includes support for OS-native authentication and auditing (e.g. using PAM).
|
||||
|
||||
## Documentation
|
||||
|
||||
The official documentation for OpenSSH are the man pages for each tool:
|
||||
|
||||
* [ssh(1)](https://man.openbsd.org/ssh.1)
|
||||
* [sshd(8)](https://man.openbsd.org/sshd.8)
|
||||
* [ssh-keygen(1)](https://man.openbsd.org/ssh-keygen.1)
|
||||
* [ssh-agent(1)](https://man.openbsd.org/ssh-agent.1)
|
||||
* [scp(1)](https://man.openbsd.org/scp.1)
|
||||
* [sftp(1)](https://man.openbsd.org/sftp.1)
|
||||
* [ssh-keyscan(8)](https://man.openbsd.org/ssh-keyscan.8)
|
||||
* [sftp-server(8)](https://man.openbsd.org/sftp-server.8)
|
||||
|
||||
## Stable Releases
|
||||
|
||||
Stable release tarballs are available from a number of [download mirrors](https://www.openssh.com/portable.html#downloads). We recommend the use of a stable release for most users. Please read the [release notes](https://www.openssh.com/releasenotes.html) for details of recent changes and potential incompatibilities.
|
||||
|
||||
## Building Portable OpenSSH
|
||||
|
||||
### Dependencies
|
||||
|
||||
Portable OpenSSH is built using autoconf and make. It requires a working C compiler, standard library and headers.
|
||||
|
||||
``libcrypto`` from one of [LibreSSL](https://www.libressl.org/), [OpenSSL](https://www.openssl.org), [AWS-LC](https://github.com/aws/aws-lc) or [BoringSSL](https://github.com/google/boringssl) may also be used. OpenSSH may be built without either of these, but the resulting binaries will have only a subset of the cryptographic algorithms normally available.
|
||||
|
||||
[zlib](https://www.zlib.net/) is optional; without it transport compression is not supported.
|
||||
|
||||
FIDO security token support needs [libfido2](https://github.com/Yubico/libfido2) and its dependencies and will be enabled automatically if they are found.
|
||||
|
||||
In addition, certain platforms and build-time options may require additional dependencies; see README.platform for details about your platform.
|
||||
|
||||
### Building a release
|
||||
|
||||
Release tarballs and release branches in git include a pre-built copy of the ``configure`` script and may be built using:
|
||||
|
||||
```
|
||||
tar zxvf openssh-X.YpZ.tar.gz
|
||||
cd openssh
|
||||
./configure # [options]
|
||||
make && make tests
|
||||
```
|
||||
|
||||
See the [Build-time Customisation](#build-time-customisation) section below for configure options. If you plan on installing OpenSSH to your system, then you will usually want to specify destination paths.
|
||||
|
||||
### Building from git
|
||||
|
||||
If building from the git master branch, you'll need [autoconf](https://www.gnu.org/software/autoconf/) installed to build the ``configure`` script. The following commands will check out and build portable OpenSSH from git:
|
||||
|
||||
```
|
||||
git clone https://github.com/openssh/openssh-portable # or https://anongit.mindrot.org/openssh.git
|
||||
cd openssh-portable
|
||||
autoreconf
|
||||
./configure
|
||||
make && make tests
|
||||
```
|
||||
|
||||
### Build-time Customisation
|
||||
|
||||
There are many build-time customisation options available. All Autoconf destination path flags (e.g. ``--prefix``) are supported (and are usually required if you want to install OpenSSH).
|
||||
|
||||
For a full list of available flags, run ``./configure --help`` but a few of the more frequently-used ones are described below. Some of these flags will require additional libraries and/or headers be installed.
|
||||
|
||||
Flag | Meaning
|
||||
--- | ---
|
||||
``--with-pam`` | Enable [PAM](https://en.wikipedia.org/wiki/Pluggable_authentication_module) support. [OpenPAM](https://www.openpam.org/), [Linux PAM](http://www.linux-pam.org/) and Solaris PAM are supported.
|
||||
``--with-libedit`` | Enable [libedit](https://www.thrysoee.dk/editline/) support for sftp.
|
||||
``--with-kerberos5`` | Enable Kerberos/GSSAPI support. Both [Heimdal](https://www.h5l.org/) and [MIT](https://web.mit.edu/kerberos/) Kerberos implementations are supported.
|
||||
``--with-selinux`` | Enable [SELinux](https://en.wikipedia.org/wiki/Security-Enhanced_Linux) support.
|
||||
|
||||
## Development
|
||||
|
||||
Portable OpenSSH development is discussed on the [openssh-unix-dev mailing list](https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev) ([archive mirror](https://marc.info/?l=openssh-unix-dev)). Bugs and feature requests are tracked on our [Bugzilla](https://bugzilla.mindrot.org/).
|
||||
|
||||
## Reporting bugs
|
||||
|
||||
_Non-security_ bugs may be reported to the developers via [Bugzilla](https://bugzilla.mindrot.org/) or via the mailing list above. Security bugs should be reported to [openssh@openssh.com](mailto:openssh.openssh.com).
|
||||
97
Agent-Windows/OGP64/usr/share/doc/openssh/README.platform
Normal file
97
Agent-Windows/OGP64/usr/share/doc/openssh/README.platform
Normal file
|
|
@ -0,0 +1,97 @@
|
|||
This file contains notes about OpenSSH on specific platforms.
|
||||
|
||||
AIX
|
||||
|
||||
Beginning with OpenSSH 3.8p1, sshd will honour an account's password
|
||||
expiry settings, where prior to that it did not. Because of this,
|
||||
it's possible for sites that have used OpenSSH's sshd exclusively to
|
||||
have accounts which have passwords expired longer than the inactive time
|
||||
(ie the "Weeks between password EXPIRATION and LOCKOUT" setting in SMIT
|
||||
or the maxexpired chuser attribute).
|
||||
|
||||
Accounts in this state must have their passwords reset manually by the
|
||||
administrator. As a precaution, it is recommended that the administrative
|
||||
passwords be reset before upgrading from OpenSSH <3.8.
|
||||
|
||||
As of OpenSSH 4.0p1, configure will attempt to detect if your version
|
||||
and maintenance level of AIX has a working getaddrinfo, and will use it
|
||||
if found. This will enable IPv6 support. If for some reason configure
|
||||
gets it wrong, or if you want to build binaries to work on earlier MLs
|
||||
than the build host then you can add "-DBROKEN_GETADDRINFO" to CFLAGS
|
||||
to force the previous IPv4-only behaviour.
|
||||
|
||||
IPv6 known to work: 5.1ML7 5.2ML2 5.2ML5
|
||||
IPv6 known broken: 4.3.3ML11 5.1ML4
|
||||
|
||||
If you wish to use dynamic libraries that aren't in the normal system
|
||||
locations (eg IBM's OpenSSL and zlib packages) then you will need to
|
||||
define the environment variable blibpath before running configure, eg
|
||||
|
||||
blibpath=/lib:/usr/lib:/opt/freeware/lib ./configure \
|
||||
--with-ssl-dir=/opt/freeware --with-zlib=/opt/freeware
|
||||
|
||||
If sshd is built with the WITH_AIXAUTHENTICATE option (which is enabled
|
||||
by default) then sshd checks that users are permitted via the
|
||||
loginrestrictions() function, in particular that the user has the
|
||||
"rlogin" attribute set. This check is not done for the root account,
|
||||
instead the PermitRootLogin setting in sshd_config is used.
|
||||
|
||||
If you are using the IBM compiler you probably want to use CC=xlc rather
|
||||
than the default of cc.
|
||||
|
||||
|
||||
Cygwin
|
||||
------
|
||||
To build on Cygwin, OpenSSH requires the following packages:
|
||||
gcc, gcc-mingw-core, mingw-runtime, binutils, make, openssl,
|
||||
openssl-devel, zlib, minres, minires-devel.
|
||||
|
||||
|
||||
Darwin and MacOS X
|
||||
------------------
|
||||
Darwin does not provide a tun(4) driver required for OpenSSH-based
|
||||
virtual private networks. The BSD manpage still exists, but the driver
|
||||
has been removed in recent releases of Darwin and MacOS X.
|
||||
|
||||
Tunnel support is known to work with Darwin 8 and MacOS X 10.4 in
|
||||
Point-to-Point (Layer 3) and Ethernet (Layer 2) mode using a third
|
||||
party driver. More information is available at:
|
||||
https://tuntaposx.sourceforge.net
|
||||
|
||||
Recent Darwin/MacOS X versions are likely unsupported.
|
||||
|
||||
Linux
|
||||
-----
|
||||
|
||||
Some Linux distributions (including Red Hat/Fedora/CentOS) include
|
||||
headers and library links in the -devel RPMs rather than the main
|
||||
binary RPMs. If you get an error about headers, or complaining about a
|
||||
missing prerequisite then you may need to install the equivalent
|
||||
development packages. On Redhat based distros these may be openssl-devel,
|
||||
zlib-devel and pam-devel, on Debian based distros these may be
|
||||
libssl-dev, libz-dev and libpam-dev.
|
||||
|
||||
|
||||
Solaris
|
||||
-------
|
||||
If you enable BSM auditing on Solaris, you need to update audit_event(4)
|
||||
for praudit(1m) to give sensible output. The following line needs to be
|
||||
added to /etc/security/audit_event:
|
||||
|
||||
32800:AUE_openssh:OpenSSH login:lo
|
||||
|
||||
The BSM audit event range available for third party TCB applications is
|
||||
32768 - 65535. Event number 32800 has been chosen for AUE_openssh.
|
||||
There is no official registry of 3rd party event numbers, so if this
|
||||
number is already in use on your system, you may change it at build time
|
||||
by configure'ing --with-cflags=-DAUE_openssh=32801 then rebuilding.
|
||||
|
||||
|
||||
Platforms using PAM
|
||||
-------------------
|
||||
As of OpenSSH 4.3p1, sshd will no longer check /etc/nologin itself when
|
||||
PAM is enabled. To maintain existing behaviour, pam_nologin should be
|
||||
added to sshd's session stack which will prevent users from starting shell
|
||||
sessions. Alternatively, pam_nologin can be added to either the auth or
|
||||
account stacks which will prevent authentication entirely, but will still
|
||||
return the output from pam_nologin to the client.
|
||||
51
Agent-Windows/OGP64/usr/share/doc/openssh/README.privsep
Normal file
51
Agent-Windows/OGP64/usr/share/doc/openssh/README.privsep
Normal file
|
|
@ -0,0 +1,51 @@
|
|||
Privilege separation, or privsep, is method in OpenSSH by which
|
||||
operations that require root privilege are performed by a separate
|
||||
privileged monitor process. Its purpose is to prevent privilege
|
||||
escalation by containing corruption to an unprivileged process.
|
||||
More information is available at:
|
||||
http://www.citi.umich.edu/u/provos/ssh/privsep.html
|
||||
|
||||
Privilege separation is now mandatory. During the pre-authentication
|
||||
phase sshd will chroot(2) to "/var/empty" and change its privileges to the
|
||||
"sshd" user and its primary group. sshd is a pseudo-account that should
|
||||
not be used by other daemons, and must be locked and should contain a
|
||||
"nologin" or invalid shell.
|
||||
|
||||
You should do something like the following to prepare the privsep
|
||||
preauth environment:
|
||||
|
||||
# mkdir /var/empty
|
||||
# chown root:sys /var/empty
|
||||
# chmod 755 /var/empty
|
||||
# groupadd sshd
|
||||
# useradd -g sshd -c 'sshd privsep' -d /var/empty -s /bin/false sshd
|
||||
|
||||
/var/empty should not contain any files.
|
||||
|
||||
configure supports the following options to change the default
|
||||
privsep user and chroot directory:
|
||||
|
||||
--with-privsep-path=xxx Path for privilege separation chroot
|
||||
--with-privsep-user=user Specify non-privileged user for privilege separation
|
||||
|
||||
PAM-enabled OpenSSH is known to function with privsep on AIX, FreeBSD,
|
||||
HP-UX (including Trusted Mode), Linux, NetBSD and Solaris.
|
||||
|
||||
On Cygwin, Tru64 Unix and OpenServer only the pre-authentication part
|
||||
of privsep is supported. Post-authentication privsep is disabled
|
||||
automatically (so you won't see the additional process mentioned below).
|
||||
|
||||
Note that for a normal interactive login with a shell, enabling privsep
|
||||
will require 1 additional process per login session.
|
||||
|
||||
Given the following process listing (from HP-UX):
|
||||
|
||||
UID PID PPID C STIME TTY TIME COMMAND
|
||||
root 1005 1 0 10:45:17 ? 0:08 /opt/openssh/sbin/sshd -u0
|
||||
root 6917 1005 0 15:19:16 ? 0:00 sshd: stevesk [priv]
|
||||
stevesk 6919 6917 0 15:19:17 ? 0:03 sshd: stevesk@2
|
||||
stevesk 6921 6919 0 15:19:17 pts/2 0:00 -bash
|
||||
|
||||
process 1005 is the sshd process listening for new connections.
|
||||
process 6917 is the privileged monitor process, 6919 is the user owned
|
||||
sshd process and 6921 is the shell process.
|
||||
132
Agent-Windows/OGP64/usr/share/doc/openssh/README.tun
Normal file
132
Agent-Windows/OGP64/usr/share/doc/openssh/README.tun
Normal file
|
|
@ -0,0 +1,132 @@
|
|||
How to use OpenSSH-based virtual private networks
|
||||
-------------------------------------------------
|
||||
|
||||
OpenSSH contains support for VPN tunneling using the tun(4) network
|
||||
tunnel pseudo-device which is available on most platforms, either for
|
||||
layer 2 or 3 traffic.
|
||||
|
||||
The following brief instructions on how to use this feature use
|
||||
a network configuration specific to the OpenBSD operating system.
|
||||
|
||||
(1) Server: Enable support for SSH tunneling
|
||||
|
||||
To enable the ssh server to accept tunnel requests from the client, you
|
||||
have to add the following option to the ssh server configuration file
|
||||
(/etc/ssh/sshd_config):
|
||||
|
||||
PermitTunnel yes
|
||||
|
||||
Restart the server or send the hangup signal (SIGHUP) to let the server
|
||||
reread it's configuration.
|
||||
|
||||
(2) Server: Restrict client access and assign the tunnel
|
||||
|
||||
The OpenSSH server simply uses the file /root/.ssh/authorized_keys to
|
||||
restrict the client to connect to a specified tunnel and to
|
||||
automatically start the related interface configuration command. These
|
||||
settings are optional but recommended:
|
||||
|
||||
tunnel="1",command="sh /etc/netstart tun1" ssh-rsa ... reyk@openbsd.org
|
||||
|
||||
(3) Client: Configure the local network tunnel interface
|
||||
|
||||
Use the hostname.if(5) interface-specific configuration file to set up
|
||||
the network tunnel configuration with OpenBSD. For example, use the
|
||||
following configuration in /etc/hostname.tun0 to set up the layer 3
|
||||
tunnel on the client:
|
||||
|
||||
inet 192.168.5.1 255.255.255.252 192.168.5.2
|
||||
|
||||
OpenBSD also supports layer 2 tunneling over the tun device by adding
|
||||
the link0 flag:
|
||||
|
||||
inet 192.168.1.78 255.255.255.0 192.168.1.255 link0
|
||||
|
||||
Layer 2 tunnels can be used in combination with an Ethernet bridge(4)
|
||||
interface, like the following example for /etc/bridgename.bridge0:
|
||||
|
||||
add tun0
|
||||
add sis0
|
||||
up
|
||||
|
||||
(4) Client: Configure the OpenSSH client
|
||||
|
||||
To establish tunnel forwarding for connections to a specified
|
||||
remote host by default, use the following ssh client configuration for
|
||||
the privileged user (in /root/.ssh/config):
|
||||
|
||||
Host sshgateway
|
||||
Tunnel yes
|
||||
TunnelDevice 0:any
|
||||
PermitLocalCommand yes
|
||||
LocalCommand sh /etc/netstart tun0
|
||||
|
||||
A more complicated configuration is possible to establish a tunnel to
|
||||
a remote host which is not directly accessible by the client.
|
||||
The following example describes a client configuration to connect to
|
||||
the remote host over two ssh hops in between. It uses the OpenSSH
|
||||
ProxyCommand in combination with the nc(1) program to forward the final
|
||||
ssh tunnel destination over multiple ssh sessions.
|
||||
|
||||
Host access.somewhere.net
|
||||
User puffy
|
||||
Host dmzgw
|
||||
User puffy
|
||||
ProxyCommand ssh access.somewhere.net nc dmzgw 22
|
||||
Host sshgateway
|
||||
Tunnel Ethernet
|
||||
TunnelDevice 0:any
|
||||
PermitLocalCommand yes
|
||||
LocalCommand sh /etc/netstart tun0
|
||||
ProxyCommand ssh dmzgw nc sshgateway 22
|
||||
|
||||
The following network plan illustrates the previous configuration in
|
||||
combination with layer 2 tunneling and Ethernet bridging.
|
||||
|
||||
+--------+ ( ) +----------------------+
|
||||
| Client |------( Internet )-----| access.somewhere.net |
|
||||
+--------+ ( ) +----------------------+
|
||||
: 192.168.1.78 |
|
||||
:............................. +-------+
|
||||
Forwarded ssh connection : | dmzgw |
|
||||
Layer 2 tunnel : +-------+
|
||||
: |
|
||||
: |
|
||||
: +------------+
|
||||
:......| sshgateway |
|
||||
| +------------+
|
||||
--- real connection Bridge -> | +----------+
|
||||
... "virtual connection" [ X ]--------| somehost |
|
||||
[X] switch +----------+
|
||||
192.168.1.25
|
||||
|
||||
(5) Client: Connect to the server and establish the tunnel
|
||||
|
||||
Finally connect to the OpenSSH server to establish the tunnel by using
|
||||
the following command:
|
||||
|
||||
ssh sshgateway
|
||||
|
||||
It is also possible to tell the client to fork into the background after
|
||||
the connection has been successfully established:
|
||||
|
||||
ssh -f sshgateway true
|
||||
|
||||
Without the ssh configuration done in step (4), it is also possible
|
||||
to use the following command lines:
|
||||
|
||||
ssh -fw 0:1 sshgateway true
|
||||
ifconfig tun0 192.168.5.1 192.168.5.2 netmask 255.255.255.252
|
||||
|
||||
Using OpenSSH tunnel forwarding is a simple way to establish secure
|
||||
and ad hoc virtual private networks. Possible fields of application
|
||||
could be wireless networks or administrative VPN tunnels.
|
||||
|
||||
Nevertheless, ssh tunneling requires some packet header overhead and
|
||||
runs on top of TCP. It is still suggested to use the IP Security
|
||||
Protocol (IPSec) for robust and permanent VPN connections and to
|
||||
interconnect corporate networks.
|
||||
|
||||
Reyk Floeter
|
||||
|
||||
$OpenBSD: README.tun,v 1.4 2006/03/28 00:12:31 deraadt Exp $
|
||||
80
Agent-Windows/OGP64/usr/share/doc/openssh/TODO
Normal file
80
Agent-Windows/OGP64/usr/share/doc/openssh/TODO
Normal file
|
|
@ -0,0 +1,80 @@
|
|||
Documentation:
|
||||
|
||||
- Update the docs
|
||||
- Update README
|
||||
- Update INSTALL
|
||||
- Merge INSTALL & README.privsep
|
||||
|
||||
- Install FAQ?
|
||||
|
||||
- General FAQ on S/Key, TIS, RSA, RSA2, etc and suggestions on when it
|
||||
would be best to use them.
|
||||
|
||||
- Create a Documentation/ directory?
|
||||
|
||||
Programming:
|
||||
|
||||
- Grep for 'XXX' comments and fix
|
||||
|
||||
- Link order is incorrect for some systems using Kerberos 4 and AFS. Result
|
||||
is multiple inclusion of DES symbols. Holger Trapp
|
||||
<holger.trapp@hrz.tu-chemnitz.de> reports that changing the configure
|
||||
generated link order from:
|
||||
-lresolv -lkrb -lz -lnsl -lutil -lkafs -lkrb -ldes -lcrypto
|
||||
to:
|
||||
-lresolv -lkrb -lz -lnsl -lutil -lcrypto -lkafs -lkrb -ldes
|
||||
fixing the problem.
|
||||
|
||||
- Write a test program that calls stat() to search for EGD/PRNGd socket
|
||||
rather than use the (non-portable) "test -S".
|
||||
|
||||
- More platforms for for setproctitle() emulation (testing needed)
|
||||
|
||||
- Improve PAM ChallengeResponseAuthentication
|
||||
- Informational messages
|
||||
- Use different PAM service name for kbdint vs regular auth (suggest from
|
||||
Solar Designer)
|
||||
- Ability to select which ChallengeResponseAuthentications may be used
|
||||
and order to try them in e.g. "ChallengeResponseAuthentication pam"
|
||||
|
||||
- Complete Tru64 SIA support
|
||||
- It looks like we could merge it into the password auth code to cut down
|
||||
on diff size. Maybe PAM password auth too?
|
||||
|
||||
- Finish integrating kernel-level auditing code for IRIX and SOLARIS
|
||||
(Gilbert.r.loomis@saic.com)
|
||||
|
||||
- 64-bit builds on HP-UX 11.X (stevesk@pobox.com):
|
||||
- utmp/wtmp get corrupted (something in loginrec?)
|
||||
- can't build with PAM (no 64-bit libpam yet)
|
||||
|
||||
Clean up configure/makefiles:
|
||||
- Clean up configure.ac - There are a few double #defined variables
|
||||
left to do. HAVE_LOGIN is one of them. Consider NOT looking for
|
||||
information in wtmpx or utmpx or any of that stuff if it's not detected
|
||||
from the start
|
||||
|
||||
- Replace the whole u_intXX_t evilness in acconfig.h with something better???
|
||||
- Do it in configure.ac
|
||||
|
||||
- Consider splitting the u_intXX_t test for sys/bitype.h into separate test
|
||||
to allow people to (right/wrongfully) link against Bind directly.
|
||||
|
||||
- Consider splitting configure.ac into separate files which do logically
|
||||
similar tests. E.g move all the type detection stuff into one file,
|
||||
entropy related stuff into another.
|
||||
|
||||
Packaging:
|
||||
- HP-UX: Provide DEPOT package scripts.
|
||||
(gilbert.r.loomis@saic.com)
|
||||
|
||||
PrivSep Issues:
|
||||
- PAM
|
||||
+ See above PAM notes
|
||||
- AIX
|
||||
+ usrinfo() does not set TTY, but only required for legacy systems. Works
|
||||
with PrivSep.
|
||||
- OSF
|
||||
+ SIA is broken
|
||||
- Cygwin
|
||||
+ Privsep for Pre-auth only (no fd passing)
|
||||
Loading…
Add table
Add a link
Reference in a new issue