I used to run my ssh server on a high port no. to avoid the dictionary
attacks. It worked quite well but I've had to go back to good ol' port
22 because I've been plugging laptop into networks with *crazy*
restrictions like blocking huge ranges of client ports except for
specific services.

So I've changed the server config to allow PubkeyAuthentication only,
and that's working fine, BUT the dictionary attacks are still
coming. (See below for the sort of stuff I mean, in syslog.)

AIUI, dictionary attacks on PubkeyAuthentication are hopeless, and I'm
surprised the attacking "clients" try it. Am I right? Why do they keep
trying? Anything else I can/should do?

Thanks!



Invalid user webmaster from 24.148.29.250
Invalid user ftp from 24.148.29.250
Invalid user sales from 24.148.29.250
Invalid user admin from 24.148.29.250
Invalid user andrea from 24.148.29.250
Invalid user guest from 24.148.29.250
Invalid user guest1 from 24.148.29.250
Invalid user guest2 from 24.148.29.250
Invalid user guest3 from 24.148.29.250
Invalid user guest4 from 24.148.29.250
Invalid user guest5 from 24.148.29.250
Invalid user guest6 from 24.148.29.250
Invalid user guest7 from 24.148.29.250
Invalid user guest8 from 24.148.29.250
Invalid user guest9 from 24.148.29.250

Nomen Nescio wrote:

> I used to run my ssh server on a high port no. to avoid the dictionary
> attacks. It worked quite well but I've had to go back to good ol' port
> 22 because I've been plugging laptop into networks with *crazy*
> restrictions like blocking huge ranges of client ports except for
> specific services.
>
> So I've changed the server config to allow PubkeyAuthentication only,
> and that's working fine, BUT the dictionary attacks are still
> coming. (See below for the sort of stuff I mean, in syslog.)
>
> AIUI, dictionary attacks on PubkeyAuthentication are hopeless, and I'm
> surprised the attacking "clients" try it. Am I right? Why do they keep
> trying? Anything else I can/should do?

How should they know you have disabled password authetication? (you did,
didn't you?)
--
Cezary Morga

Nomen Nescio <nobody@dizum.com> wrote:
> I used to run my ssh server on a high port no. to avoid the dictionary
> attacks. It worked quite well but I've had to go back to good ol' port
> 22 because I've been plugging laptop into networks with *crazy*
> restrictions like blocking huge ranges of client ports except for
> specific services.

I've thought about a stupid simple web page (most sites would allow 80)
that I could type in an IP address and enable that address for port 22.
Even with *zero* authentication on the web page, I don't think it would
be a problem. A bot isn't going to do that kind of work for one host.

> AIUI, dictionary attacks on PubkeyAuthentication are hopeless, and I'm
> surprised the attacking "clients" try it. Am I right? Why do they keep
> trying?

Stupid bots don't care.

--
Darren Dunham ddunham@taos.com
Senior Technical Consultant TAOS http://www.taos.com/
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >

Nomen Nescio <nobody@dizum.com> writes:

>I used to run my ssh server on a high port no. to avoid the dictionary
>attacks. It worked quite well but I've had to go back to good ol' port
>22 because I've been plugging laptop into networks with *crazy*
>restrictions like blocking huge ranges of client ports except for
>specific services.

>So I've changed the server config to allow PubkeyAuthentication only,
>and that's working fine, BUT the dictionary attacks are still
>coming. (See below for the sort of stuff I mean, in syslog.)

>AIUI, dictionary attacks on PubkeyAuthentication are hopeless, and I'm
>surprised the attacking "clients" try it. Am I right? Why do they keep
>trying? Anything else I can/should do?

Do you thinkthat there is a human being behind those attacks, trying all
the passwords? It is a program. which is launched from someone else's
computer.

You could just put that IP address into /etc/hosts.allow with a deny tag
for ssh.
sshd: 24.148.29.250:deny


>Thanks!



>Invalid user webmaster from 24.148.29.250
>Invalid user ftp from 24.148.29.250
>Invalid user sales from 24.148.29.250
>Invalid user admin from 24.148.29.250
>Invalid user andrea from 24.148.29.250
>Invalid user guest from 24.148.29.250
>Invalid user guest1 from 24.148.29.250
>Invalid user guest2 from 24.148.29.250
>Invalid user guest3 from 24.148.29.250
>Invalid user guest4 from 24.148.29.250
>Invalid user guest5 from 24.148.29.250
>Invalid user guest6 from 24.148.29.250
>Invalid user guest7 from 24.148.29.250
>Invalid user guest8 from 24.148.29.250
>Invalid user guest9 from 24.148.29.250

Darren Dunham <ddunham@redwood.taos.com> writes:

>Nomen Nescio <nobody@dizum.com> wrote:
>> I used to run my ssh server on a high port no. to avoid the dictionary
>> attacks. It worked quite well but I've had to go back to good ol' port
>> 22 because I've been plugging laptop into networks with *crazy*
>> restrictions like blocking huge ranges of client ports except for
>> specific services.

>I've thought about a stupid simple web page (most sites would allow 80)
>that I could type in an IP address and enable that address for port 22.
>Even with *zero* authentication on the web page, I don't think it would
>be a problem. A bot isn't going to do that kind of work for one host.

Or you could simply have your ssh respond to port 80. Unless you actually
have a web server running on that machine, that will be fine.

>> AIUI, dictionary attacks on PubkeyAuthentication are hopeless, and I'm
>> surprised the attacking "clients" try it. Am I right? Why do they keep
>> trying?

>Stupid bots don't care.

>--
>Darren Dunham ddunham@taos.com
>Senior Technical Consultant TAOS http://www.taos.com/
>Got some Dr Pepper? San Francisco, CA bay area
> < This line left intentionally blank to confuse you. >

Nomen Nescio <nobody@dizum.com> writes:

> Why do they keep
> trying?

Because they're script kiddie attacks and will try no matter what your
config.

> Anything else I can/should do?

Just move sshd to listen on a non-standard port and the annoyance will
cease.

--
Todd H.
http://www.toddh.net/

Todd H. wrote:
> Nomen Nescio <nobody@dizum.com> writes:
>
>> Why do they keep
>> trying?
>
> Because they're script kiddie attacks and will try no matter what your
> config.
>
>> Anything else I can/should do?
>
> Just move sshd to listen on a non-standard port and the annoyance will
> cease.
>

Or just don't worry about it if you've disabled password authentication.
That keeps them busy trying hopelessly to get into your server instead
of attacking one that's truly vulnerable.

Chuck <skilover_nospam@bluebottle.com> writes:

> Todd H. wrote:
> > Nomen Nescio <nobody@dizum.com> writes:
> >
> >> Why do they keep
> >> trying?
> >
> > Because they're script kiddie attacks and will try no matter what your
> > config.
> >
> >> Anything else I can/should do?
> >
> > Just move sshd to listen on a non-standard port and the annoyance will
> > cease.
> >
>
> Or just don't worry about it if you've disabled password authentication.
> That keeps them busy trying hopelessly to get into your server instead
> of attacking one that's truly vulnerable.

If the sshd server isn't there to listen to an attack on port 22, sshd
won't cut a failed login attempt to a log. The host level port
filter will just quietly ignore the tcp connection request. Seems to
work a treat.



--
Todd H.
http://www.toddh.net/

I am surprised that no one has mentioned the possibility of using
IPTables in order to address the issue raised by the OP, all the more so
bearing in mind that he seems to be annoyed about his logs getting full of
traces from those childish dictionary attacks.

This is a deterrent against SSH breakin attempts. Without this,
/var/log/ messages tends to get flooded by traces from such attempts. The
last two lines of this script prevent such attempts to take place more
frequently than every 15 seconds. Effectively, a failed SSH login attempt
from a given IP address results in any further SSH login attempts from
that address to be summarily dismissed for 15 seconds. The first line in
the script is there so that this mechanism is not used in the 192.168.0
internal network.


iptables -A INPUT -p tcp -i eth0 -s 192.168.0.0/24 --dport 22 -j ACCEPT
iptables -A INPUT -p tcp -i eth0 -m state --state NEW --dport 22 -m recent --update --seconds 15 -j DROP
iptables -A INPUT -p tcp -i eth0 -m state --state NEW --dport 22 -m recent --set -j ACCEPT

In comp.security.ssh Frank W. Steiner <steinfw@hotmail.com>:
> I am surprised that no one has mentioned the possibility of using
> IPTables in order to address the issue raised by the OP, all the more so

I am surprised how you got the OP would run Linux at all?

[..]

BTW
Please quote some context on reply, thx.

--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo zvpunry@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 162: bugs in the RAID

On Oct 5, 3:52 pm, Frank W. Steiner wrote:
[snip]
> This is a deterrent against SSH breakin attempts. Without this,
> /var/log/ messages tends to get flooded by traces from such attempts. The
> last two lines of this script prevent such attempts to take place more
> frequently than every 15 seconds. Effectively, a failed SSH login attempt
> from a given IP address results in any further SSH login attempts from
> that address to be summarily dismissed for 15 seconds. The first line in
> the script is there so that this mechanism is not used in the 192.168.0
> internal network.
>
> iptables -A INPUT -p tcp -i eth0 -s 192.168.0.0/24 --dport 22 -j ACCEPT
> iptables -A INPUT -p tcp -i eth0 -m state --state NEW --dport 22 -m recent --update --seconds 15 -j DROP
> iptables -A INPUT -p tcp -i eth0 -m state --state NEW --dport 22 -m recent --set -j ACCEPT

And if you don't want or can't use iptables, then look for DenyHosts
which does a similar function using the tcp_wrappers support that most
sshd daemons are built with.
--
René Berber

Unruh <unruh-spam@physics.ubc.ca> wrote:

> >AIUI, dictionary attacks on PubkeyAuthentication are hopeless, and I'm
> >surprised the attacking "clients" try it. Am I right? Why do they keep
> >trying? Anything else I can/should do?
>
> Do you thinkthat there is a human being behind those attacks, trying all
> the passwords? It is a program. which is launched from someone else's
> computer.

Of course I know that ... what I mean is, can't the bot tell that the
server only takes key authentication?

What's the bot trying to send me, random big numbers?

Cezary Morga <cezarym@data.pl> wrote:

> How should they know you have disabled password authetication?

My ssh client can tell. If I try to log in without the key loaded in
ssh-agent and I hit enter when it asks for the key passphrase, ssh no
longer asks me for the login password next, it just says "Permission
denied (publickey)", so can't the bot tell the same thing?


> (you did, didn't you?)

Yes, that's what I meant! Here are the bits of sshd_config:

RSAAuthentication yes
PubkeyAuthentication yes
IgnoreRhosts yes
RhostsRSAAuthentication no
HostbasedAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
PasswordAuthentication no

>>>>> "NN" == Nomen Nescio <nobody@dizum.com> writes:

NN> Unruh <unruh-spam@physics.ubc.ca> wrote:
>> >AIUI, dictionary attacks on PubkeyAuthentication are hopeless, and
>> I'm >surprised the attacking "clients" try it. Am I right? Why do
>> they keep >trying? Anything else I can/should do?
>>
>> Do you thinkthat there is a human being behind those attacks,
>> trying all the passwords? It is a program. which is launched from
>> someone else's computer.

NN> Of course I know that ... what I mean is, can't the bot tell that
NN> the server only takes key authentication?

NN> What's the bot trying to send me, random big numbers?

No, it's likely still trying password authentication. The SSH-AUTH
protocol allows a client to try any authentication method it likes at any
point, regardless of whether the server accepts it. The attack program in
question probably just connects and tries passwords, without bothering to
notice whether password authentication is even supported.

--
Richard Silverman
res@qoxp.net

"Richard E. Silverman" <res@qoxp.net> wrote:

> NN> Of course I know that ... what I mean is, can't the bot tell that
> NN> the server only takes key authentication?
>
> NN> What's the bot trying to send me, random big numbers?
>
> No, it's likely still trying password authentication. The SSH-AUTH
> protocol allows a client to try any authentication method it likes at any
> point, regardless of whether the server accepts it. The attack program in
> question probably just connects and tries passwords, without bothering to
> notice whether password authentication is even supported.

Now I see! My "normal" ssh client doesn't give me a paswsord option
because the server has told it not to bother. The bot tries it anyway
because it wasn't paying attention.

Stupid bot!

Todd H. wrote:
> Chuck <skilover_nospam@bluebottle.com> writes:
>
>> Todd H. wrote:
>>> Nomen Nescio <nobody@dizum.com> writes:
>>>
>>>> Why do they keep
>>>> trying?
>>> Because they're script kiddie attacks and will try no matter what your
>>> config.
>>>
>>>> Anything else I can/should do?
>>> Just move sshd to listen on a non-standard port and the annoyance will
>>> cease.
>>>
>> Or just don't worry about it if you've disabled password authentication.
>> That keeps them busy trying hopelessly to get into your server instead
>> of attacking one that's truly vulnerable.
>
> If the sshd server isn't there to listen to an attack on port 22, sshd
> won't cut a failed login attempt to a log. The host level port
> filter will just quietly ignore the tcp connection request. Seems to
> work a treat.
>
>
>

That's what I do too but I think the OP said he needs to set up camp
behind FW's that he doesn't control. Hence he is stuck with port 22.

In comp.security.ssh Nomen Nescio <nobody@dizum.com>:
> "Richard E. Silverman" <res@qoxp.net> wrote:

>> NN> Of course I know that ... what I mean is, can't the bot tell that
>> NN> the server only takes key authentication?

>> NN> What's the bot trying to send me, random big numbers?

>> No, it's likely still trying password authentication. The SSH-AUTH
>> protocol allows a client to try any authentication method it likes at any
>> point, regardless of whether the server accepts it. The attack program in
>> question probably just connects and tries passwords, without bothering to
>> notice whether password authentication is even supported.

> Now I see! My "normal" ssh client doesn't give me a paswsord option
> because the server has told it not to bother.

Not exactly, your client asks the sshd for key authentication
before password authentication if this succeeds, there is no need
for any other authentication, you are already logged in.

You can see this if you just try 'ssh -vvv remotehost'.

debug1: Authentications that can continue:
publickey,password,keyboard-interactive

^^^^^^^^^

As first.

--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo zvpunry@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 88: Boss' kid fucked up the machine

>>>>> "MH" == Michael Heiming <michael+USENET@www.heiming.de> writes:

MH> In comp.security.ssh Nomen Nescio <nobody@dizum.com>:
>> "Richard E. Silverman" <res@qoxp.net> wrote:

NN> Of course I know that ... what I mean is, can't the bot tell that
NN> the server only takes key authentication?

NN> What's the bot trying to send me, random big numbers?

>>> No, it's likely still trying password authentication. The
>>> SSH-AUTH protocol allows a client to try any authentication method
>>> it likes at any point, regardless of whether the server accepts
>>> it. The attack program in question probably just connects and
>>> tries passwords, without bothering to notice whether password
>>> authentication is even supported.

>> Now I see! My "normal" ssh client doesn't give me a paswsord option
>> because the server has told it not to bother.

MH> Not exactly, your client asks the sshd for key authentication
MH> before password authentication if this succeeds, there is no need
MH> for any other authentication, you are already logged in.

MH> You can see this if you just try 'ssh -vvv remotehost'.

It may or may not do this; it depends on the method order defined in the
client configuration with PreferredAuthentications.

MH> debug1: Authentications that can continue:
MH> publickey,password,keyboard-interactive
MH> ^^^^^^^^^

MH> As first.

This is actually irrelevant. The client is showing methods supported by
the server, in the order in which the server happens to list them. It
does not actually show the order in which it will try them. Play with
PreferredAuthentications a bit and you will see this.

--
Richard Silverman
res@qoxp.net

In comp.security.ssh Richard E. Silverman <res@qoxp.net>:
>>>>>> "MH" == Michael Heiming <michael+USENET@www.heiming.de> writes:

> MH> In comp.security.ssh Nomen Nescio <nobody@dizum.com>:
> >> "Richard E. Silverman" <res@qoxp.net> wrote:

> NN> Of course I know that ... what I mean is, can't the bot tell that
> NN> the server only takes key authentication?

> NN> What's the bot trying to send me, random big numbers?

> >>> No, it's likely still trying password authentication. The
> >>> SSH-AUTH protocol allows a client to try any authentication method
> >>> it likes at any point, regardless of whether the server accepts
> >>> it. The attack program in question probably just connects and
> >>> tries passwords, without bothering to notice whether password
> >>> authentication is even supported.

> >> Now I see! My "normal" ssh client doesn't give me a paswsord option
> >> because the server has told it not to bother.

> MH> Not exactly, your client asks the sshd for key authentication
> MH> before password authentication if this succeeds, there is no need
> MH> for any other authentication, you are already logged in.

> MH> You can see this if you just try 'ssh -vvv remotehost'.

> It may or may not do this; it depends on the method order defined in the
> client configuration with PreferredAuthentications.

Presuming zero client configuration, which seems fair, at least
the openssh client defaults to key authentication if it finds
some.

> MH> debug1: Authentications that can continue:
> MH> publickey,password,keyboard-interactive
> MH> ^^^^^^^^^

> MH> As first.

> This is actually irrelevant. The client is showing methods supported by
> the server, in the order in which the server happens to list them. It
> does not actually show the order in which it will try them. Play with
> PreferredAuthentications a bit and you will see this.

Indeed, but it goes on like this:

debug3: start over, passed a different list publickey,password,keyboard-interactive
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey

A little later:

debug1: Server accepts key: pkalg ssh-dss blen 433
[..]
debug1: Entering interactive session.

I trust you that the message was just showing the supported
methods.

Best regards

--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo zvpunry@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 394: Jupiter is aligned with Mars.