you can also limit how many connection are allowed to the server using
the same ip and how many sessions also you can time it out. I have it on
my iptables rules I love it, in addition to the authfail

Just my 2 cents.

remo

Antonio A Hilario wrote:
> Hello Richard,
>
> I've had this kind of trouble before, taking over the maintenance of a web
> server with openssh installed in its default configuration.
>
> The problem here is that password logins are permitted by the SSH
> configuration, and the ssh server is configured to listen on the default port
> 22.
>
> What you need to do is a combination of things.
>
> 1. Use a different port than port 22.
>
> Change the setting for Port in /etc/ssh/sshd_config on the *remote* side to a
> high-numbered port, numbered above 1024 (the default privileged ports range
> is from 1-1023), and restart the OpenSSH server. For example, to set SSH to
> listen on port 3418:
> # ------------ snip -------------
> # Port 22
> Port 3418
> # ------------ snip -------------
>
> This prevents automated brute force attacks using a dictionary from easily
> finding the server listen port.
>
> 2. Enable public key authentication. This takes three steps:
>
> a. Add these lines to your /etc/ssh/sshd_config:
>
> # ------------ snip -------------
> RSAAuthentication yes
> PubkeyAuthentication yes
> # ------------ snip -------------
>
> b. Generate a public key pair, by executing these commands from your command
> line. If you are logged in as your regular, unprivileged user, say, rchapman,
> and you want to generate an 8192 bit RSA key (8192 bits is a bit overkill,
> some might say; typically people would use values between 1024-4096):
>
> # ------------ snip -------------
> rchapman@~] mkdir -p ~/.ssh
> rchapman@~] chmod 700 ~/.ssh
> rchapman@~] rsa-keygen -t rsa -b 8192
> (you'll be asked to save two files, one with a .pub extension)
> # ------------ snip -------------
>
> You need to transfer the public key half (rsa_key.pub) to the target server
> somehow, say on a USB stick, or over the wire. You keep the private half
> (rsa_key) on the machine from which you connect to remote_side.
>
> Concatenate the public key half (in this example, called rsa_key.pub) to the
> file ~/.ssh/authorized_keys on the target server:
>
> rchapman_remote@remote_side] # cat rsa_key.pub >> ~/.ssh/authorized_keys
>
> c. To connect to the server named "remote_side" using the private key half
> you've kept on your local machine, you need to create the file ~/.ssh/config,
> adding these lines:
>
> # ------------ snip -------------
> # Local OpenSSH config file in /home/rchapman/.ssh/config
> Host remote_side
> Port = 3418
> IdentityFile = ~/.ssh/rsa_key
> Protocol = 2
> User = rchapman_remote
> # Note that rchapman_remote is the username on the remote side
> #
> # ------------ snip -------------
>
> c. Do an ssh login to the remote side, as your local user:
>
> rchapman@~] # ssh -v remote_side
>
> The "-v" enables verbose logging to your console, of the status of protocol
> negotiation.
>
> Hope this helps.
>
> avahilario@gmail.com
>
> On Friday 02 May 2008, Richard Chapman wrote:
>> Hi
>> I don't now much about ssh - but I use it to connect to my centos server
>> with nx. Normally - I only do this on our local network and have port 22
>> disabled in the internet firewall.
>> Recently - I was away from the office - and enabled port 22 on the
>> firewall - so I could access the centos server remotely. I thought ssh
>> had pretty good security - and nx uses a key to allow access.
>>
>> However - after only a day with port 22 enabled - I had some sort of
>> attack reported by the firewall - and I had the following in my logwatch...
>>
>> --------------------- pam_unix Begin ------------------------
>>
>> smtp:
>> Unknown Entries:
>> authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= :
>> 155 Time(s) check pass; user unknown: 155 Time(s)
>> authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=
>> user=richard: 1 Time(s) bad username [!]: 1 Time(s)
>> bad username[*]: 1 Time(s)
>>
>> sshd:
>> Authentication Failures:
>> unknown (60.12.1.158): 1581 Time(s)
>> root (60.12.1.158): 82 Time(s)
>> sshd (60.12.1.158): 4 Time(s)
>> mysql (60.12.1.158): 3 Time(s)
>> richard (60.12.1.158): 3 Time(s)
>> gopher (60.12.1.158): 2 Time(s)
>> halt (60.12.1.158): 2 Time(s)
>> mail (60.12.1.158): 2 Time(s)
>> mailnull (60.12.1.158): 2 Time(s)
>> max (60.12.1.158): 2 Time(s)
>> nfsnobody (60.12.1.158): 2 Time(s)
>> nobody (60.12.1.158): 2 Time(s)
>> postgres (60.12.1.158): 2 Time(s)
>> squid (60.12.1.158): 2 Time(s)
>> adm (60.12.1.158): 1 Time(s)
>> ais (60.12.1.158): 1 Time(s)
>> apache (60.12.1.158): 1 Time(s)
>> bin (60.12.1.158): 1 Time(s)
>> daemon (60.12.1.158): 1 Time(s)
>> ftp (60.12.1.158): 1 Time(s)
>> games (60.12.1.158): 1 Time(s)
>> gdm (60.12.1.158): 1 Time(s)
>> haldaemon (60.12.1.158): 1 Time(s)
>> lp (60.12.1.158): 1 Time(s)
>> named (60.12.1.158): 1 Time(s)
>> news (60.12.1.158): 1 Time(s)
>> nscd (60.12.1.158): 1 Time(s)
>> ntp (60.12.1.158): 1 Time(s)
>> nut (60.12.1.158): 1 Time(s)
>> operator (60.12.1.158): 1 Time(s)
>> pcap (60.12.1.158): 1 Time(s)
>> piranha (60.12.1.158): 1 Time(s)
>> postfix (60.12.1.158): 1 Time(s)
>> rpc (60.12.1.158): 1 Time(s)
>> rpcuser (60.12.1.158): 1 Time(s)
>> rpm (60.12.1.158): 1 Time(s)
>> shutdown (60.12.1.158): 1 Time(s)
>> smmsp (60.12.1.158): 1 Time(s)
>> sync (60.12.1.158): 1 Time(s)
>> tim (60.12.1.158): 1 Time(s)
>> uucp (60.12.1.158): 1 Time(s)
>> webalizer (60.12.1.158): 1 Time(s)
>> Invalid Users:
>> Unknown Account: 1581 Time(s)
>>
>>
>> Can anyone tell me what is going on here. It looks like someone is
>> trying to find usernames by just testing a list. They appear to have
>> found 3 of our usernames - but hopefully not the passwords.
>>
>>
>> How much of a security issue is this? If they did guess a password -
>> would they have full shell access? If so - how is this any better than
>> (say) telnet?
>>
>> Are there any settings I can and should do to restrict access further? I
>> have blocked port 22 in the firewall for the time being. Can I set up a
>> shared private key or similar?
>>
>> Many thanks
>>
>> Richard

>
>
>
> !DSPAM:481b4f7c301401336712104!
>