summaryrefslogtreecommitdiffstats
path: root/usr.bin/ssh/sshd_config.5 (follow)
Commit message (Collapse)AuthorAgeFilesLines
* allow key options (command="..." and friends) in AuthorizedPrincipals;djm2010-06-291-3/+12
| | | | ok markus@
* expose some more sshd_config options inside Match blocks:djm2010-06-221-2/+6
| | | | | | AuthorizedKeysFile AuthorizedPrincipalsFile HostbasedUsesNameFromPacketOnly PermitTunnel bz#1764; feedback from imorgan AT nas.nasa.gov; ok dtucker@
* tweak previous;jmc2010-05-071-3/+2
|
* add some optional indirection to matching of principal names listeddjm2010-05-071-2/+39
| | | | | | | | | | | | | | | | | | | | | in certificates. Currently, a certificate must include the a user's name to be accepted for authentication. This change adds the ability to specify a list of certificate principal names that are acceptable. When authenticating using a CA trusted through ~/.ssh/authorized_keys, this adds a new principals="name1[,name2,...]" key option. For CAs listed through sshd_config's TrustedCAKeys option, a new config option "AuthorizedPrincipalsFile" specifies a per-user file containing the list of acceptable names. If either option is absent, the current behaviour of requiring the username to appear in principals continues to apply. These options are useful for role accounts, disjoint account namespaces and "user@realm"-style naming policies in certificates. feedback and ok markus@
* missing word; spotted by jmc@djm2010-03-041-2/+2
|
* tweak previous;jmc2010-03-041-3/+3
|
* Add a TrustedUserCAKeys option to sshd_config to specify CA keys thatdjm2010-03-041-2/+23
| | | | | | | | | | | are trusted to authenticate users (in addition than doing it per-user in authorized_keys). Add a RevokedKeys option to sshd_config and a @revoked marker to known_hosts to allow keys to me revoked and banned for user or host authentication. feedback and ok markus@
* Add support for certificate key types for users and hosts.djm2010-02-261-2/+10
| | | | | | | | | | | | | | | | | | | | | | | | OpenSSH certificate key types are not X.509 certificates, but a much simpler format that encodes a public key, identity information and some validity constraints and signs it with a CA key. CA keys are regular SSH keys. This certificate style avoids the attack surface of X.509 certificates and is very easy to deploy. Certified host keys allow automatic acceptance of new host keys when a CA certificate is marked as trusted in ~/.ssh/known_hosts. see VERIFYING HOST KEYS in ssh(1) for details. Certified user keys allow authentication of users when the signing CA key is marked as trusted in authorized_keys. See "AUTHORIZED_KEYS FILE FORMAT" in sshd(8) for details. Certificates are minted using ssh-keygen(1), documentation is in the "CERTIFICATES" section of that manpage. Documentation on the format of certificates is in the file PROTOCOL.certkeys feedback and ok markus@
* Remove RoutingDomain from ssh since it's now not needed. It can be replaceddtucker2010-01-091-5/+2
| | | | | | | | | | | | | with "route exec" or "nc -V" as a proxycommand. "route exec" also ensures that trafic such as DNS lookups stays withing the specified routingdomain. For example (from reyk): # route -T 2 exec /usr/sbin/sshd or inherited from the parent process $ route -T 2 exec sh $ ssh 10.1.2.3 ok deraadt@ markus@ stevesk@ reyk@
* sort previous;jmc2009-12-291-4/+4
|
* Rename RDomain config option to RoutingDomain to be more clear andstevesk2009-12-291-3/+3
| | | | | | | | | consistent with other options. NOTE: if you currently use RDomain in the ssh client or server config, or ssh/sshd -o, you must update to use RoutingDomain. ok markus@ djm@
* try to clarify ChrootDirectory pathname argument a bit; resulting fromstevesk2009-12-191-5/+5
| | | | a question on openssh-unix-dev. ok jmc@
* clarify that StrictModes does not apply to ChrootDirectory. Permissionsdjm2009-11-101-2/+5
| | | | and ownership are always checked when chrooting. bz#1532
* tweak previous;jmc2009-10-281-4/+4
|
* Allow to set the rdomain in ssh/sftp/scp/sshd and ssh-keyscan.reyk2009-10-281-2/+5
| | | | ok markus@
* some tweaks now that protocol 1 is not offered by default; ok markusjmc2009-10-081-2/+2
|
* disable protocol 1 by default (after a transition period of about 10 years)markus2009-10-081-3/+3
| | | | ok deraadt
* Add PubkeyAuthentication to the list allowed in a Match block (bz #1577)dtucker2009-08-161-2/+3
|
* clarify we cd to user's home after chroot; ok markus@ onstevesk2009-04-211-2/+5
| | | | earlier version; tweaks and ok jmc@
* tweak previous; ok steveskjmc2009-04-181-8/+5
|
* clarify that even internal-sftp needs /dev/log for logging to work; okstevesk2009-04-171-3/+9
| | | | markus@
* fix possessive; ok djm@stevesk2009-04-131-3/+3
|
* missing perioddjm2009-02-221-2/+2
|
* don't advertise experimental optionsdjm2009-02-221-16/+4
|
* sync list of preferred ciphers; ok djm@naddy2009-01-241-5/+5
|
* add AllowAgentForwarding to available Match keywords listokan2008-12-301-2/+3
| | | | ok djm
* Add support for an experimental zero-knowledge password authenticationdjm2008-11-041-3/+15
| | | | | | | | | | | | | | | | method using the J-PAKE protocol described in F. Hao, P. Ryan, "Password Authenticated Key Exchange by Juggling", 16th Workshop on Security Protocols, Cambridge, April 2008. This method allows password-based authentication without exposing the password to the server. Instead, the client and server exchange cryptographic proofs to demonstrate of knowledge of the password while revealing nothing useful to an attacker or compromised endpoint. This is experimental, work-in-progress code and is presently compiled-time disabled (turn on -DJPAKE in Makefile.inc). "just commit it. It isn't too intrusive." deraadt@
* support setting PermitEmptyPasswords in a Match blockdjm2008-10-091-2/+3
| | | | requested in PR3891; ok dtucker@
* increase default size of ssh protocol 1 ephemeral key from 768 to 1024djm2008-07-021-3/+3
| | | | bits; prodded by & ok dtucker@ ok deraadt@
* Allow MaxAuthTries within a Match block. ok djm@dtucker2008-06-151-1/+2
|
* MaxSessions is allowed in a Match block toodtucker2008-06-151-2/+3
|
* tweak previous;jmc2008-06-101-4/+5
|
* better reference for pattern-listdjm2008-06-101-3/+3
|
* support CIDR address matching in sshd_config "Match address" blocks, withdjm2008-06-101-2/+24
| | | | | | | | | | | | full support for negation and fall-back to classic wildcard matching. For example: Match address 192.0.2.0/24,3ffe:ffff::/32,!10.* PasswordAuthentication yes addrmatch.c code mostly lifted from flowd's addr.c feedback and ok dtucker@
* Make the maximum number of sessions run-time controllable viadjm2008-05-081-2/+5
| | | | | | | | | | | | | | | | | a sshd_config MaxSessions knob. This is useful for disabling login/shell/subsystem access while leaving port-forwarding working (MaxSessions 0), disabling connection multiplexing (MaxSessions 1) or simply increasing the number of allows multiplexed sessions. Because some bozos are sure to configure MaxSessions in excess of the number of available file descriptors in sshd (which, at peak, might be as many as 9*MaxSessions), audit sshd to ensure that it doesn't leak fds on error paths, and make it fail gracefully on out-of-fd conditions - sending channel errors instead of than exiting with fatal(). bz#1090; MaxSessions config bits and manpage from junyer AT gmail.com ok markus@
* sort;jmc2008-05-071-10/+10
|
* Enable the AllowAgentForwarding option in sshd_config (global and matchpyr2008-05-071-2/+11
| | | | | | | | | | | context), to specify if agents should be permitted on the server. As the man page states: ``Note that disabling Agent forwarding does not improve security unless users are also denied shell access, as they can always install their own forwarders.'' ok djm@, ok and a mild frown markus@
* HostbasedAuthentication is supported under Match toodjm2008-04-051-3/+4
|
* oops, some unrelated stuff crept into that commit - backout.djm2008-04-041-34/+1
| | | | spotted by jmc@
* ChrootDirectory is supported in Match blocks (in fact, it is most usefuldjm2008-04-041-2/+36
| | | | there). Spotted by Minstrel AT minstrel.org.uk
* ignore ~/.ssh/rc if a sshd_config ForceCommand is specified;djm2008-03-251-3/+5
| | | | from dtucker@ ok deraadt@ djm@
* bump Mdocdate for pages committed in "febuary", necessary becausejmc2008-02-111-2/+2
| | | | of a typo in rcs.c;
* mantion that "internal-sftp" is useful with ForceCommand toodjm2008-02-101-2/+7
|
* missing `)';jmc2008-02-091-3/+3
|
* add sshd_config ChrootDirectory option to chroot(2) users to a directory anddjm2008-02-081-2/+52
| | | | | tweak internal sftp server to work with it (no special files in chroot required). ok markus@
* Allow PermitRootLogin in a Match block. Allows for, eg, permitting rootdtucker2008-01-011-2/+3
| | | | only from the local network. ok markus@, man page bit ok jmc@
* Support "Banner=none" to disable displaying of the pre-login banner;djm2007-08-231-4/+5
| | | | ok dtucker@ deraadt@
* oops, here too: put the MAC list into a display, like we do forjmc2007-06-081-3/+6
| | | | ciphers, since groff has trouble with wide lines;
* Add a new MAC algorithm for data integrity, UMAC-64 (not default yet, mustpvalchev2007-06-071-3/+3
| | | | | | | | | | specify umac-64@openssh.com). Provides about 20% end-to-end speedup compared to hmac-md5. Represents a different approach to message authentication to that of HMAC that may be beneficial if HMAC based on one of its underlying hash algorithms is found to be vulnerable to a new attack. http://www.ietf.org/rfc/rfc4418.txt in conjunction with and OK djm@
* convert to new .Dd format;jmc2007-05-311-2/+2
|
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.