/etc/ssh/sshd_config Banner /etc/issue.net
/etc/issue.net ********************************************* * This is a private system. * * Use by unauthorized persons is prohibited.* * All accesses to this service are logged. * *********************************************
create your key
ssh-keygen -t dsa
copy your new key out to all the servers, and make ssh use it. the mkdir below may fail if the directory exists, ignore the error its harmless
for i in $(cat servers) ; do echo SERVER=$; scp ~/.ssh/id_dsa.pub $i ssh $i "mkdir .ssh ; chmod 700 .ssh ; cat ~/id_dsa.pub >> ~/.ssh/authorized_keys ; chmod 644 /.ssh/authorized_keys;" done
# ssh -o 'StrictHostKeyChecking no' user@host
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA host key has just been changed. The fingerprint for the RSA key sent by the remote host is a7:a8:f2:97:94:33:58:b7:9d:bc:e0:a6:6b:f7:0a:29. Please contact your system administrator. Add correct host key in /home/ramesh/.ssh/known_hosts to get rid of this message. Offending key in /home/ramesh/.ssh/known_hosts: 6 Permission denied (publickey,password).
# sed -i '6d' ~/.ssh/known_hosts
Perl solution:
# perl -pi -e 's/\Q$_// if ($. == 6);' ~/.ssh/known_hosts
Joost van Baal, february 2006
This document explains how to harden the OpenSSH sshd, as commonly found on GNU/Linux and other Unix-like systems. Its intended audience is system administrators who are not afraid to read manpages. Examples will be somewhat Debian-specific, but are likely applicable for other systems too. If you have any suggestions or comments, please email joostvb+ssh-harden@uvt.nl.
If your system is connected to the internet, and you're offering a publically accessible sshd, you'll likely have seen stuff like
Feb 19 04:18:45 gelfand sshd[6461]: (pam_unix) authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=foo.example.com Feb 19 04:18:47 gelfand sshd[6461]: Failed password for invalid user ident from 10.1.2.3 port 53170 ssh2 Feb 19 04:18:49 gelfand sshd[6463]: Invalid user privoxy from 10.1.2.3 Feb 19 04:18:49 gelfand sshd[6463]: (pam_unix) check pass; user unknown Feb 19 04:18:49 gelfand sshd[6463]: (pam_unix) authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=foo.example.com Feb 19 04:18:50 gelfand sshd[6463]: Failed password for invalid user privoxy from 10.1.2.3 port 53502 ssh2 Feb 19 04:18:52 gelfand sshd[6465]: Invalid user pvm from 10.1.2.3 Feb 19 04:18:52 gelfand sshd[6465]: (pam_unix) check pass; user unknown Feb 19 04:18:52 gelfand sshd[6465]: (pam_unix) authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=foo.example.com Feb 19 04:18:54 gelfand sshd[6465]: Failed password for invalid user pvm from 10.1.2.2 port 53804 ssh2
in your /var/log/auth.log file. This means you've been under attack by a (very likely) automated sshd scanner. It tried to open a shell on your system by doing brute-force password guessing dictionary attacks.
Recently, we've seen attacks like this succeed, and leading to GNU/Linux systems being added to DDoS zombie bot networks.
Let me tell you this: you don't want such a thing to happen to your system.
There are various ways to make sure you won't be the next target. We'll give you some of the ways here. Pick the one (or pick _more_ than one, to be even more secure!) most suitable for your situation. Questions to ask yourself in order to decide: Do you really need an sshd? Who are the legitimate users of your sshd? Are these people on static IPs? Are these people able to handle ssh keypairs?
If you make any of the suggested configuration changes: test the change before trusting it!
/etc/init.d/ssh
script and/or remove /usr/sbin/sshd
. (You probaly want to _keep_ the client: /usr/bin/ssh
) If you're running Debian sarge, do this by invoking “dpkg-reconfigure -plow ssh”
./etc/hosts.allow
to allow ssh only from trusted IPs. See hosts_access(5).
/etc/ssh/sshd_config
), and tell your users to use ssh's -p flag. It is preferred to use a port <1024
, so that only root can run the server.AllowUsers youraccount@1.2.3.* youraccount@dyn-foo.example.com yourfriend@2.3.4.5 anotheraccount
to /etc/ssh/sshd_config. This example would allow access from 1.2.3.0/24
and
from the IP with PTR pointing to dyn-foo.example.com to the local user youraccount. It would furthermore allow access from 2.3.4.5 to user yourfriend. Finally, SSH access to anotheraccount is allowed from any IP. All other SSH access is denied. See sshd_config(5).
PasswordAuthentication no
” in sshd_config
. This forces people to use keypairs: .ssh/authorized_keys
on your host and ~/.ssh/id_rsa[.pub]
on their host. You might want to disable passwords alltogether now: the second field in /etc/shadow
should be *.PermitRootLogin no
” in sshd_config
is nice too.)“Securing SSH, kind of.” by Martin ( http://www.flexion.org/ ) at http://www.flexion.org/site/index.php?gadget=StaticPage&action=Page&id=9 .
“Keeping SSH access secure” by Steve Kemp and various contributors at http://www.debian-administration.org/articles/87 .
Wessel Dankers for valuable feedback.
This is version $Id: ssh-harden.txt 9678 2006-02-20 06:40:05Z joostvb $, maintained using SVN at URL: https://infix.uvt.nl/its-id/trunk/sources/uvt-unix-doc/ssh-harden.txt $.
This document is published at http://www.non-gnu.uvt.nl/pub/uvt-unix-doc/ .
Copyright 2006 Tilburg University http://www.uvt.nl/
This document is free; you can redistribute it and/or modify it under the terms of the GNU GPL, see http://www.gnu.org/copyleft/gpl.html . There is NO WARRANTY.
/etc/fail2ban/jail.conf\\
action = %(action_mw)s\\
use EF DSCP in ssh:
~/.ssh/config IPQoS ef
use jump host
~/.ssh/config Host finalhost HostName finalhost User userfinal ProxyCommand ssh proxyuser@proxyhost nc %h %p
then one can simply type
ssh finalhost
to ssh via proxyhost to final destination host
using same options for multiple hosts in same domain
Host switch* router* myrouter* cmts*
no need to type FQDN for switch-somethingsomething