Limit SSH passphrase attempts?

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.
 
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 :)
 
Weird. Ok, do this:
Code:
:> /var/log/all.log
and put:
Code:
 *.*                      /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.
 
Allowed logging to all.log and bad attempts still do not show up.

Only shows when the publickey has been accepted.
 
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.
 
Code:
#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
 
In your /etc/syslog.conf you should have something like this:
Code:
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:
Code:
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:
Code:
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:
Code:
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
 
da1 said:
Uncomment
Code:
#SyslogFacility AUTH
#LogLevel INFO
restart ssh and try again. Keep an eye out for errors in all.log


Still doesn't show any bad attempts.

Code:
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.
 
Ok, that's it .... start it in the foreground with
Code:
/usr/sbin/sshd -d
And from the manual:
Code:
     -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
Code:
tcpdump
in another session.
 
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.
 
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.
 
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.
 
Back
Top