Umm. I think you mis-understood me abit. I'm not asking how should I config -my- sshd, 
but what is the general usage of the client ssh. And this would include using ssh on a 
public terminal (for example, at Linux World Expo, at the "Email garden" or some linux 
internet cafe' or a friend's house). A dot file is not something that can used in that 
critria (sp?). In other words, what can I -try- to instill (sp?) in my users/cleints 
on the proper usage of ssh. they can do whatever they want, but I want to be able to 
give them a good head-start.

* on [09.05.01] Roeland Meyer <[EMAIL PROTECTED]> wrote:
> Delivered-To: [EMAIL PROTECTED]
> From: Roeland Meyer <[EMAIL PROTECTED]>
> To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>, 
>       [EMAIL PROTECTED]
> Subject: RE: a question about proper use of ssh
> Date: Wed, 5 Sep 2001 07:47:40 -0700 
> 
> |> From: Isaac Bentley [mailto:[EMAIL PROTECTED]]
> |> Sent: Tuesday, September 04, 2001 5:56 PM
> 
> |> I have in the past, told people to always use "ssh -C -c <ciphername>
> |> - -l <username> <hostname>" when connecting, but somebody pointed out
> |> that is not really needed, because all ssh servers encrypt on all
> |> connections as default, unless the admin forced it to do differently.
> |> He is -very- adamant (sp?) about it, but I like to stand my ground on
> |> this one :-)
> 
> Sorry, your ground is weak. You should set your default ssh options in
> /etc/sshd.d/ssh.conf (note, not /etc/ssh.d/sshd.conf) for your entire
> system. Then you users only have to use "ssh <host>", which they are
> probably doing anyway, when your back is turned. You have two conf files,
> one for ssh and t'other for sshd. The general principle here is that the
> least amount of typing required, results in the fewest errors. Errors are
> not good. In *nix, errors can be fatal.
> 
> Your friend is correct about ssh behavior. ssh always encrypts. In fact, it
> is very difficult to get it to stop encrypting. 
> 
> |> The question is: Is my way (specifying arguments) any better then
> |> just say executing "ssh <hostname>"?
> 
> One of the command-line switches you require is the first-step to getting it
> to do so. All you have to do is typo the arguments. It is safer to NOT
> specify any switches on the command line.
> 
> |> Should I inherently trust the
> |> server, whether it may be FreSSH or OpenSSH or SSH(c)? What about
> |> trojans (like an trojaned sshd on the server), anyway to avoid
> |> pitfalls for the client?
> 
> If the server has been root-kit'd then there is nothing you can do to
> protect anyone. Put a fork in it and call it "well-done", you've been
> "owned", it's not your server anymore. If you can't trust your own server
> then you need to scrub the disks, re-install the OS, and recover *only* data
> files from the backups (scripts and sources should be backed up on CVS and
> you should never backup binaries).
> 
> |> And yes, I know you can setup a dot file for ssh on the user's home
> |> dir, I'm talking about general ssh'ing in to a server...
> 
> That's exactly what the dot-file is for. BTW, ssh is to protect the session
> transit connection, not the server. If you truely want session
> authentication security, and if you are sufficiently paranoid, setup a
> dedicated Kerberos5 authentication server. Use Heimdal. Let NO ONE but root
> have a shell account on that server. Shell accounts are bad.
> 

-- 
Isaac Bentley

PGP signature

Reply via email to