Top 20 OpenSSH Server Best Security Practices

Top 20 OpenSSH Server Best Security Practices
7/9/12 7:23 PM
About
Forum
Howtos & FAQs
Low graphics
Shell Scripts
RSS/Feed
nixcraft - insight into linux admin work

by Vivek Gite on July 24, 2009 117 comments Last updated December 5, 2009
OpenSSH is the implementation of the SSH protocol. OpenSSH is recommended for remote login, making backups, remote file transfer via
scp or sftp, and much more. SSH is perfect to keep confidentiality and integrity for data exchanged between two networks and systems.
However, the main advantage is server authentication, through the use of public key cryptography. From time to time there are rumors about
OpenSSH zero day exploit. Here are a few things you need to tweak in order to improve OpenSSH server security.
Default Config Files and SSH Port

/etc/ssh/sshd_config - OpenSSH server configuration file.
/etc/ssh/ssh_config - OpenSSH client configuration file.
~/.ssh/ - Users ssh configuration directory.
~/.ssh/authorized_keys or ~/.ssh/authorized_keys - Lists the public keys (RSA or DSA) that can be used to log into the users account
/etc/nologin - If this file exists, sshd refuses to let anyone except root log in.
/etc/hosts.allow and /etc/hosts.deny : Access controls lists that should be enforced by tcp-wrappers are defined here.
SSH default port : TCP 22
SSH Session in Action
#1: Disable OpenSSH Server

Workstations and laptop can work without OpenSSH server. If you need not to provide the remote login and file transfer capabilities of SSH, disable and remove the SSHD
server. CentOS / RHEL / Fedora Linux user can disable and remove openssh-server with yum command:
# chkconfig sshd off
# yum erase openssh-server
Debian / Ubuntu Linux user can disable and remove the same with apt-get command:
# apt-get remove openssh-server
You may need to update your iptables script to remove ssh exception rule. Under CentOS / RHEL / Fedora edit the files /etc/sysconfig/iptables and /etc/sysconfig/ip6tables.
Once done restart iptables service:
# service iptables restart
# service ip6tables restart
#2: Only Use SSH Protocol 2

SSH protocol version 1 (SSH-1) has man-in-the-middle attacks problems and security vulnerabilities. SSH-1 is obsolete and should be avoided at all cost. Open
sshd_config file and make sure the following line exists:
1. Protocol 2
http://www.cyberciti.biz/tips/linux-unix-bsd-openssh-server-best-practices.html
Page 1 of 10
7/9/12 7:23 PM
#3: Limit Users' SSH Access

By default all systems user can login via SSH using their password or public key. Sometime you create UNIX / Linux user account for ftp or email purpose. However,
those user can login to system using ssh. They will have full access to system tools including compilers and scripting languages such as Perl, Python which can open
network ports and do many other fancy things. One of my client has really outdated php script and an attacker was able to create a new account on the system via a php
script. However, attacker failed to get into box via ssh because it wasn't in AllowUsers.
Only allow root, vivek and jerry user to use the system via SSH, add the following to sshd_config:
1. AllowUsers root vivek jerry
Alternatively, you can allow all users to login via SSH but deny only a few users, with the following line:
1. DenyUsers saroj anjali foo
You can also configure Linux PAM allows or deny login via the sshd server. You can allow list of group name to access or deny access to the ssh.
#4: Configure Idle Log Out Timeout Interval

User can login to server via ssh and you can set an idel timeout interval to avoid unattended ssh session. Open sshd_config and make sure following values are configured:
1. ClientAliveInterval 300
2. ClientAliveCountMax 0
You are setting an idle timeout interval in seconds (300 secs = 5 minutes). After this interval has passed, the idle user will be automatically kicked out (read as logged out).
See how to automatically log BASH / TCSH / SSH users out after a period of inactivity for more details.
#5: Disable .rhosts Files

Don't read the user's ~/.rhosts and ~/.shosts files. Update sshd_config with the following settings:
1. IgnoreRhosts yes
SSH can emulate the behavior of the obsolete rsh command, just disable insecure access via RSH.
#6: Disable Host-Based Authentication

To disable host-based authentication, update sshd_config with the following option:
1. HostbasedAuthentication no
#7: Disable root Login via SSH

There is no need to login as root via ssh over a network. Normal users can use su or sudo (recommended) to gain root level access. This also make sure you get full
auditing information about who ran privileged commands on the system via sudo. To disable root login via SSH, update sshd_config with the following line:
1. PermitRootLogin no
However, bob made excellent point:
Saying "don't login as root" is h******t. It stems from the days when people sniffed the first packets of sessions so logging in as yourself and su-ing decreased
the chance an attacker would see the root pw, and decreast the chance you got spoofed as to your telnet host target, You'd get your password spoofed but not
root's pw. Gimme a break. this is 2005 - We have ssh, used properly it's secure. used improperly none of this 1989 will make a damn bit of difference. -Bob
#8: Enable a Warning Banner

Set a warning banner by updating sshd_config with the following line:
1. Banner /etc/issue
Sample /etc/issue file:
---------------------------------------------------------------------------------------------You are accessing a XYZ Government (XYZG) Information System (IS) that is provided for authorized use only.
By using this IS (which includes any device attached to this IS), you consent to the following conditions:
+ The XYZG routinely intercepts and monitors communications on this IS for purposes including, but not limited to,
penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM),
law enforcement (LE), and counterintelligence (CI) investigations.
+ At any time, the XYZG may inspect and seize data stored on this IS.
+ Communications using, or data stored on, this IS are not private, are subject to routine monitoring,
interception, and search, and may be disclosed or used for any XYZG authorized purpose.
+ This IS includes security measures (e.g., authentication and access controls) to protect XYZG interests--not
for your personal benefit or privacy.
+ Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching
or monitoring of the content of privileged communications, or work product, related to personal representation
or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work
product are private and confidential. See User Agreement for details.
----------------------------------------------------------------------------------------------
Above is standard sample, consult your legal team for exact user agreement and legal notice details.
Page 2 of 10
7/9/12 7:23 PM
#8: Firewall SSH Port # 22

You need to firewall ssh port # 22 by updating iptables or pf firewall configurations. Usually, OpenSSH server must only accept connections from your LAN or other
remote WAN sites only.
Netfilter (Iptables) Configuration

Update /etc/sysconfig/iptables (Redhat and friends specific file) to accept connection only from 192.168.1.0/24 and 202.54.1.5/29, enter:
1. -A RH-Firewall-1-INPUT -s 192.168.1.0/24 -m state --state NEW -p tcp --dport 22 -j ACCEPT
2. -A RH-Firewall-1-INPUT -s 202.54.1.5/29 -m state --state NEW -p tcp --dport 22 -j ACCEPT
If you've dual stacked sshd with IPv6, edit /etc/sysconfig/ip6tables (Redhat and friends specific file), enter:
1.
-A RH-Firewall-1-INPUT -s ipv6network::/ipv6mask -m tcp -p tcp --dport 22 -j ACCEPT
Replace ipv6network::/ipv6mask with actual IPv6 ranges.
*BSD PF Firewall Configuration

If you are using PF firewall update /etc/pf.conf as follows:
pass in on $ext_if inet proto tcp from {192.168.1.0/24, 202.54.1.5/29} to $ssh_server_ip port ssh flags S/SA synproxy state
#9: Change SSH Port and Limit IP Binding

By default SSH listen to all available interfaces and IP address on the system. Limit ssh port binding and change ssh port (by default brute forcing scripts only try to
connects to port # 22). To bind to 192.168.1.5 and 202.54.1.5 IPs and to port 300, add or correct the following line:
1. Port 300
2. ListenAddress 192.168.1.5
3. ListenAddress 202.54.1.5
A better approach to use proactive approaches scripts such as fail2ban or denyhosts (see below).
#10: Use Strong SSH Passwords and Passphrase

It cannot be stressed enough how important it is to use strong user passwords and passphrase for your keys. Brute force attack works because you use dictionary based
passwords. You can force users to avoid passwords against a dictionary attack and use john the ripper tool to find out existing weak passwords. Here is a sample random
password generator (put in your ~/.bashrc):
1. genpasswd() {
2.
local l=$1
3.
[ "$l" == "" ] && l=20
4.
tr -dc A-Za-z0-9_ < /dev/urandom | head -c ${l} | xargs
5. }
Run it:
genpasswd 16
Output:
uw8CnDVMwC6vOKgW
#11: Use Public Key Based Authentication

Use public/private key pair with password protection for the private key. See how to use RSA and DSA key based authentication. Never ever use passphrase free key
(passphrase key less) login.
#12: Use Keychain Based Authentication

keychain is a special bash script designed to make key-based authentication incredibly convenient and flexible. It offers various security benefits over passphrase-free keys.
See how to setup and use keychain software.
#13: Chroot SSHD (Lock Down Users To Their Home Directories)

By default users are allowed to browse the server directories such as /etc/, /bin and so on. You can protect ssh, using os based chroot or use special tools such as rssh. With
the release of OpenSSH 4.8p1 or 4.9p1, you no longer have to rely on third-party hacks such as rssh or complicated chroot(1) setups to lock users to their home directories.
See this blog post about new ChrootDirectory directive to lock down users to their home directories.
#14: Use TCP Wrappers

TCP Wrapper is a host-based Networking ACL system, used to filter network access to Internet. OpenSSH does supports TCP wrappers. Just update your /etc/hosts.allow
file as follows to allow SSH only from 192.168.1.2 172.16.23.12 :
sshd : 192.168.1.2 172.16.23.12
See this FAQ about setting and using TCP wrappers under Linux / Mac OS X and UNIX like operating systems.
Page 3 of 10
7/9/12 7:23 PM
#15: Disable Empty Passwords

You need to explicitly disallow remote login from accounts with empty passwords, update sshd_config with the following line:
1. PermitEmptyPasswords no
#16: Thwart SSH Crackers (Brute Force Attack)

Brute force is a method of defeating a cryptographic scheme by trying a large number of possibilities using a single or distributed computer network. To prevents brute
force attacks against SSH, use the following softwares:
DenyHosts is a Python based security tool for SSH servers. It is intended to prevent brute force attacks on SSH servers by monitoring invalid login attempts in the
authentication log and blocking the originating IP addresses.
Explains how to setup DenyHosts under RHEL / Fedora and CentOS Linux.
Fail2ban is a similar program that prevents brute force attacks against SSH.
security/sshguard-pf protect hosts from brute force attacks against ssh and other services using pf.
security/sshguard-ipfw protect hosts from brute force attacks against ssh and other services using ipfw.
security/sshguard-ipfilter protect hosts from brute force attacks against ssh and other services using ipfilter.
security/sshblock block abusive SSH login attempts.
security/sshit checks for SSH/FTP bruteforce and blocks given IPs.
BlockHosts Automatic blocking of abusive IP hosts.
Blacklist Get rid of those bruteforce attempts.
Brute Force Detection A modular shell script for parsing application logs and checking for authentication failures. It does this using a rules system where application
specific options are stored including regular expressions for each unique auth format.
IPQ BDB filter May be considered as a fail2ban lite.
#17: Rate-limit Incoming Port # 22 Connections

Both netfilter and pf provides rate-limit option to perform simple throttling on incoming connections on port # 22.
Iptables Example
The following example will drop incoming connections which make more than 5 connection attempts upon port 22 within 60 seconds:
1.
2.
3.
4.
5.
6.
#!/bin/bash
inet_if=eth1
ssh_port=22
$IPT -I INPUT -p tcp --dport ${ssh_port} -i ${inet_if} -m state --state NEW -m recent
$IPT -I INPUT -p tcp --dport ${ssh_port} -i ${inet_if} -m state --state NEW -m recent
--set
--update --seconds 60 --hitco
Call above script from your iptables scripts. Another config option:
1.
2.
3.
4.
5.
$IPT -A INPUT -i ${inet_if} -p tcp --dport ${ssh_port} -m state --state NEW -m limit --limit 3/min --limit-burst
$IPT -A INPUT -i ${inet_if} -p tcp --dport ${ssh_port} -m state --state ESTABLISHED -j ACCEPT
$IPT -A OUTPUT -o ${inet_if} -p tcp --sport ${ssh_port} -m state --state ESTABLISHED -j ACCEPT
# another one line example
# $IPT -A INPUT -i ${inet_if} -m state --state NEW,ESTABLISHED,RELATED -p tcp --dport 22 -m limit --limit 5/minute -
See iptables man page for more details.
*BSD PF Example
The following will limits the maximum number of connections per source to 20 and rate limit the number of connections to 15 in a 5 second span. If anyone breaks our
rules add them to our abusive_ips table and block them for making any further connections. Finally, flush keyword kills all states created by the matching rule which
originate from the host which exceeds these limits.
1.
2.
3.
4.
sshd_server_ip="202.54.1.5"
table <abusive_ips> persist
block in quick from <abusive_ips>
pass in on $ext_if proto tcp to $sshd_server_ip port ssh flags S/SA keep state (max-src-conn 20, max-src-conn-rate
#18: Use Port Knocking

Port knocking is a method of externally opening ports on a firewall by generating a connection attempt on a set of prespecified closed ports. Once a correct sequence of
connection attempts is received, the firewall rules are dynamically modified to allow the host which sent the connection attempts to connect over specific port(s). A sample
port Knocking example for ssh using iptables:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
$IPT -N stage1
$IPT -A stage1 -m recent --remove --name knock
$IPT -A stage1 -p tcp --dport 3456 -m recent --set --name knock2
$IPT -N stage2
$IPT -A stage2 -m recent --remove --name knock2
$IPT -A stage2 -p tcp --dport 2345 -m recent --set --name heaven
$IPT -N door
$IPT -A door -m recent --rcheck --seconds 5 --name knock2 -j stage2
$IPT -A door -m recent --rcheck --seconds 5 --name knock -j stage1
Page 4 of 10
12.
13.
14.
15.
16.
7/9/12 7:23 PM
$IPT -A door -p tcp --dport 1234 -m recent --set --name knock

$IPT -A INPUT -m --state ESTABLISHED,RELATED -j ACCEPT
$IPT -A INPUT -p tcp --dport 22 -m recent --rcheck --seconds 5 --name heaven -j ACCEPT
$IPT -A INPUT -p tcp --syn -j doo
fwknop is an implementation that combines port knocking and passive OS fingerprinting.
Multiple-port knocking Netfilter/IPtables only implementation.
#19: Use Log Analyzer

Read your logs using logwatch or logcheck. These tools make your log reading life easier. It will go through your logs for a given period of time and make a report in the
areas that you wish with the detail that you wish. Make sure LogLevel is set to INFO or DEBUG in sshd_config:
LogLevel INFO
#20: Patch OpenSSH and Operating Systems

It is recommended that you use tools such as yum, apt-get, freebsd-update and others to keep systems up to date with the latest security patches.
Other Options
To hide openssh version, you need to update source code and compile openssh again. Make sure following options are enabled in sshd_config:
# Turn on privilege separation
UsePrivilegeSeparation yes
# Prevent the use of insecure home directory and key file permissions
StrictModes yes
# Turn on reverse name checking
VerifyReverseMapping yes
# Do you need port forwarding?
AllowTcpForwarding no
X11Forwarding no
# Specifies whether password authentication is allowed. The default is yes.
PasswordAuthentication no
Verify your sshd_config file before restarting / reloading changes:

# /usr/sbin/sshd -t
Tighter SSH security with two-factor or three-factor (or more) authentication.

References:
1. The official OpenSSH project.
2. Forum thread: Failed SSH login attempts and how to avoid brute ssh attacks
3. man pages sshd_config, ssh_config, tcpd, yum, and apt-get.
If you have a technique or handy software not mentioned here, please share in the comments below to help your fellow readers keep their openssh based server secure.
Tweet
159
11
Like
90
StumbleUpon
Featured Articles:
20 Linux System Monitoring Tools Every SysAdmin Should Know
20 Linux Server Hardening Security Tips
Linux: 20 Iptables Examples For New SysAdmins
My 10 UNIX Command Line Mistakes
25 PHP Security Best Practices For Sys Admins
The Novice Guide To Buying A Linux Laptop
Top 5 Email Client For Linux, Mac OS X, and Windows Users
Top 10 Open Source Web-Based Project Management Software
{ 117 comments read them below or add one }
Previous Comments
101 MetroMagz December 1, 2011 at 2:37 pm
You could disable it and run as the another account which that account has same permit as root account, thats what i do on my server.
This tutorial very useful as the sysadmin.
102 Siddharth December 12, 2011 at 7:13 pm
Page 5 of 10
7/9/12 7:23 PM
hey, Vivek,
thank you for this excellent post.
I have a query
Is it possible to block multiple ssh logins from a single client pc?
i mean, a single client must be allowed to run only one ssh sessionat any given time.
If it helps, my server is debian and client is ubuntu
103 Henry Paul December 30, 2011 at 6:00 am
There is another solution to root auditing and login. We use root login with without-password option so key login is allowed remotely, password is denied. Then we
configured EASH shell for session logging on our jump server and restrict ssh logins via jump server. Basically the entire ssh session is logged to a remote server for
future auditing, and we still have a more convenient access to the system for running automated scripts, etc.
104 MUNIKRISHNAN.M January 9, 2012 at 6:12 am
this details are very help full Linux learner and working system admins
thank you
105 Andrew Bruce January 19, 2012 at 12:59 am
One technique I like to use is to have local, low-priv accounts used for SSH access on a nicen'empty box. This in conjunction with TCP forwarding allows me to let
users in (no passwords, of course, just PK authentication) and then chroot the users to lock them in their current dir. That minimizes zero-day risk cuz the SSH users
have no privs on the domain, network, or anything elsethey are simply placeholders to allow TCP port forwarding to be setup. Users setting up tunnels to real
servers get prompted with our strong two-factor authentication so we have the best of both worlds.
VPN would be fine but it is very slow compared to SSH. No, this is *not* due to protocol (Ive timed VPN and SSH and there is no detectable difference in
throughput). It is instead due to the edge firewalls that trap / track all VPN traffic and the shitty VPN clients the organization wants us to use.
To sum up: keep your SSH server clean of all other software, use local low-priv user accounts, use only PK for authentication, maybe tie in IP filtering to prevent
hackers from even knowing about your listening port. Port knocking is too complicated for me to explain to users, or Id be using that instead (tres kewl approach).
106 graz January 22, 2012 at 10:11 am
Im still a bit unsure about how using sudo to su is a good idea.
logon to server with regular account and bad password 12345678
sudo su12345678 and you have a root shell..
Surely to step up to the root user from a regular account you should be issuing a separate password. I see the thought behind protecting the root password by never
having to type it and no one having to know it, but with sudo su someone can gain root without the root pw anyway, so whats the point of protecting it if its not
needed anyway.
Just my 2 cents anyway..
107 precious March 27, 2012 at 4:31 pm
Hello I want to know if the SSH can work with Window i have bitvise Tunnelier I want to know how i can work with it can if you can help me with host usename
and pasword. hope to hear from you very soon
108 Andrey March 29, 2012 at 4:26 am
Thank You!
109 AnomyII April 15, 2012 at 5:33 pm
Wow, default Googly searches should have a date filter, since everything is on the indelible web, that it resurrected such an old post as first hit? OK fine Ill play
While anomie might be offended by a few f**ks and god****ns where *HES* from, I live in NYC and F**K! is no more a curse word than OW! or CUT IT OUT!
people do not even bother stopping their 4 year olds from saying it. Its lost all vulgarity here, and is completely acceptable in the business world too, well unless
youre doing I.T. work for a church organization. Maybe.
The point is, you say you dont listen because you feel cussing is childish, Id like to point out that good information is good information no matter how its
delivered. Censoring someone elses speech because it offends you? So when did you join the Republican party?
PS: Your reference is a bit dated, mate. Sailor? Who the hell sails anymore besides the Chinese? Im guessing youve never been in a dockside bar anyway, since that
world must offend your sensibilities! (Im kidding) You want to hear a stream of profanity to make that proverbial sailor blush, engage an NYPD officer in
conversation. :)
----
I would also like to point out that #10, random password example, that your script only uses A-Z, a-z, 0-9 while uw8CnDVMwC6vOKgW is pretty complex for
a brute force attempt on a connection-limited server, that could be brute forced in our everyone has <50Mbit connections" world very quickly, where the addition of
even a single ! or ? would send the brute force routine's runtime an order of magnitude higher.
It's a moot point anyway, NO ONE is going to memorize a random password. It's a Bad Idea(TM). If they bothered memorizing a random string, chances are that
after they did so, they would n e v e r change it, and what's worse in this scenario? If you're this paranoid about security, you're a canidate for a one-time-password
setup and a SecurID key fob.
110 Skaperen April 16, 2012 at 7:41 pm
I dont agree with There is no need to login as root via ssh over a network but neither do I agree with Bobs reasoning, either. The argument I heard was it allowed
each admin to have their own root login, and avoided everyone having to get a new shared root password when one of them leaked or quit. But SSH keys, which are
Page 6 of 10
7/9/12 7:23 PM
more secure, avoided that. So I disallow PASSWORD access to root and require keys only.
Logging directly in as root has advantages, like making sure rsync-over-ssh can back up the system when it originates from the backup servers.
111 undermined April 26, 2012 at 4:29 pm
In my opinion it comes down to knowing what you are trying to protect. If your system needs any level of protection, then you need full auditability. Remote logins
directly to the root user (or any other privileged user) prevent adequate accountability. Yes, one can argue that PK authentication is stronger than PW authentication
but Ive never known a user to change the PK, whereas all of my users are required to change their passwords regularily. We all know that security is a process and
that having layers is an important aspect of defending a system from the onslaught of attacks out there (and the new ones coming out hourly). It is much harder for a
server to verify that the PK used to authenticate is pass-phrase protected; this is where the last argument breaks down for me. As someone who is responsible for the
security of a server, I cant control what tools or configurations the client-side has/uses. I agree that allowing admins to login and sudo su - using their own
passwords is a convenience and an attempt at balancing the use of the root password. We do many things in my environment, which is fairly large (over 6,500
midrange systems): 1. We have a local, non-privileged account to allow remote SSH logins when LDAP/Kerberos are unavailable. 2. We limit the use of the su
binary to members of a specific group (root:trusted, 4550). 3. The account listed in #1 is a member of the appropriate group so that it can execute the su binary. 4.
All admins have to change their passwords at least every 30 days. 5. All non-admins have to change their passwords at least every 90 days. 6. All password changes
are verified through crack to ensure strong password are selected. 7. We use TCPWrappers to limit the connectivity to the servers from specific SSH gateway
servers for regular users. We allow admins to connect directly because we have a dedicated subnet on the LAN where the admins workstations are, inside a locked
room with physical access controls. 8. We run auditd on the SSH gateway servers to log all commands. We run auditd on the servers to log all root commands that
have an assigned terminal (only some systems, especially regulated systems, require logging all commands, including those without an assigned terminal, such as
cron jobs, etc). 9. Physical access to the raised-floor is limited. 10. Access to the serial console is done through an iLO connection with authentication to the Active
Directory system so root logins on the console are still attributable to an individual (and one from a different authentication subsystem). 11. All logs are centralized
to log proxy servers and then forwarded to an appliance that ensures 2 years of off-site, non-modifiable logs.
When we patch our systems (roughly 1 admin to 350-400 systems), we use tools for doing this efficiently. We do not expect an admin to login to each server
manually and run a command, either as the root user directly or by use of sudo su -. This just wouldnt work in a large environment. The use of tools for this specific
purpose, and one that is done monthly at that, was well justified. It just doesnt make sense to use the patching need to justify the lessening of the security posture,
especially in a large environment, where the purchase of a tool is more efficient, doesnt require the lessening of security, and has a faster ROI, especially in a large
environment.
If you dont know what you are trying to secure, and you cant account for every action on the host, then you ultimately dont have adequate security, imho. There
are definately some challenges that arise in larger environments that home operations dont usually encounter but you are also far more likely to need a stronger
security posture in said larger environment than in the home operation.
Two-factor authentication is your friend, as is education and enforcement, where possible, such as with pam_crack to ensure strong passwords.
Just my $0.02
112 Lucas Dohring April 28, 2012 at 9:15 pm
An alternative for generating passwords is:
alias genpasswd='dd if=/dev/urandom count=1 bs=$1 2> /dev/null | ascii85 -n'
Use as `genpasswd 16` for a 16 character password.

note: you need ascii85 installed.
113 Peter O May 9, 2012 at 9:17 am
I need to comment on Bobs excellent point, I disagree.
Most corporate install have more than one admin. Its impossible to tell who actually logged in if they just log on as root. Its better to log in with your real username
and then sudo. This makes it all traceable in syslog.
114 C H June 1, 2012 at 12:00 am
I have an opinion about root login. Im rather fond of creating multiple root accounts: aroot, broot, croot, droot, etc. That way, you can have your accountability and
your quick access too.
115 Mr Smith June 10, 2012 at 8:47 am
Just wanted to add another thanks and nice how to on securing ssh access. Gives people plenty to chew on and research for further reading on the topic. Also not
that really matters, also posted to say, jebuz people get over the use of profanity eh. Can only speak for me, but its extremely annoying to see 18 crying der widdle
eyes out over a tad of adult language having been used. Sheesh youre not going to die from it or etc.
BE STRONG LADIES/LADS !!! Shield your delicate eyes from the horrid nasty words !!! D:
lmao end pet peeve rant. :)
116 A June 17, 2012 at 1:12 am
Thanks for the guide. Im looking to disable error feedback when it doesnt find an appropriate auth method. For example:
No supported authentication methods available (server sent: publickey)
or
(server sent: publickey, gssapi-keyex,gsappi-with-mic)
I want to prevent disclosure of the available auth methods? I assume I have to recompile, but before I go there, is it possible?
Thanks,
Ayman
117 Haakon Ltveit July 8, 2012 at 3:28 pm
Page 7 of 10
7/9/12 7:23 PM
Would it be a good idea to use a different port than port 22?

Might not always be feasible, but it seems like a good idea at least.
Previous Comments
Leave a Comment
Name *
E-mail *
Website
You can use these HTML tags and attributes for your code and commands: <strong> <em> <ol> <li> <u> <ul> <blockquote> <pre> <a href="" title="">
Notify me of followup comments via e-mail.
Security Question:
What is 10 + 10 ?
Solve the simple math so we know that you are a human and not a bot.
Submit
Tagged as: /etc/rssh.conf, /etc/ssh/sshd_conf, openssh, openssh brute Force Attack, openssh security, ssh server security, sshd, sshd check error, sshd chroot, sshd Chroot Directory, sshd stop Brute Force Attack
Previous post: Top 10 Open Source Web-Based Project Management Software

Next post: BIND 9 Dynamic Update DoS Security Update
Follow us @ Youtube | Twitter | Google +
To search, type and hit enter
Page 8 of 10
7/9/12 7:23 PM
nixCraft on Facebook
Like
22,054 people like nixCraft.
Citra
Virendra
Delfryanto Muhammad
Hirzan
Bhargav
Geno
Mark BensonChizoba Emmanuel

Kai
Facebook social plugin
Related Posts
Happy 8th Birthday, OpenSSH!
Download of the Day: OpenSSH Server 5.0 ( security fix release )
Download Of The Day: OpenSSH 5.1
Secure communication with Kerberized OpenSSH on AIX using Windows Kerberos service
Howto improve ssh session performance by reusing an existing connection to a remote openssh server
2004-2012 nixCraft. All rights reserved. Cannot be reproduced without written permission.
Privacy Policy | Terms of Service | Questions or Comments | Copyright Info | Sitemap
Page 9 of 10
7/9/12 7:23 PM
Page 10 of 10

Top 20 OpenSSH Server Best Security Practices

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Top 20 OpenSSH Server Best Security Practices

Hochgeladen von

Copyright:

Verfügbare Formate

Top 20 OpenSSH Server Best Security Practices

nixcraft - insight into linux admin work