# Limit SSH passphrase attempts?



## stevejones (Apr 13, 2011)

Hello,

Hope this is in the right section.

Is there a way to limit SSH passphrase attempts ?

Thank you.


----------



## da1 (Apr 13, 2011)

MaxAuthTries


----------



## SirDice (Apr 13, 2011)

Alternatively you can install something like security/sshguard.


----------



## stevejones (Apr 13, 2011)

Ok thanks guys I'll give both a try.


----------



## stevejones (Apr 13, 2011)

So I had MaxAuthTries set to 2 already but I can still try numerous bad passwords without getting disconnected.

Is there another setting that overrides MaxAuthTries?

Thank you.


----------



## wblock@ (Apr 13, 2011)

After changing the config, did you
`# pkill -HUP sshd`


----------



## stevejones (Apr 13, 2011)

I reloaded `/etc/rc.d/sshd reload`

The problem only seems to happen when using putty. If I *ssh* in the usual way *ssh username@host* I get disconnected after the 3rd bad attempt. Using putty it never disconnects me no matter how many bad attempts. 

So must be a putty thing. I'll try and find something on the putty website.

Thanks again


----------



## SirDice (Apr 14, 2011)

What does /var/log/auth.log tell you when you try to connect with a bad attempt?


----------



## stevejones (Apr 16, 2011)

Nothing shows up when the password is bad. Only logs when the password is good.


----------



## da1 (Apr 16, 2011)

Weird. Ok, do this:

```
:> /var/log/all.log
```
 and put: 
	
	



```
*.*                      /var/log/all.log
```
 in /etc/syslog.conf. Restart syslogd and try the ssh thing again. Check the all.log file as it will record ALL activity.


----------



## stevejones (Apr 16, 2011)

Allowed logging to all.log and bad attempts still do not show up.

Only shows when the publickey has been accepted.


----------



## kpa (Apr 16, 2011)

As far as I know there won't be any connection made to the ssh server until the ssh client is happy with the password you provide for decrypting the private key. So the client (Putty) can keep asking for the right password as long as it pleases and there won't be anything in the server's logs.


----------



## da1 (Apr 16, 2011)

Show us your sshd_config.


----------



## stevejones (Apr 16, 2011)

```
#VersionAddendum FreeBSD-20090522

Port 1970
#Protocol 2
#AddressFamily any
ListenAddress 192.168.1.109
#ListenAddress ::

# Disable legacy (protocol version 1) support in the server for new
# installations. In future the default will change to require explicit
# activation of protocol 1
Protocol 2

# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 1024

# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
PermitRootLogin no
#StrictModes yes
MaxAuthTries 2
#MaxSessions 10

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# Change to yes to enable built-in password authentication.
PasswordAuthentication no
PermitEmptyPasswords no

# Change to no to disable PAM authentication
ChallengeResponseAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

# Set this to 'no' to disable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
#UsePAM yes

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10
#PermitTunnel no
#ChrootDirectory none

# no default banner path
#Banner none

# override default of no subsystems
Subsystem       sftp    /usr/libexec/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#       X11Forwarding no
#       AllowTcpForwarding no
#       ForceCommand cvs server
```


----------



## da1 (Apr 16, 2011)

Uncomment 
	
	



```
#SyslogFacility AUTH
#LogLevel INFO
```
 restart ssh and try again. Keep an eye out for errors in all.log


----------



## gkontos (Apr 17, 2011)

In your /etc/syslog.conf you should have something like this:

```
auth.info;authpriv.info				/var/log/auth.log
```
With this setting you should be able to see all attempts, successful or not.
This is me logging in to my server:

```
Apr 16 08:37:03 mail sshd[6059]: Accepted publickey for gkontos from xxx.xxx.xxx.xxx port 52743 ssh2
```
And this is someone who shouldn't be trying at all:

```
Apr 16 09:46:06 mail sshd[10574]: Did not receive identification string from 184.107.183.194
Apr 16 09:56:10 mail sshd[11219]: Invalid user apple from 184.107.183.194
```
If you want to block script kiddies from filling up your logs you can use a pf firewall rule like this:

```
table <kiddies> persist
block in log quick from <kiddies>
pass in on $mail proto tcp to any port ssh flags S/SA keep state (max-src-conn 4, max-src-conn-rate 3/5, overload <kiddies> flush)
```
This allows 4 connections from the same source and 3 connection attempts in 5 seconds. After that the IP is being blocked.
Regards,
George


----------



## stevejones (Apr 17, 2011)

da1 said:
			
		

> Uncomment
> 
> 
> 
> ...




Still doesn't show any bad attempts.


```
auth.info;authpriv.info				/var/log/auth.log
```

My syslog.conf has the same setting as above for auth.log

gkontos I'll give your fw rule a try, thanks.


----------



## da1 (Apr 17, 2011)

Ok, that's it .... start it in the foreground with
	
	



```
/usr/sbin/sshd -d
```
And from the manual:

```
-d      Debug mode.  The server sends verbose debug output to standard
             error, and does not put itself in the background.  The server
             also will not fork and will only process one connection.  This
             option is only intended for debugging for the server.  Multiple
             -d options increase the debugging level.  Maximum is 3.
```

I would also monitor the traffic with
	
	



```
tcpdump
```
 in another session.


----------



## phoenix (Apr 17, 2011)

When you mention "passphrase attempts" are you talking about the passphrase *for the ssh key on the client*?

If so, there's nothing to log on the server, as that is all done on the client.  All the server sees if the key, nothing more.


----------



## stevejones (Apr 17, 2011)

phoenix said:
			
		

> When you mention "passphrase attempts" are you talking about the passphrase *for the ssh key on the client*?
> 
> If so, there's nothing to log on the server, as that is all done on the client.  All the server sees if the key, nothing more.



Yes for the ssh key on the client.

So it's the client that's doing the authentication ?

That might explain the difference between putty and the built in ssh client.


----------



## phoenix (Apr 18, 2011)

The client tries to read the private key file.  If it's encrypted with a passphrase, the client asks for the passphrase.  If the passphrase does not match, the client asks again, and keeps asking until either the correct passphrase is given, or all the tries are used up and then it exits with a failure.  This all happens on the client.

The actual SSH authentication is done on the server.  But, all the server does is check that the key file sent matches the public key on the server.  So long as the private and public keys match ... you are allowed to connect and login.

The difference between PuTTY and the standard OpenSSH client is that you need to convert your OpenSSH keys into PuTTY-formatted keys (ppk files) before you can use them.  Which is why the PuTTY suite include the puttygen program, which does just that.


----------

