Re: SSHD defaults

From: Nico Kadel-Garcia (nkadel@bellatlantic.net)
Date: 06/24/02


From: "Nico Kadel-Garcia" <nkadel@bellatlantic.net>
Date: Mon, 24 Jun 2002 02:21:34 GMT


"teLi" <route@null0.null> wrote in message
news:_2uR8.34684$Tu6.4420462@typhoon.austin.rr.com...
> I know the default key size is 768 bits with OpenSSH. Is it possible to
> change this value from 768 to 1024? If I'm not mistaken, 1024 bits
encrypts
> the key while 768 sends it as plain text. Correct me if I am wrong,
please.
>
> Also, I was reading Hacking Linux Exposed and it said I should change
> RSAAuthentication to "no" because this is an insecure method of
> authentication because it doesen't require the user's password if someone
> just copies the key from .ssh/authorized_keys. I'm a little confused about
> that. I use SSH-1.99-OpenSSH_3.1p1.

That.... Sounds wrong.

For everyb key a user has, there is the private part (such as .ssh/identity)
and the public part (.ss/identity.pub). The public part is copied to the
.ssh/authorized_keys file on the target, and this allows the user with the
private key in his ssh-agent or accessed by the ssh client to get into the
system without insisting on keys.

Key length has next to nothing to do with whether the key is sent encrypted
or not, near as I can tell. It's just a parameter you can set, with a
minimum length of 512. It's selected to be *convenient*: large enough to be
unreasonably difficult to crack by brute force, and short enough to not suck
up all the computational resources of your client and server, both.

Now, it's quite true that one can copy keys *INTO* someone else's
.ssh/authorized_keys file, thus gaining arbitrary access to their account.
This is particularly true of NFS based home directories: people on any NFS
client can become root locally, "su" to become the user in question, and
edit that user's mounted home directories. This is why I try so hard to
explain to people that having a firewall does not protect you fully: it only
takes one hole for people to really hack your systems.

> Basically I am a little woried about sshd's configuration file defaults.
I'd
> like to tweak them to the most secure possible settings. The method of
> authentication I plan to use is username/password.
>
> Any feedback would be appreciated.

Go for it: of course, you won't be able to run automated scripts to
communicate among your machines this way. So rsyncing or running remote
probes or easily administering a lot of machines from a tightly controlled
server becomes much more problematical.



Relevant Pages

  • Re: SSHD defaults
    ... up all the computational resources of your client and server, ... This is particularly true of NFS based home directories: ... communicate among your machines this way. ...
    (comp.os.linux.security)
  • Re: Passing username/password in a secure way on a Remoting call
    ... client authentication, with the second phase being optional. ... phase, the server, in response to a client's request, sends its certificate ... encrypts with the server's public key, ... The server recovers the master key and authenticates ...
    (microsoft.public.dotnet.security)
  • Re: Is Double Encryption in possible in C#/.NET
    ... > Instead of encrypting the symmetric key twice, what you are looking for is ... > Assuming client/server have already exchanged public keys, ... > a message to the client it: ... >> server encrypts the symmetric key first using its private key and then ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Wireless access
    ... I do realize the poker client encrypts everything, ... PokerRoom to tell me I'm secure, I'm trusting my browser. ...
    (rec.gambling.poker)
  • IPSec in Workgroup
    ... I have 2 machines with Windows XP SP 2. ... I'm trying to create an IPSec policy ... that encrypts ALL traffic between the two machines. ... I setup matching ...
    (microsoft.public.windowsxp.security_admin)