# sshd PAM error spam from china?



## buradd (Oct 3, 2012)

I have a server that hosts a simple web site and I have obviously an open ssh port so I can fiddle with it.. I don't check the main screen often, but I did recently and noticed that as of Sept 27th, multiple china IP's have been trying to ssh as root.. they are resulting in PAM authentication errors... I have not enabled logging in thru ssh as root, so my question is, am I safe to ignore these feeble attempts to break into my simple server? I consider my root pw to be very strong as well.. any reassurance would be greatly appreciated.. also any tips i.e.; should I try to change the ssh port or something?


----------



## AlexJ (Oct 3, 2012)

First of all change default port to something above 30000.
Second - use certificate based authentication only and disable "using keyboard authentication" completely.
Third - there is a bunch of programs that open firewall port for particular IP only on demand with some kinda secrets.


----------



## SirDice (Oct 3, 2012)

Welcome to the wonderful world of the internet. A world that's riddled with people looking for an easy score.

Install something like security/sshguard or security/py-fail2ban.


----------



## kpa (Oct 3, 2012)

China has the biggest amount of infected home computers that are part of botnets that are behind this type of probing, it's a simple statistic based on the huge number of new computers and low awareness of computer security, no need to go to some silly conspiracy theories involving the chinese goverment.


----------



## buradd (Oct 5, 2012)

AlexJ said:
			
		

> First of all change default port to something above 30000.
> Second - use certificate based authentication only and disable "using keyboard authentication" completely.
> Third - there is a bunch of programs that open firewall port for particular IP only on demand with some kinda secrets.



changing the port has stopped the incoming attacks, thank you for the info!

i have to read more into the private/public key thing, I keep getting key denied when using putty and puttygen keys.. but you have put me in the right direction :stud


----------



## SirDice (Oct 5, 2012)

You probably copied the wrong formatted key. It should be all on one line:


```
ssh-dss AAAA{lots of gibberish} dice@williscorto.dicelan.home
```

And append it to ~/.ssh/authorized_keys.


----------



## buradd (Oct 6, 2012)

SirDice said:
			
		

> You probably copied the wrong formatted key. It should be all on one line:
> 
> 
> ```
> ...



thank you sir, I had seen you put the name@domain at the end and noticed the copy/paste box from puttygen said imported-ssh-key.. thats the one I was pasting in authorized keys.. but when I just cp the id_dsa.pub to authorized_keys it worked.. thank you! love this community


----------



## AlexJ (Oct 6, 2012)

Well, there is a lot of "how-to" that explain public-key authentication, 
but most of them assume that you will do it on an Unix machine.
Pay attention that a bunch of people who wrote this don't understand how it works that why
they suggest/advise to generate crypto keys on the same computer that they need to protect.
*
Private key SHOULD NOT be on a computer that you going connect to!

Private key should live on your workstation only 
that you're going to use for connection to a remote computer.

Remote computer SHOULD have only a public key.
*

Below you can find some kinda "short" instruction that I wrote a long time ago for our users.
It will work for most users who didn't change pre-installed software on their 
notebooks/desktops or shortly for windows workstations.

==================================================
1. Run PuTTyGen

2. Select in the bottom of screen *SSH-2 RSA* radio button.

3. Choose number of bits in a generated key.
   While 1024 bits is impossible job to break it in a few 
   decades on a single computer, we shouldn't forget that modern 
   crackers/hackers own tens of thousands zombie computers at
   once so if they would need to brute-force something - they 
   have a lot of power to do this on their malicious distributed network.
   So, shortly - place there 2048 bit to complicate brute force task more.

4  Press "Generate" a public/private key pair button
   (To speed up process entertain yourself with random-path 
    mouse moving around progress bar of *PuTTyGen*)

5. When keys is ready, add UserName@domainName of remote computer to the field 
   "Key comment" on the end of string that show something like "rsa-key-20121005"
   So it may looks like _rsa-key-20121005-SuperUser@SuperDuperBox.com_ 
   that would helps a little to track multiple keys.

6. Enter simple to remember password in the fields "Key passphrase/Confirm passphrase"
   to protect this private key from unauthorized using(kids/wive/coworkers/fbi)
   (If you hate to type this password that unlock private key on your local 
    workstation when you connect to a remote computer or most importantly when you 
    use software with scare name like - *FileZilla*, 
    you can use late pageant(that comes with *PuTTy*), which
    will automatically feed *putty* and *filezila* with this password)

7. Press *"Save private key"* button.
   (Choose name of private key-file like User@yourDomain.com.ppk)

8.(!!!) 
   8.a Make left mouse click exactly on *ssh-rsa* in the upper box that
       have name "Public key for pasting into OpenSSH authorized_keys file"
   8.b Make right mouse click exactly on *ssh-rsa* in the upper box that
       have name "Public key for pasting into OpenSSH authorized_keys file"
       and from appeared menu click on "Select All" 
   8.c Repeat step 8.b but choose from menu "Copy" instead of "Select All"
   8.d Open notepad/wordpad/whateverpad and paste there your *"Public key"*
   8.e Save it with name authorized_keys

9. Now you have multiple ways to move this public key to a remote computer to exact location:
~/.ssh and place it there in the file with name authorized_keys(!!!)
   You can send it over FTP or simply paste it into your favorite editor
   on remote computer if you already connected over SSH to the file:

```
~/.ssh/authorized_keys
```

10. To be make sure that public key pasted correctly - run following from command line:

```
cd ~/.ssh && cp authorized_keys authorized_keys.tmp && awk '{gsub("\r",""); print;}' authorized_keys.tmp > authorized_keys &&  rm -f authorized_keys.tmp
```
   Operation above will remove Windows's "end of line" hidden character that Unix machine disregard to understand.
*DO NOT EDIT pasted string!!!* 
   It should be one line only that start with *ssh-rsa AAAA....* 
   and ended witn comments that was added in the step #5

11. Now you need to tell remote computer - don't use keyboard authentication.
    edit /etc/sshd_config and make sure you have following there:

```
#############################################
# Keyboardless authentication with public key
#--------------------------------------------
#

Protocol 2
PubkeyAuthentication yes
PasswordAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
UsePAM yes

StrictModes yes
IgnoreRhosts yes

#
#=============================================



##########################
# --- Optional stuff ---
#-------------------------
#

PrintLastLog yes
GatewayPorts no
AllowTcpForwarding yes
LoginGraceTime 33

# Prevent "ghost" users that was disconnected because of network disruption.
# TCPKeepAlive is spoofable. Use ClientAliveInterval instead
TCPKeepAlive no
ClientAliveInterval 300
ClientAliveCountMax 3

# allow tun(4) device forwarding
PermitTunnel yes
  
# To be able to use SSHFS make sure you have following. (correct this path of sftp-server for 64bit machines!!!)
Subsystem sftp /usr/libexec/sftp-server 

# ADJUST (!!!) Access permissions to your needs:
# The allow/deny directives are processed in the following order: DenyUsers, AllowUsers, DenyGroups, and finally  AllowGroups
# AllowGroups wheel git
```

12. Run following on remote computer:

```
nohup service sshd restart
```

13. Start *PuTTy*, load your remote session from "Saved sessions"

14. Go to SSH->Auth tree and browse for your private key (that you saved in step (7) )

15. Save *PuTTy* session and ... actually that it - The End of story, use it 
==================================================


----------



## wblock@ (Oct 6, 2012)

buradd said:
			
		

> changing the port has stopped the incoming attacks, thank you for the info!



Quoting from SSH Mastery:


> Running SSH on an unusual port won't actually help secure SSH, but it will reduce the number of login attempts from SSH-cracking worms.


----------



## buradd (Oct 6, 2012)

i've changed the port, disabled password auth, and enabled a working key..since then there has been no more logged attempts of foreign connections, i'm sure this can be marked solved now, thank you everyone for the help!


----------

