Does anybody know anything about the Tectia SSH client? My employer
has just installed this thing for us to use to connect to our UNIX
machines.

Using the telnet equivalent is pretty straightforward: create a
profile for each machine I want to connect to, then just chose the
appropriate profile.

But I can't figure out the FTP client at all. You can access the
profiles you've created, but when you do that a telnet window appears
and your file transfer window vanishes. I can use Edit|Settings to
configure a profile, which includes the IP address of the machine to
connect to. But there doesn't seem to be anything corresponding to the
telnet client's profiles list. I seem to be able to configure ONE
machine to connect to, and once I do that I can't tell it to connect
to another machine. I can give a * for IP address, in which case it
will prompt me for a machine to connect to. I could respond with an IP
address or a domain name. But in our environment the machines I need
to connect to have no domain names (at least no usable ones. It's a
security thing, I wouldn't understand). So using this option, I have
to look up the IP address of the machine I want to connect to. PITA!!!



--
Tim Slattery
Slattery_T@bls.gov

Tim Slattery <Slattery_T@bls.gov> wrote:

>Does anybody know anything about the Tectia SSH client? My employer
>has just installed this thing for us to use to connect to our UNIX
>machines.
>
>Using the telnet equivalent is pretty straightforward: create a
>profile for each machine I want to connect to, then just chose the
>appropriate profile.
>
>But I can't figure out the FTP client at all. You can access the
>profiles you've created, but when you do that a telnet window appears
>and your file transfer window vanishes.

Figured it out, I think. If you create a profile in the telnet client,
you get a telnet window when you open it. If you create one in the FTP
client, you get a file transfer window when you open it. The only
difference in the *.ssh file that defines the profile is a single line
in the [Window Positions] section:

[Window Positions]
Window=S: T 200 100 579 548

That's in the telnet profile. The file transfer profile is identical
except that the T in the line above becomes an F.

--
Tim Slattery
Slattery_T@bls.gov

Tim Slattery wrote:
> Tim Slattery <Slattery_T@bls.gov> wrote:
>
> >Does anybody know anything about the Tectia SSH client? My employer
> >has just installed this thing for us to use to connect to our UNIX
> >machines.

Tim,

It sounds like you figured out how to use it, but I think it's worth
your while to understand
what SSH gives you. SSH provides you with "strong authentication, and
strong encryption" capabilities, a large key pair to encrypt and
decrypt data and create a digital signature (to
prove you are who you say you are), and a public key for others to
encrypt what they are sending to you. There are a lot of bad guys out
there, and they do want to hurt you! ;-)

There is a lot more to it than than, but please check out their website
www.ssh.org
and learn more about how it works and what it can do for you...
Otherwise with telnet you
are sending your passwords across the network in cleartext for anyone
to read...

Rhino

I was in a discussion with someone yesterday about SSH and how
certification works with a
Certificate Authority. A couple of points could use a little
clarification.

When a new SSH client sends a request to transmit data to the SSH
Server for the first time does it's request include it's (the SSH
client's) certificate which includes it's own
public key inside, and the CA's digital signature as proof of who it
is? Or does the SSH Server ask the CA to validate the client?

Someone suggested that the SSH Server would not need to talk to the CA
at all, and that it
would simply respond to the SSH client directly. I know that without a
CA someone
would have had to put the clients public key on the server and visa
versa, and away we
go. His point is beginning to make sense to me, as it would save a lot
of overhead.

With a CA I had thought the SSH server would need to check with the CA
and the CA
would validate the client, and send the SSH Servers public key to the
client along with it's own digital signature proving it is the valid CA
to the client.

I can see the other persons point that it is reasonable that when the
SSH client was
brought online and entered into the CA lists of valid hosts does the CA
send
this info out to the SSH Servers, preinforming them about the new SSH
client?

I have RTFM for many hours at this point, at www.ssh.org, and
Wikipedia, RSA, etc.

Cheers, Rhino

"rhino007_us@yahoo.com" <rhino007_us@yahoo.com> wrote:

>
>Tim Slattery wrote:
>> Tim Slattery <Slattery_T@bls.gov> wrote:
>>
>> >Does anybody know anything about the Tectia SSH client? My employer
>> >has just installed this thing for us to use to connect to our UNIX
>> >machines.
>
>Tim,
>
>It sounds like you figured out how to use it, but I think it's worth
>your while to understand
>what SSH gives you. SSH provides you with "strong authentication, and
>strong encryption" capabilities, a large key pair to encrypt and
>decrypt data and create a digital signature (to
>prove you are who you say you are), and a public key for others to
>encrypt what they are sending to you. There are a lot of bad guys out
>there, and they do want to hurt you! ;-)
>
>There is a lot more to it than than, but please check out their website
>www.ssh.org
>and learn more about how it works and what it can do for you...
>Otherwise with telnet you
>are sending your passwords across the network in cleartext for anyone
>to read...

I understand all that Rhino. I was using the words "telnet" and "FTP"
to denote the - umm - telnet-like or telnet-equivalent Tectia client
and the file transfer client.

--
Tim Slattery
Slattery_T@bls.gov

rhino007_us@yahoo.com <rhino007_us@yahoo.com> wrote:
> I was in a discussion with someone yesterday about SSH and how
> certification works with a
> Certificate Authority. A couple of points could use a little
> clarification.

> When a new SSH client sends a request to transmit data to the SSH
> Server for the first time

Rather than 'transmit data' I would phrase that as 'connect'.

does it's request include it's (the SSH
> client's) certificate which includes it's own
> public key inside, and the CA's digital signature as proof of who it
> is? Or does the SSH Server ask the CA to validate the client?

Neither. In normal SSH usage there is no CA.

In the initial SSH connection, the server's private host key is used to
verify the server's identity against the server's public host key which
is stored in a local database on the client. If this is the initial
connection and the administrator has not pre-populated the database,
then it usually allows you to accept the server's key initially. There
is no verification on this acceptance and no CA aids you.

After the SSH connection is up, the client user authenticates to the
server, possibly using a public key stored on the server to authenticate
the user's private key. (several other authentication schemes are
possible)

> Someone suggested that the SSH Server would not need to talk to the CA
> at all, and that it would simply respond to the SSH client directly.
> I know that without a CA someone would have had to put the clients
> public key on the server and visa versa, and away we go. His point is
> beginning to make sense to me, as it would save a lot of overhead.

Correct (except for the vice versa part). The server generally does not
care about the client's identity for the SSH connection.

> With a CA I had thought the SSH server would need to check with the CA
> and the CA would validate the client, and send the SSH Servers public
> key to the client along with it's own digital signature proving it is
> the valid CA to the client.

There's no CA for ssh keys. SSH is not SSL.

--
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. >

rhino007_us@yahoo.com <rhino007_us@yahoo.com> wrote:
> Someone suggested that the SSH Server would not need to talk to the CA
> at all, and that it

*AFTER* sending, I realize that your subject mentions Tectia SSH. I
apologize if it implements something else for managing keys. I was
referring to openssh.

--
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. >

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

DD> rhino007_us@yahoo.com <rhino007_us@yahoo.com> wrote:
>> Someone suggested that the SSH Server would not need to talk to the
>> CA at all, and that it

DD> *AFTER* sending, I realize that your subject mentions Tectia SSH.
DD> I apologize if it implements something else for managing keys. I
DD> was referring to openssh.
DD> area < This line left intentionally blank to confuse you. >

Tectia offers X.509 certificate support for both server and client
authentication.

In the simplest case, for server authentication: each time you bring up a
new SSH server, you have the CA sign its hostkey. Each client has a copy
of the CA's certificate, initially distributed in a secure manner. This
way, a client can validate the hostname/key binding by checking the
signature in the hostkey certificate using the CA's key. So, instead of
managing a constantly changing known-hosts list, you distribute a single
CA certificate instead.

The client does not need to contact the CA to perform authentication,
although it may wish to consult the CA's certificate revocation list to
check for a revoked certificate.

--
Richard Silverman
res@qoxp.net