Assigning ssh to a different port number is not worth too much
security-wise, is it? If the access rate to the machine is typical,
all 65536 ports could be scanned first for a hot ssh connection in a
matter of minutes or even seconds, no?
--
% Randy Yates % "And all that I can do
%% Fuquay-Varina, NC % is say I'm sorry,
%%% 919-577-9882 % that's the way it goes..."
%%%% <yates@ieee.org> % Getting To The Point', *Balance of Power*, ELO
http://home.earthlink.net/~yatescr

On Thu, 02 Aug 2007 20:46:20 -0400, Randy Yates wrote:
> Assigning ssh to a different port number is not worth too much
> security-wise, is it?

Only to lower login attempts from script kiddies.

> all 65536 ports could be scanned first for a hot ssh connection in a
> matter of minutes or even seconds, no?

True, but I have not seen full port scans in awhile. I have seen a sneaky
cracker picking 1 or two new ports once or twice a week trying to stay
under my radar.

On 3 Aug, 04:52, comph...@toddh.net (Todd H.) wrote:
> Randy Yates <ya...@ieee.org> writes:
> > Assigning ssh to a different port number is not worth too much
> > security-wise, is it? If the access rate to the machine is typical,
> > all 65536 ports could be scanned first for a hot ssh connection in a
> > matter of minutes or even seconds, no?
>
> Practically, if you move to a non-standard port you'll see denied
> attempts to connect drop nearly to 0 in your connection logs, leaving
> you with a lot less shit to sift through as you regularly review your
> logfiles.
>
> Leave it on 22 and you'll have all the freaking script kiddie stuff
> brute force guessing ya 24/7.

Bingo. cluttering your logs is really irritating, and should only be
encouraged if you're an aggressive administrator running a honey pot
to trap and report the little vermin.

Port knocking is sweet to avoid just this problem, fortunately.

Randy Yates <yates@ieee.org> writes:

> Assigning ssh to a different port number is not worth too much
> security-wise, is it? If the access rate to the machine is typical,
> all 65536 ports could be scanned first for a hot ssh connection in a
> matter of minutes or even seconds, no?

Practically, if you move to a non-standard port you'll see denied
attempts to connect drop nearly to 0 in your connection logs, leaving
you with a lot less shit to sift through as you regularly review your
logfiles.

Leave it on 22 and you'll have all the freaking script kiddie stuff
brute force guessing ya 24/7.


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

Nico wrote:
> On 3 Aug, 04:52, comph...@toddh.net (Todd H.) wrote:
>> Randy Yates <ya...@ieee.org> writes:
>>> Assigning ssh to a different port number is not worth too much
>>> security-wise, is it? If the access rate to the machine is typical,
>>> all 65536 ports could be scanned first for a hot ssh connection in a
>>> matter of minutes or even seconds, no?
>> Practically, if you move to a non-standard port you'll see denied
>> attempts to connect drop nearly to 0 in your connection logs, leaving
>> you with a lot less shit to sift through as you regularly review your
>> logfiles.
>>
>> Leave it on 22 and you'll have all the freaking script kiddie stuff
>> brute force guessing ya 24/7.

It's convenient to have it on the default port. If you use
public/private key authentication no script kiddie is ever going to
guess your private key and you can simply use a decent log filter.

Nico wrote:
> On 3 Aug, 04:52, comph...@toddh.net (Todd H.) wrote:
>> Randy Yates <ya...@ieee.org> writes:
>>> Assigning ssh to a different port number is not worth too much
>>> security-wise, is it? If the access rate to the machine is typical,
>>> all 65536 ports could be scanned first for a hot ssh connection in a
>>> matter of minutes or even seconds, no?
>> Practically, if you move to a non-standard port you'll see denied
>> attempts to connect drop nearly to 0 in your connection logs, leaving
>> you with a lot less shit to sift through as you regularly review your
>> logfiles.
>>
>> Leave it on 22 and you'll have all the freaking script kiddie stuff
>> brute force guessing ya 24/7.

It's convenient to have it on the default port. If you use
public/private key authentication no script kiddie is ever going to
guess your private key and you can simply use a decent log filter.

Steven Mocking <ufo@quicknet.youmightwanttogetridofthis.nl> writes:

> Nico wrote:
> > On 3 Aug, 04:52, comph...@toddh.net (Todd H.) wrote:
> >> Randy Yates <ya...@ieee.org> writes:
> >>> Assigning ssh to a different port number is not worth too much
> >>> security-wise, is it? If the access rate to the machine is typical,
> >>> all 65536 ports could be scanned first for a hot ssh connection in a
> >>> matter of minutes or even seconds, no?
> >> Practically, if you move to a non-standard port you'll see denied
> >> attempts to connect drop nearly to 0 in your connection logs, leaving
> >> you with a lot less shit to sift through as you regularly review your
> >> logfiles.
> >>
> >> Leave it on 22 and you'll have all the freaking script kiddie stuff
> >> brute force guessing ya 24/7.
>
> It's convenient to have it on the default port. If you use
> public/private key authentication no script kiddie is ever going to
> guess your private key and you can simply use a decent log filter.


That's a personal choice of course. Myself I'd cheerfully add a -p
argument versus having to slog through script kiddies filling up logs
(or me having to have incomplete logs) if it can be avoided.

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

Steven Mocking <ufo@quicknet.youmightwanttogetridofthis.nl> writes:

> Nico wrote:
> > On 3 Aug, 04:52, comph...@toddh.net (Todd H.) wrote:
> >> Randy Yates <ya...@ieee.org> writes:
> >>> Assigning ssh to a different port number is not worth too much
> >>> security-wise, is it? If the access rate to the machine is typical,
> >>> all 65536 ports could be scanned first for a hot ssh connection in a
> >>> matter of minutes or even seconds, no?
> >> Practically, if you move to a non-standard port you'll see denied
> >> attempts to connect drop nearly to 0 in your connection logs, leaving
> >> you with a lot less shit to sift through as you regularly review your
> >> logfiles.
> >>
> >> Leave it on 22 and you'll have all the freaking script kiddie stuff
> >> brute force guessing ya 24/7.
>
> It's convenient to have it on the default port. If you use
> public/private key authentication no script kiddie is ever going to
> guess your private key and you can simply use a decent log filter.


That's a personal choice of course. Myself I'd cheerfully add a -p
argument versus having to slog through script kiddies filling up logs
(or me having to have incomplete logs) if it can be avoided.

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

On 7 Aug, 21:50, Steven Mocking
<u...@quicknet.youmightwanttogetridofthis.nl> wrote:

> It's convenient to have it on the default port. If you use
> public/private key authentication no script kiddie is ever going to
> guess your private key and you can simply use a decent log filter.


Script kiddies steal keys, especially the passphrase-free keys so
common for people who don't bother to use keychain or Pageant or ssh-
agent. I've seen it used extensively in corporate networks, and sent
nastygrams to people about such keys left in NFS mounted directories.

On 7 Aug, 21:50, Steven Mocking
<u...@quicknet.youmightwanttogetridofthis.nl> wrote:

> It's convenient to have it on the default port. If you use
> public/private key authentication no script kiddie is ever going to
> guess your private key and you can simply use a decent log filter.


Script kiddies steal keys, especially the passphrase-free keys so
common for people who don't bother to use keychain or Pageant or ssh-
agent. I've seen it used extensively in corporate networks, and sent
nastygrams to people about such keys left in NFS mounted directories.

Nico <nkadel@gmail.com> writes:

> On 7 Aug, 21:50, Steven Mocking
> <u...@quicknet.youmightwanttogetridofthis.nl> wrote:
>
>> It's convenient to have it on the default port. If you use
>> public/private key authentication no script kiddie is ever going to
>> guess your private key and you can simply use a decent log filter.
>
>
> Script kiddies steal keys, especially the passphrase-free keys so
> common for people who don't bother to use keychain or Pageant or ssh-
> agent. I've seen it used extensively in corporate networks, and sent
> nastygrams to people about such keys left in NFS mounted directories.

That's an excellent point, and an attack I hadn't thought of protecting
against until you mentioned it.

So, it you DO use a passphrase to protect your keys, then the chance of
a successful attack are about the same as guessing your account password?
In other words, the two forms of authentication are of equivalent strengths
(when passphrases are used)?
--
% Randy Yates % "The dreamer, the unwoken fool -
%% Fuquay-Varina, NC % in dreams, no pain will kiss the brow..."
%%% 919-577-9882 %
%%%% <yates@ieee.org> % 'Eldorado Overture', *Eldorado*, ELO
http://home.earthlink.net/~yatescr

>>>>> "RY" == Randy Yates <yates@ieee.org> writes:

RY> Nico <nkadel@gmail.com> writes:
>> On 7 Aug, 21:50, Steven Mocking
>> <u...@quicknet.youmightwanttogetridofthis.nl> wrote:
>>
>>> It's convenient to have it on the default port. If you use
>>> public/private key authentication no script kiddie is ever going
>>> to guess your private key and you can simply use a decent log
>>> filter.
>>
>>
>> Script kiddies steal keys, especially the passphrase-free keys so
>> common for people who don't bother to use keychain or Pageant or
>> ssh- agent. I've seen it used extensively in corporate networks,
>> and sent nastygrams to people about such keys left in NFS mounted
>> directories.

RY> That's an excellent point, and an attack I hadn't thought of
RY> protecting against until you mentioned it.

RY> So, it you DO use a passphrase to protect your keys, then the
RY> chance of a successful attack are about the same as guessing your
RY> account password? In other words, the two forms of authentication
RY> are of equivalent strengths (when passphrases are used)

I'd say that overall, publickey is stronger, but there are other
differences. Remember, publickey is effectively two-factor; it requires
your private key file, as well as your passphrase. A pure guessing attack
may succeed against your password; it will not succeed against your
private key. If the attacker gets your private key file, then the two are
of similar difficulty, but still not the same. To guess your password, an
attacker must reveal himself by making many login attempts, whereas a
guessing attack against your key passphrase is purely offline. On the other
hand, when using password authentication, you reveal your password to a
possbily compromised server; publickey authentication does not reveal your
private key in the same way.

--
Richard Silverman
res@qoxp.net

On 9 Aug, 23:07, "Richard E. Silverman" <r...@qoxp.net> wrote:
> >>>>> "RY" == Randy Yates <ya...@ieee.org> writes:
>
> RY> Nico <nka...@gmail.com> writes:
> >> On 7 Aug, 21:50, Steven Mocking
> >> <u...@quicknet.youmightwanttogetridofthis.nl> wrote:
> >>
> >>> It's convenient to have it on the default port. If you use
> >>> public/private key authentication no script kiddie is ever going
> >>> to guess your private key and you can simply use a decent log
> >>> filter.
> >>
> >>
> >> Script kiddies steal keys, especially the passphrase-free keys so
> >> common for people who don't bother to use keychain or Pageant or
> >> ssh- agent. I've seen it used extensively in corporate networks,
> >> and sent nastygrams to people about such keys left in NFS mounted
> >> directories.
>
> RY> That's an excellent point, and an attack I hadn't thought of
> RY> protecting against until you mentioned it.
>
> RY> So, it you DO use a passphrase to protect your keys, then the
> RY> chance of a successful attack are about the same as guessing your
> RY> account password? In other words, the two forms of authentication
> RY> are of equivalent strengths (when passphrases are used)
>
> I'd say that overall, publickey is stronger, but there are other
> differences. Remember, publickey is effectively two-factor; it requires
> your private key file, as well as your passphrase. A pure guessing attack
> may succeed against your password; it will not succeed against your
> private key. If the attacker gets your private key file, then the two are
> of similar difficulty, but still not the same. To guess your password, an
> attacker must reveal himself by making many login attempts, whereas a
> guessing attack against your key passphrase is purely offline. On the other
> hand, when using password authentication, you reveal your password to a
> possbily compromised server; publickey authentication does not reveal your
> private key in the same way.

And Richard is one of the serious authorities on OpenSSH. (Hi,
Richard!)

If an attacker gets your private and public keys, as is commonly
available on NFS shared networks in the user's own $HOME/.ssh
directory or in places where fools make their home directories world
readable and turn off the sshd security settings related to this, "in
order to share work", then the cracker can test the keys and possible
passwords for the private keys on their own. And I've seen such
practices in corporate networks, along with personal using their own
last names as both their logins and passwords, and lacked the
corporate authority to slap them in the head and make them change it.

One of the big advantages of SSH in this regard over the older crypt
style passwords is that it takes freaking *time* to check each key
against a list of likely passphrases, vastly more time than the old
crypt approach. The world's most common passphrase is "love". There's
an old tool called "crack" by Alec Moffett that was wonderful at
guessing weak passwords. I used to use crack against the stored FTP
server password file to make the point that that system *could not* be
considered secure, and gain leverage to set up a real HTTPS based
service using an actual Kerberized back end that enforced some
password security.