Skip to content

Update sshd-pfs_config #57

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
rhyven wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Update sshd-pfs_config #57

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
52be890
Update sshd-pfs_config
rhyven Mar 9, 2015
91164b7
Additional comments, and some tweaks
rhyven Aug 21, 2015
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
50 changes: 39 additions & 11 deletions configs/sshd/sshd-pfs_config
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,11 +1,39 @@
# Specifies the ciphers allowed for protocol version 2.
# The default is: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,
# arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,
# aes256-cbc,arcfour
Ciphers aes256-ctr

# Specifies the available MAC (message authentication code) algorithms.
# The default is: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,
# hmac-sha1-96,hmac-md5-96,hmac-sha2-256,hmac-sha256-96,hmac-sha2-512,
# hmac-sha2-512-96
MACs hmac-sha2-512
# COMPATIBILITY
# The below options are compatible with OpenSSH 6.6+, PuTTY 0.64+, and AbsoluteTelnet 9.84+ (RC10 at 2015-03-09)

# Specify strong key exchange algorithms; preferrably curve25519, but allow DHG-SHA256 for compatibility
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256

# Specify strong ciphers: chacha or aes256-GCM for authenticated encryption; aes256-CTR for compatibility
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes256-ctr

# Specify strong MAC's, preferring Encrypt-then-MAC methods; strong SHA2 for compatibility
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512,hmac-sha2-256

# Restrict incoming connections to authenticate with Pubkey authentication only
# Uncomment once you've created and tested your public & private keys
# PasswordAuthentication no

# Only allow members of the ssh-user group to connect to this server
# Uncomment once you've created an ssh-user group and added expected users to the group
# AllowGroups ssh-user

# Limit the grace time for logins to as short as possible in your situation.
# For fast connections & pubkey authentication, this can go down to ~5 seconds
# Warning: a low grace time can make slow connections timeout before the connection is completed
LoginGraceTime 30

# Prevent the root user from accessing SSH.
PermitRootLogin no

# Disable SSHv1
Protocol 2

# Make sure that file permissions for private & public key files are safe
StrictModes yes

# Prevent privilege escalation - keeps any corruption within an unprivileged processes
UsePrivilegeSeparation yes
Copy link
Copy Markdown

@fmarier fmarier Jun 21, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A better value for this setting is sandbox. Here's the description from the manpage:

If UsePrivilegeSeparation is set to “sandbox” then the pre-authentication unprivileged process is subject to additional restrictions.

(via https://wiki.mozilla.org/Security/Guidelines/OpenSSH)

Copy link
Copy Markdown
Author

@rhyven rhyven Aug 21, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@fmarier - Thanks François, I didn't know about the sandbox setting!

Copy link
Copy Markdown
Author

@rhyven rhyven Aug 21, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@GigabyteProductions - Just to reduce the amount of time the system is listening to an unauthenticated user; I was coming from a viewpoint of "minimum possible access", and didn't see the point in giving people a whole 120 seconds of airtime. There may be no security value in it, but there might be a new 0-day at some point or something.


# PAM enables ChallengeResponseAuthentication and PasswordAuthentication; disable to leave only Pubkey enabled
UsePAM no