Re: want to automate PSFTP, skip fingerprint cache/prompt?

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View

    TG> I have a program that will execute a commandline for PSFTP.  I
    TG> pass all of the login options via switches, then use -b to use a
    TG> batch file for the server operations.  I don't want to store the
    TG> server fingerprint in the local cache.

It doesn't store the fingerprint; it stores the server's host key.

    TG> Every time PSFTP executes it prompts to save the fingerprint.

To save the host key, rather, which it identifies by displaying the

    TG> Can someone tell me how to eliminate the fingerprint prompt?

You can't; if you do, you have no server authentication and your SSH
connections are vulnerable to man-in-the-middle attacks.  See the FAQ:

  Richard Silverman

Re: want to automate PSFTP, skip fingerprint cache/prompt?

    TG> Is this the proper way to authorize access to a given server for
    TG> an entire site?: 1) Run PSFTP on any client.  2) Accept server key
    TG> in registry.  3) Once and once only: Use a program to copy the
    TG> proper registry key to all authorized PCs.

This procedure is technically to MITM as well; if when you do it, someone
is spoofing the server, you could store a bogus key.  Of course, you can
check the fingerprint displayed against the correct one.  But this isn't
best way to proceed, anyway...

    TG> The FAQ says the key is under:
    TG> HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\ I found the data at
    TG> that path, under, SshHostKeys, with value rsa2@22:a.b.c.d

    TG> So can I just copy that around the site?  Does the value of the
    TG> key vary by client (wouldn't think so).  

There's no client-dependent component to the key itself.  There might be
something odd about other details of its storage by PuTTY, but I doubt

    TG> Is the key location standard across Win32 platforms?

No idea.

    TG> Assume there are 100 PCs that run this interface.  I just don't
    TG> want to have a sysadmin manually save the server key on every
    TG> PC. I have ways to do the registry updates automatically if that's
    TG> the proper procedure.

I think that would be the best approach.

You're noticing a real problem with current SSH software: awkward and
unscalable server authentication.  The most widespread, interoperable
method -- the "known-hosts" list in various forms, in the registry in this
case -- is too simpleminded; it's a nightmare for large deployments.  And
since there are too many cases in which it fails, users inevitably learn
to ignore server verification warnings, which is bad.  There are three
main alternatives I'm aware of:

1) Kerberos
2) X.509 PKI
3) SRP ( /)

Kerberos is a great system, but of course you need a Kerberos
infrastructure, which may not be feasible.  But more people should
consider it, because it's not actually that hard to do, and in some
environments *lots* of software is Kerberos-aware.  For instance, many
common network clients in Red Hat (Pine, Mutt, Telnet, imapd, etc.) ship
Kerberos-ready -- if you set up a Kerberos realm appropriately, they just
magically start working, and you get reasonably pervasive single-signon
with little work.

There is a problem with SSH vis-a-vis Kerberos, however, in the standards
arena: there is as yet no widely accepted standard for doing Kerberos in
the SSH-2 protocol.  It's available in SSH-1, and in fact as mentioned
above works out of the box in Red Hat, but it's past time that SSH-1 died
and you don't want to recommend its use for anything other than occasional
compatibility.  There are patches for doing Kerberos via GSSAPI for

... however, since this is not widely implemented, you are mostly
restricted to using it with a corresponding build of the OpenSSH client,
which may be an unacceptable restriction (or not, depending on the
environment). has yet another, incompatible method for doing
Kerberos over SSH-2, which similarly will work only with their software.

Using X.509 certificates gives similar benefits for server authentication,
but again, although there is support for it in the protocol, it is not
widely implemented.  The product has it, but only in the
commercial version.  It works nicely, though: you can simply distribute a
single key to all client installations, for the CA which issues your
server certificates.  Then you're done, at least in the short term: you
can add new hosts, change host keys at will for whatever reason, etc., and
not touch the clients.  Of course, there are all the usual PKI issues,
such as checking for certificate revocation.  Kerberos really gives you
that already, plus user authentication -- which you can also do with SSH
and certificates but it's more work...  a detailed comparison of the
tradeoffs here is more than I want to write just now.

SRP is similar to Kerberos in that a single exchange performs mutual
authentication, and it relies only on the user's password (no ancillary
material to deal with, such as private keys or known-hosts lists).  There
are differences on a more technical level, but again punting that... the
issues are again:

- limited availability

- lack of SSH standard

- For a given password, the protocol only assures that you are talking to
  a host with whom you have shared that password -- so to get full
  per-host authentication, you'd need to use a different password with
  every host.

- Possible IP issues; SRP is patented (US patent 6,226,383 held by Phoenix

I should really write up an FAQ or article on this stuff...

  Richard Silverman

Re: want to automate PSFTP, skip fingerprint cache/prompt?

    res> For instance, many common network clients in Red Hat (Pine, Mutt,
    res> Telnet, imapd, etc.) ship Kerberos-ready -- if you set up a
    res> Kerberos realm appropriately, they just magically start working,

I should have included Evolution (Kerberos-5 via GSSAPI) and sendmail in
this list.  Sendmail means you get a nice solution for SMTP authentication
as well, so you can have a mail single configuration for roaming users
without having an open relay, all integrated with Kerberos
single-signon... I use it; it all works very nicely.

  Richard Silverman

Re: want to automate PSFTP, skip fingerprint cache/prompt?

Quoted text here. Click to load it

There's a fourth, relatively new, option: host key verification via DNS.
The current OpenSSH snapshots have experimental support for this.

Grab a snapshot and take a look at README.dns, which says, in part:

"How to verify host keys using OpenSSH and DNS

OpenSSH contains experimental support for verifying host keys using DNS
as described in draft-ietf-secsh-dns-xx.txt. The document contains
very brief instructions on how to test this feature. Configuring DNS
and DNSSEC is out of the scope of this document."

Quoted text here. Click to load it

There is also an unofficial OpenSSH X.509 patch available at: /

Quoted text here. Click to load it

Do you take contributions to your FAQ?  I'm tired of explaining
fragmentation/MTU/firewall/NAT problems.

Darren Tucker (dtucker at
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

Re: want to automate PSFTP, skip fingerprint cache/prompt?

    DT> Do you take contributions to your FAQ?  I'm tired of explaining        
    DT> fragmentation/MTU/firewall/NAT problems.                                
Sure, that would be great.                                                      

  Richard Silverman

Re: want to automate PSFTP, skip fingerprint cache/prompt?

Thanks for all the info guys.  I've written my code to extract the
proper registry key from an admin PC and pull it into a server.  The
first time clients need PSFTP (triggered from their business app) the
server will check their registry, if they don't have a server key it's
installed to their system, and the FTP process continues as normal
with no prompts.  [ Almost like I wrote my own Kerberos. :) ]   In
case you're wondering, we know the clients are valid because they've
already authenticated "deeply" into the application.

All of the other info is useful but at this point I'm writing code for
someone else's site, so I have no control over what or how they're
doing their security.  One thing I will do though, is ask them why
they go through so much pain to run PSFTP when they're running plain
telnet over the net for users.  ;)


(great things snipped for brevity)

Site Timeline