[plug] Slippery, secure file transfers

[Bernd Felsche]

"simon" <simon at chrome64.org> writes:
>Bernd Felsche (bernie at innovative.iinet.net.au) wrote:

>> I ran into a problem with a cantankerous FTP server and
>> equally-adept "support" staff of a business partner for one of my
>> customers.

>> Their FTP server doesn't work properly... "it works for everybody
>> else" - the "everybody else" is actually that unwashed population
>> using THEIR proprietary FTP windows client software to MANUALLY
>> transfer EDI documents.

>EDI.....brrrrrrrr

>If the EDI of which you speak is the EDI I know of, and the broken
>FTP server of which you speak is the broken FTP server I know of,
>you have my condolences :)

It's pretty tough telling the people who are paying you by the hour
that their EDI partner's system doesn't comply with standards and
that they are going to have to pay for 4 to 10 hours of extra time
to work around the issue.

>I believe they munged the FTP server on purpose, and there was a
>vague but poorly thought through reason for doing it :) Ive blocked
>most of this stuff out, but I believe my mate (who was writing EDI
>stuff with my assistance) ended up getting it to work with a hacked
>perl module :)

I gave up on the write-only language. :-)

Python is much nicer, overall. It can make my brain hurt sometimes,
but serious perl stuff not only usually makes my brain hurt, it also
makes my eyes water.

I'll "do perl" when it's necessary. I'd rather not. I know only
about 2 dozen programming languages but I can't think of anything
I'd rather not touch.

>Be aware, they probably dont realise you can ssh in, and by

I told them... just as I was about to start flushing the whole idea
down the toilet, not having gotten anywhere with their "support", I
asked if I could try "something" while he was on the phone... that
something was 
	ssh user at hostname

And bingo. I was in. All the access I needed.

I then generated some keys for ID, created a .ssh directory on their
server and scp'd the key into the protected directory. Now it's a
passwordless connection.

FTP login had of course been clear text.

>avoiding their FTP server you may be doing more harm than good -
>possibly it marks EDI documents as you retrieve them? I really dont
>remember.....

Their server scans the directory for files matching a particular
name pattern. It's nought to do with their broken ftp server. It'd
be a very scary concept, security-wise.

My customer doesn't have the patience/deep pockets to pay for me to
experiment with a recalcitrant FTP server. If their EDI partner
suffers as a result of me getting EDI traffic flowing despite a
dysfunctional, non-standard FTP server, then it can only be due to
egg on their face.

Nowhere in their specification is it stated that they use a
proprietary file transfer protocol.
-- 
/"\ Bernd Felsche - Innovative Reckoning, Perth, Western Australia
\ /  ASCII ribbon campaign | "Laws do not persuade just because
 X   against HTML mail     |  they threaten."
/ \  and postings          | Lucius Annaeus Seneca, c. 4BC - 65AD.