On Mon, 05 Apr 2010 10:01:08 +0100, Matthew Seaman wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 04/04/2010 22:04:35, Marcin Wisnicki wrote:
>> Is it possible to configure sshd such that both conditions are met:
>>
>> 1. Root will be able to login only by using keys 2. Normal u
orry its its been said already. As
> far as I knew the directive
> PermitRootLogin without-password
> in /etc/ssh/sshd_config
> should accomplish what was requested.
>
> However a note later in the default sshd_config file regarding the
> UsePAM setting says
> 'Dep
ard-interactive
>
> Only by running two instances of sshd on different ports / IP numbers.
>
I missed the rest of this thread so sorry its its been said already. As
far as I knew the directive
PermitRootLogin without-password
in /etc/ssh/sshd_config
should accomplish what was requested.
Ho
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/04/2010 22:04:35, Marcin Wisnicki wrote:
> Is it possible to configure sshd such that both conditions are met:
>
> 1. Root will be able to login only by using keys
> 2. Normal users will still be able to use pam/keyboard-interactive
Only by run
On 05/04/10 01:35, Marcin Wisnicki wrote:
PasswordAuthentication is already disabled (by default).
I need to disable ChallengeResponseAuthentication however:
/etc/ssh/sshd_config line 131: Directive 'ChallengeResponseAuthentication'
is not allowed within a Match block
Same
On Sun, 04 Apr 2010 23:49:59 +0200, Julian Fagir wrote:
> Hi,
>
>> Is it possible to configure sshd such that both conditions are met:
>>
>> 1. Root will be able to login only by using keys 2. Normal users will
>> still be able to use pam/keyboard-interactive
>
> perhaps the sshd-option "Permit
to restrict from where root can
> login with another match block.
>
PasswordAuthentication is already disabled (by default).
I need to disable ChallengeResponseAuthentication however:
/etc/ssh/sshd_config line 131: Directive 'ChallengeResponseAuthentication'
is not allow
On 04/04/2010 22:04, Marcin Wisnicki wrote:
Is it possible to configure sshd such that both conditions are met:
1. Root will be able to login only by using keys
Yes
2. Normal users will still be able to use pam/keyboard-interactive
Yes
see PermitRootLogin section in man sshd_config..
On 04/04/10 23:04, Marcin Wisnicki wrote:
Is it possible to configure sshd such that both conditions are met:
1. Root will be able to login only by using keys
2. Normal users will still be able to use pam/keyboard-interactive
Yes, you can create a Match block with the criteria User, something
On 4 April 2010 22:49, Julian Fagir wrote:
> Hi,
>
> > Is it possible to configure sshd such that both conditions are met:
> >
> > 1. Root will be able to login only by using keys
> > 2. Normal users will still be able to use pam/keyboard-interactive
>
> perhaps the sshd-option "PermitRootLogin"
Hi,
> Is it possible to configure sshd such that both conditions are met:
>
> 1. Root will be able to login only by using keys
> 2. Normal users will still be able to use pam/keyboard-interactive
perhaps the sshd-option "PermitRootLogin" does match your requirements.
To be found in sshd_config (
Is it possible to configure sshd such that both conditions are met:
1. Root will be able to login only by using keys
2. Normal users will still be able to use pam/keyboard-interactive
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.o
/GENERIC
amd64
together with ipfw. The problem I have is this, if I am on the box I can
restart my firewall with no problem, but when I log in remotely and
restart the firewall for reason I am locked out and can not ssh into it.
Below is the messages log:
Mar 25 14:51:04 panadine kernel: Trying to mount
alo.edu:/usr/obj/usr/src/sys/GENERIC
> > amd64
> > together with ipfw. The problem I have is this, if I am on the box I can
> > restart my firewall with no problem, but when I log in remotely and
> > restart the firewall for reason I am locked out and can not ssh into it.
> >
e problem I have is this, if I am on the box I can
> restart my firewall with no problem, but when I log in remotely and
> restart the firewall for reason I am locked out and can not ssh into it.
>
> Below is the messages log:
> Mar 25 14:51:04 panadine kernel: Trying to mount root
the box I can
restart my firewall with no problem, but when I log in remotely and
restart the firewall for reason I am locked out and can not ssh into it.
Below is the messages log:
Mar 25 14:51:04 panadine kernel: Trying to mount root from ufs:/dev/ad4s1a
Mar 25 14:51:04 panadine kernel: ipfw2
On Mar 10, 2010, at 11:59, Olivier Nicole
wrote:
Now Diffie-Hellman may help providing the trust for the fingerprint.
No it won't. Trust goes either via a trusted third party as in PKI or
the pgp chain of trust or via direct verification. In the latter case
if you cannot establish tr
Hi,
> > The pre-shared information need not to be secret ... but there is
> > need for pre-shared trusted information.
> Er, if the pre-shared information is not secret, how can I be sure
> that the person presenting it is in fact my intended correspondent
> and not a MIM?
That is why I wrote "tr
On 10/03/10 07:16, per...@pluto.rain.com wrote:
but logic tends to tell me that is I have no prior knowledge about
the person I am about to talk to, anybody (MIM) could pretend to
be that person.
True. Cryptography by it self does not solve the identity problem.
The pre-shared information ne
Olivier Nicole wrote:
> > What happened to Diffie-Hellman? Last I heard, its whole
> > point was to enable secure communication, protected from both
> > eavesdropping and MIM attacks, between systems having no prior
> > trust relationship (e.g. any sort of pre-shared secret) ...
>
> I am not expe
On Tue, Mar 9, 2010 at 12:48 AM, Olivier Nicole wrote:
> > What happened to Diffie-Hellman? Last I heard, its whole point was
> > to enable secure communication, protected from both eavesdropping
> > and MIM attacks, between systems having no prior trust relationship
> > (e.g. any sort of pre-sh
> What happened to Diffie-Hellman? Last I heard, its whole point was
> to enable secure communication, protected from both eavesdropping
> and MIM attacks, between systems having no prior trust relationship
> (e.g. any sort of pre-shared secret). What stops the server and
> client from establishi
Angelin Lalev wrote:
> So, SSH uses algorithms like ssh-dss or ssh-rsa to do key exchange.
> These algorithms can defeat any attempts on eavesdropping, but cannot
> defeat man-in-the-middle attacks. To defeat them, some pre-shared
> information is needed - key fingerprint.
What
> The output is written to be used with packet filter, if you use some other
> firewall you may need edit the script. If you use packet filter, then you
> can dump the list into a file and create tables like this:
>
> table persist file "/etc/blacklist"
> block in qui
tables like this:
table persist file "/etc/blacklist"
block in quick from
I use blacklisting for mail while I use whitelisting for ssh.
You should know the limits of the script, the problem is that some
ranges have been assigned directly by IANA, particularly for US. Thes
On Sun, Mar 7, 2010 at 3:25 PM, Angelin Lalev wrote:
> Greetings,
>
> I'm doing some research into ssh and its underlying cryptographic
> methods and I have questions. I don't know whom else to ask and humbly
> ask for forgiveness if I'm way OT.
>
> So, SSH use
Angelin Lalev writes:
;2~> On Sun, Mar 7, 2010 at 11:25 PM, Angelin Lalev
wrote:
>> Greetings,
>>
>> I'm doing some research into ssh and its underlying cryptographic
>> methods and I have questions. I don't know whom else to ask and humbly
>> ask f
are running and determine which
> services are running on each port. In that case running ssh on a
> non-standard port is futile.
>
> However, I'm not really a fan of using non-standard ports for ssh, I don't
> believe it's the right solution to the problem: You have ssh
se he will scan large ip-ranges for hosts listening on
port 22.
b. The attacker wants to gain control of a particular server. In that
case he will scan all ports to see what services are running and
determine which services are running on each port. In that case running
ssh on a non-standard po
On Sun, Mar 7, 2010 at 11:25 PM, Angelin Lalev wrote:
> Greetings,
>
> I'm doing some research into ssh and its underlying cryptographic
> methods and I have questions. I don't know whom else to ask and humbly
> ask for forgiveness if I'm way OT.
>
> So, SSH
Greetings,
I'm doing some research into ssh and its underlying cryptographic
methods and I have questions. I don't know whom else to ask and humbly
ask for forgiveness if I'm way OT.
So, SSH uses algorithms like ssh-dss or ssh-rsa to do key exchange.
These algorithms can defeat
+++ Erik Norgaard [06/03/10 02:44 +0100]:
On 05/03/10 13:54, John wrote:
My nightly security logs have thousands upon thousands of ssh probes
in them. One day, over 6500. This is enough that I can actually
"feel" it in my network performance. Other than changing ssh to
a non-sta
> "Matthew" == Matthew Seaman writes:
Matthew> On the whole, I don't see the value in having a high-numbered MX to
Matthew> dumbly accept, queue and forward messages like this.
High-numbered MX came from a time where an internal machine could
only be delivered from outside via an external ga
On Sat, 6 Mar 2010, Matthew Seaman wrote:
> On 06/03/2010 06:33:53, Ian Smith wrote:
> > In freebsd-questions Digest, Vol 300, Issue 10, Message: 6
> > On Fri, 05 Mar 2010 16:07:29 + Matthew Seaman
> > wrote:
> > > On 05/03/2010 15:51:52, Randal L. Schwartz wrote:
> > > > The spamtrap
On Mar 6, 2010, at 4:36 AM, Matthew Seaman wrote:
Having an IPv6-only high-mx seems to terminally confuse most
spambots...
I understand why IPv6 would confuse them, but don't follow why higher
numbered MXs would be more attractive to them in the first place?
Are they assuming a 'secondary' MX
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/03/2010 06:33:53, Ian Smith wrote:
> In freebsd-questions Digest, Vol 300, Issue 10, Message: 6
> On Fri, 05 Mar 2010 16:07:29 + Matthew Seaman
> wrote:
> > On 05/03/2010 15:51:52, Randal L. Schwartz wrote:
> > > The spamtrap is a shiny o
In freebsd-questions Digest, Vol 300, Issue 10, Message: 6
On Fri, 05 Mar 2010 16:07:29 + Matthew Seaman
wrote:
> On 05/03/2010 15:51:52, Randal L. Schwartz wrote:
> > The spamtrap is a shiny object for spam, and anything that goes there gets
> > blocked for an hour from hitting the low po
That was just the quick summary. Google for "PPTP security" and you'll
see a top link from Bruce Schneier who basically says no way to it.
Sent from my iPhone, so blame Steve Jobs for any speeling misteaks.
On Mar 5, 2010, at 9:20 PM, Tim Judd wrote:
..wikipedia? that's informative and use
urity.
>
Randal,
It's not meant as the solution for remote access. It's only a
stopgap so you can ssh into your router and add the remote IP. Then
disconnect from the VPN you've configured, PPTP or not, and use SSH.
And the fact that I haven't (yet) seen random bo
On 3/5/2010 7:44 PM, Erik Norgaard wrote:
> On 05/03/10 13:54, John wrote:
>> My nightly security logs have thousands upon thousands of ssh probes
>> in them. One day, over 6500. This is enough that I can actually
>> "feel" it in my network performance. Othe
On 05/03/10 13:54, John wrote:
My nightly security logs have thousands upon thousands of ssh probes
in them. One day, over 6500. This is enough that I can actually
"feel" it in my network performance. Other than changing ssh to
a non-standard port - is there a way to deal with the
Randal L. Schwartz wrote:
"Tim" == Tim Judd writes:
Tim> I've been in that same boat. I eventually came to the decision to:
Tim> Install PPTP server software, accepting connections from any IP.
Whoa. Here we are, talking about making it *more* secure, and
you go the other direction
> "Tim" == Tim Judd writes:
Tim> I've been in that same boat. I eventually came to the decision to:
Tim> Install PPTP server software, accepting connections from any IP.
Whoa. Here we are, talking about making it *more* secure, and
you go the other direction
http://en.wikipedia.org
On 05/03/2010 13:26, John wrote:
Ah, I should have added that I travel a fair amount, and often
have to get to my systems via hotel WiFi or Aircard, so it's
impossible to predict my originating IP address in advance. If
that were not the case, this would be an excellent suggestion.
What about
Matthew Seaman wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/03/2010 16:12:11, Randal L. Schwartz wrote:
"Matthew" == Matthew Seaman writes:
Matthew> On 05/03/2010 15:51:52, Randal L. Schwartz wrote:
The spamtrap is a shiny object for spam, and anything that goes there gets
bloc
Replies interspersed
On 3/5/10, John wrote:
> On Fri, Mar 05, 2010 at 07:03:53AM -0600, Programmer In Training wrote:
>> On 03/05/10 06:54, John wrote:
>> > My nightly security logs have thousands upon thousands of ssh probes
>> > in them. One day, over 6500. This is
Thousands of ssh probes
Friday, March 5, 2010 1:54 PM
From:
"John"
To:
freebsd-questions@freebsd.org
My nightly security logs have thousands upon thousands of ssh probes
in them. One day, over 6500. This is enough that I can actually
"feel" it in my network performance.
to tcp from to any label "ssh
bruteforce" probability 85%
So I let 15% of the pakets through in the hope that will slow down this
brute force attacks and I can protect in this step other hosts.
Hopefully the attacker keeps then longer in my tarpit.
Bye
Matthias
--
"Programming to
; >> [...near the top of the rules section...]
> >> block drop in log quick on $ext_if from
> >>
> >> [...later in the rules section...]
> >> pass in on $ext_if proto tcp \
> >> from any to $ext_if port ssh \
> >> flags S/SA kee
>> [...later in the rules section...]
>> pass in on $ext_if proto tcp \
>> from any to $ext_if port ssh \
>> flags S/SA keep state\
>> (max-src-conn-rate 3/30, overload flush global)
>>
>
> that is dangarous, if you use subve
section...]
> >pass in on $ext_if proto tcp \
> > from any to $ext_if port ssh \
> > flags S/SA keep state\
> > (max-src-conn-rate 3/30, overload flush global)
> >
>
> that is dangarous, if you use subversion over ssh you will somet
Hi,
Am 05.03.10 17:01, schrieb Matthew Seaman:
table persist
[...near the top of the rules section...]
block drop in log quick on $ext_if from
[...later in the rules section...]
pass in on $ext_if proto tcp \
from any to $ext_if port ssh \
flags S/SA keep state
ect into a PF firewall
> and have it open up extra access for you, all controlled by ssh keys.
>
> See: http://www.openbsd.org/faq/pf/authpf.html
>
> Not only that, but you can dynamically block brute force attempts to
> crack SSH passwords using just PF -- no need to scan
them to the rule set and clear the change flag. Using this
combination I was able to allow ssh access only to the necessary ip
addresses.
We use a similar approach but only rely on tcpwrappers.
Here's what we do (simplified & obfuscated slightly), just
for reference (or, maybe comme
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/03/2010 16:12:11, Randal L. Schwartz wrote:
>> "Matthew" == Matthew Seaman writes:
>
> Matthew> On 05/03/2010 15:51:52, Randal L. Schwartz wrote:
>>> The spamtrap is a shiny object for spam, and anything that goes there gets
>>> blocked for
> "Matthew" == Matthew Seaman writes:
Matthew> On 05/03/2010 15:51:52, Randal L. Schwartz wrote:
>> The spamtrap is a shiny object for spam, and anything that goes there gets
>> blocked for an hour from hitting the low port. I presented this at a
>> conference once.
Matthew> Having an IPv6-
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/03/2010 15:51:52, Randal L. Schwartz wrote:
> The spamtrap is a shiny object for spam, and anything that goes there gets
> blocked for an hour from hitting the low port. I presented this at a
> conference once.
Having an IPv6-only high-mx seems
eally like this. I may have to implement it for pf.
> It should be really easy with CGI and calls to pfctl.
There's already a mechanism whereby you can connect into a PF firewall
and have it open up extra access for you, all controlled by ssh keys.
See: http://www.openbsd.org/faq/pf/auth
firewall update daemon) connected to the
db
and ran a query to check for any rule changes. If there were it would
apply them to the rule set and clear the change flag. Using this
combination I was able to allow ssh access only to the necessary ip
addresses.
I kind of scrapped it when VPNs became
> "John" == John writes:
John> Yes - that's exactly what I used to do, and exactly why I used to do
John> it, but now I'm thinking of actually implement https.
Rent more than one IP. :) I have a block of 8 for exactly that reason.
It allows me to run sshd on 443 *and* https on a different
is false security.
>
> It's equivalent to adding precisely two bytes (per knock, which can't
> be too close or far apart or numerous) to the key length.
>
> Are you really thinking that increasing your key length from 2048 to 2050
> helps?
>
> The right solution
t
be too close or far apart or numerous) to the key length.
Are you really thinking that increasing your key length from 2048 to 2050
helps?
The right solution is proper ssh key management, and intrusion detection, and
if you insist on having password access, use one-time passwords and/or
strength
On Fri, Mar 05, 2010 at 10:19:09AM -0500, mikel king wrote:
>
> On Mar 5, 2010, at 8:26 AM, John wrote:
>
> >On Fri, Mar 05, 2010 at 07:03:53AM -0600, Programmer In Training
> >wrote:
> >>On 03/05/10 06:54, John wrote:
> >>>My nightly security logs h
On Mar 5, 2010, at 8:26 AM, John wrote:
On Fri, Mar 05, 2010 at 07:03:53AM -0600, Programmer In Training
wrote:
On 03/05/10 06:54, John wrote:
My nightly security logs have thousands upon thousands of ssh probes
in them. One day, over 6500. This is enough that I can actually
"feel&q
Hello John,
I would suggest you just block ssh acces for everyone.
But, to allow acces for yourself - you could install wonderfull
utility = 'knock-knock'.
It listen on specified ports (they could be closed), and, on receiving
p= redefined knock-knock (for example
On 2010-03-05 13:54, John wrote:
My nightly security logs have thousands upon thousands of ssh probes
in them. One day, over 6500. This is enough that I can actually
"feel" it in my network performance. Other than changing ssh to
a non-standard port - is there a way to deal
On Fri, Mar 05, 2010 at 07:03:53AM -0600, Programmer In Training wrote:
> On 03/05/10 06:54, John wrote:
> > My nightly security logs have thousands upon thousands of ssh probes
> > in them. One day, over 6500. This is enough that I can actually
> > "feel" it in
John writes:
> My nightly security logs have thousands upon thousands of ssh
> probes in them. One day, over 6500. This is enough that I can
> actually "feel" it in my network performance. Other than
> changing ssh to a non-standard port - is there a way to deal wit
On Fri, Mar 5, 2010 at 2:54 PM, John wrote:
> My nightly security logs have thousands upon thousands of ssh probes
> in them. One day, over 6500. This is enough that I can actually
> "feel" it in my network performance. Other than changing ssh to
> a non-standard port -
On 03/05/10 06:54, John wrote:
> My nightly security logs have thousands upon thousands of ssh probes
> in them. One day, over 6500. This is enough that I can actually
> "feel" it in my network performance. Other than changing ssh to
> a non-standard port - is there a
My nightly security logs have thousands upon thousands of ssh probes
in them. One day, over 6500. This is enough that I can actually
"feel" it in my network performance. Other than changing ssh to
a non-standard port - is there a way to deal with these? Every
day, they originate fr
Hi again,
> I have this weird error since yesterday, one a system that used to be
> working nicely, suddenly:
>
> ssh cores dump when run as non priviledged user, works fine for root
> sshd aborts on signal 11
> [... see my previous mails?]
This seems to be a problem linked t
Hi again,
> I have this weird error since yesterday, one a system that used to be
> working nicely, suddenly:
>
> ssh cores dump when run as non priviledged user, works fine for root
> sshd aborts on signal 11
>
> I tried to reinstall world, but it is the same.
>
>
Hi,
I have this weird error since yesterday, one a system that used to be
working nicely, suddenly:
ssh cores dump when run as non priviledged user, works fine for root
sshd aborts on signal 11
I tried to reinstall world, but it is the same.
There is openssl installed from the ports on that
On Wed, Jan 20, 2010 at 10:49:09PM -0500, Aryeh M. Friedman wrote:
> I need to set up a machine so that I can type "ssh [host]" as root from
> some other host and I get a prompt with super user privs... I already
> have set this up for u...@host for root and ssh host for nor
On Wed, Jan 20, 2010 at 11:09:14PM -0500, Steve Bertrand typed:
> Aryeh M. Friedman wrote:
> > I need to set up a machine so that I can type "ssh [host]" as root from
> > some other host and I get a prompt with super user privs... I already
> > have set this up for
I need to set up a machine so that I can type "ssh [host]" as root from
some other host and I get a prompt with super user privs... I already
have set this up for u...@host for root and ssh host for normal users...
but root still asks for a password after I set the authorized_key
Aryeh M. Friedman wrote:
> I need to set up a machine so that I can type "ssh [host]" as root from
> some other host and I get a prompt with super user privs... I already
> have set this up for u...@host for root and ssh host for normal users...
> but root still asks for a pa
Hi,
Aryeh M. Friedman wrote:
> I need to set up a machine so that I can type "ssh [host]" as root from
> some other host and I get a prompt with super user privs... I already
> have set this up for u...@host for root and ssh host for normal users...
> but root still ask
I need to set up a machine so that I can type "ssh [host]" as root from
some other host and I get a prompt with super user privs... I already
have set this up for u...@host for root and ssh host for normal users...
but root still asks for a password after I set the authorized_key
On Tue, Jan 12, 2010 at 11:36:11PM +0100, Erik Norgaard wrote:
> Anton Shterenlikht wrote:
>
> >> - why not let your firewall do the blocking? If your blocking is IP
> >> based that's the place to block.
> >
> > I'm already under the University firewall. Only port 22 is let through.
> > But even
Anton Shterenlikht wrote:
- why not let your firewall do the blocking? If your blocking is IP
based that's the place to block.
I'm already under the University firewall. Only port 22 is let through.
But even that filles my logs.
What I meant was that if you want to block IPs or ranges of IPs
On Tue, Jan 12, 2010 at 10:42:06AM +0100, Erik Norgaard wrote:
> Anton Shterenlikht wrote:
> > I'm thinking of denying ssh access to host from which
> > I get brute force ssh attacks.
>
> This is a returning topic, search the archives. Anyway, the returning
> an
Anton Shterenlikht wrote:
I'm thinking of denying ssh access to host from which
I get brute force ssh attacks.
This is a returning topic, search the archives. Anyway, the returning
answer:
- why not let your firewall do the blocking? If your blocking is IP
based that's the plac
On Mon, Jan 11, 2010 at 7:01 AM, Anton Shterenlikht wrote:
> I'm thinking of denying ssh access to host from which
> I get brute force ssh attacks.
>
> HOwever, I see in /etc/hosts.allow:
>
> # Wrapping sshd(8) is not normally a good idea, but if you
> # need to
I had the same ssh-bruteforce troubles.
Here's the script I use against that.
It's in cron, launched every 2 minutes.
#!/bin/sh
AUTH=/var/log/auth.log
BKLST=/var/log/blacklist.log
HOSTS=/etc/hosts
DHOSTS=/etc/hosts.deny
cat $AUTH | egrep -i "(illegal|invalid|failed)" | awk
Anton Shterenlikht writes:
> I'm very grateful for all advice, but I'm still unsure
> why denying ssh access to a particular host via /etc/hosts.allow
> is a bad idea.
As far as I recall, the reason the warning was added to the manual was
that it's fairly heavy on res
On Mon, Jan 11, 2010 at 03:25:04PM +, Matthew Seaman wrote:
> Anton Shterenlikht wrote:
> > I'm thinking of denying ssh access to host from which
> > I get brute force ssh attacks.
> >
> > HOwever, I see in /etc/hosts.allow:
> >
> > # Wrapping ssh
Anton Shterenlikht wrote:
I'm thinking of denying ssh access to host from which
I get brute force ssh attacks.
HOwever, I see in /etc/hosts.allow:
# Wrapping sshd(8) is not normally a good idea, but if you
# need to do it, here's how
#sshd : .evil.cracker.example.com : deny
Why i
Tim Judd wrote:
I've been meaning to check this out. My firewall ssh rules are very
strict, in fact, if the remote IP is "unknown" meaning, I don't know
where the heck it's coming from, it's blocked. It's easier to say it
this way: I allow ssh connections
On Mon, Jan 11, 2010 at 07:18:04AM -0700, Tim Judd wrote:
> On 1/11/10, David Southwell wrote:
> >> I'm thinking of denying ssh access to host from which
> >> I get brute force ssh attacks.
> >>
> >> HOwever, I see in /etc/hosts.allow:
> >>
>
On 1/11/10, David Southwell wrote:
>> I'm thinking of denying ssh access to host from which
>> I get brute force ssh attacks.
>>
>> HOwever, I see in /etc/hosts.allow:
>>
>> # Wrapping sshd(8) is not normally a good idea, but if yo
David Southwell wrote:
I'm thinking of denying ssh access to host from which
I get brute force ssh attacks.
HOwever, I see in /etc/hosts.allow:
# Wrapping sshd(8) is not normally a good idea, but if you
# need to do it, here's how
#sshd : .evil.cracker.example.com : deny
Why is it
> I'm thinking of denying ssh access to host from which
> I get brute force ssh attacks.
>
> HOwever, I see in /etc/hosts.allow:
>
> # Wrapping sshd(8) is not normally a good idea, but if you
> # need to do it, here's how
> #sshd : .evil.cracker.example.com : d
I'm thinking of denying ssh access to host from which
I get brute force ssh attacks.
HOwever, I see in /etc/hosts.allow:
# Wrapping sshd(8) is not normally a good idea, but if you
# need to do it, here's how
#sshd : .evil.cracker.example.com : deny
Why is it not a good idea?
Also,
2010/1/1 J65nko
> After some posts a discussion on the freebsd-table mailing list goes into
> several approaches to deal with these SSH probes.
>
> See
> http://lists.freebsd.org/pipermail/freebsd-stable/2009-December/053326.html
>
> You still could allow outgoing ssh t
After some posts a discussion on the freebsd-table mailing list goes into
several approaches to deal with these SSH probes.
See http://lists.freebsd.org/pipermail/freebsd-stable/2009-December/053326.html
You still could allow outgoing ssh traffic on port 22 and allow
incoming SSH on another port
David Rawling wrote:
> On 2/01/2010 2:07 AM, J.D. Bronson wrote:
>> Few options I can think of in random order...I use #1:
>>
>> 1. Run SSH on an obscure port. Seriously, thats one of the easiest
>> things to do. Since I have done that, I have had ZERO attempts and it
&g
On Fri, Jan 1, 2010 at 8:56 AM, David Rawling wrote:
> I tend to think there's not much I can do about this, but I'll ask anyway.
>
> I've implemented sshguard to block the normal bruteforce attacks - which
> seems to be working reasonably well.
>
> However now I have the following:
>
> Jan 1 17
On 1/1/10 9:19 AM, David Rawling wrote:
Darn.
1 is out because 22 is the one port that most organisations (including
mine) allow out of their networks for administering routers.
2 is unfortunately not an option (as a consultant I do work from many
networks)
4 - again I might have to log in any
201 - 300 of 2823 matches
Mail list logo
