Hjälp med FTP-automatisering

fixade mellanslags delen med en uppdatering

http://www.dnz.se/misc/magic-uploader.sh

det skall inte vara endast "/kalendertest/calendar" som path, det är iaf det som den klagar på, om inte annat testa loga in manuelt med ftp

ftp host.domain.tld

för mappen som du har knappat in är inte rätt iaf..

saker som "/" och annat som ftp kan ta som mapp avdelare är ingen bra ide att ha i namn alls på filer dock...

Jag behövde ett litet hobby projekt för att ha ngt att göra, har semester och slut saker att göra

*/5 * * * * /Users/server/Anders/magic-uploader.sh

En helt ny värld öppnar sig men skämt och sido detta är styrkan i Unix, en uppsjö små program som gör en sak bra, som man kan "länka" samman så det allt blir mer än bara summan av delarna..

Angående nedräkning, nej inte någon nedräknning som jag kan komma på iaf cron är som till för att man lägger in sina saker och sen låter den vara...

Att komnandona körs kan du se med "ps x" som listar alla aktiva processer som du har aktiva, bara skriva i terminalen klockan 13:55 eller något sådant

kommandon körs baserat på vad klockan är inte, när du la in dem i crontab, så om du skriver */5 blir det då 0,5,10,15,20,25.... kommandot körs.

5 minuter är dock väldigt ofta, det är ju lite risk att ISPn ser det som abuse av ftp kontot eller så, var 20min kanske räcker?

FTP i alla dess former är ett ont protokoll som skall undvikas så mycket som det går, det är designat i en tidsålder där alla litade på alla och ingen hade brandväggar..

Anledningen att det går olika fort är vanligtvis algoritmerna som används, för att inte tala om det faktum att de flesta krypterade FTP lösningar endast krypterar kommando-kanalen och inte data-kanalen så visst, din användare & lösen etc är krypterade men datan som du laddar ner är i klartext för alla att läsa om du använder trådlöst exempelvis.

Egentligen är som alla adderingar och "säkerhets" lösningar till FTP som att sminka en gris eller styla en volvo.. rätt meningslösa..

det är egentligen bara:

do shell script "/path/to/script"

Som exempel, jag har en del script sparade som applikationer så jag kan styra över musiken som kommer från last.fm (genom min router/vpn gw) med quicksilver.

De tar bandnamnet som jag knappar in i QS och kör ett kommando på den maskinen per ssh med publik-key..

using terms from application "Quicksilver"
	on process text band
		do shell script "ssh -q garm.dnz.se /usr/scripts/lfmctl start " & band & ""
		do shell script "ssh -q garm.dnz.se /usr/scripts/lfmctl play"
		do shell script "/usr/local/bin/growlnotify -a iTunes -t \"last-fm\" -m \"stream started\""
	end process text
end using terms from

scp är dock inte ftp utan bygger på ssh's säkerhet, vilken är mycket god. I just det här fallen är det dessutom en bra idé eftersom det är lätt att skripta då passwordless login är inställt. En annan (behörig) användare på samma maskin kan sniffa upp lösenordet så ur det perspektivet är lösningen utan scp inte bra.

Notera att memark skrev FTPS vilket är en helt annan sak, SCP/SFTP är ssh funktioner ja, men hör inte till diskussionen av just den anledningen

Hastighets "problemen" dock är vanligtvis pga av valet av algoritm..

Det där får du gärna utveckla. Att kryptera både kommando- och datakanaler är väl självklart om man är ute efter nån form av säkerhet. Likaså att kräva både server- och klientcert. SSL/TLS är ju den förhärskande säkerhetslösningen inom många områden just nu. Tycker du det är lika dumt att köra HTTP över SSL?

SSL/TLS är endast ett sätt att skapa en säker tunnel, vad som man sedan stoppar i denna tunnel är helt upp till en själv.

FTP består av 2 "kanaler", en för login och kommandon så som "CWD /dir" eller så, och en för datan som du laddar upp/ned. Dock det som anses som säker FTP är endast kryptering av kommando-kanalen då det gör att user/pass kombinationen blir skyddad, en annan anledning till denna lösningen är att det är en kompromiss för hastighet, kryptera den obetydliga datamängden som kommandona genererar är inte kostsamt, att kryptera all transporterad data som ftp servern hanterar är dock mycket mer kostsamt.. så nej, det är inte på något sätt "självklart" att kryptera allt, personligen kunde jag inte bry mig mindre om någon sniffar datan som skickas, det är som "ja jippi, du har nu lagt ner energi för att få ngt som du kunde få om du bara frågade" krypteringen är till för access kontroll helt enkelt.

Om det är SSL eller TLS eller XYZ som nu råkar vara krypterinslösningen för dagen spelar ingen roll, hela poängen är just det att FTP är ett korkat protokoll.. det är som sagt sminka en gris varning.. bara för att man nu kan kryptera datan gör det inte att protokollet är mindre korkat för det..

Blir lite nyfiken av rekommendationen att köra SCP/SFTP. Nog för att kryptering är bra, men känns inte FTPS isf lite mer tidsenligt? Min erfarenhet är att SSH-baserad överföring är knöligare och långsammare än SSL/TLS-dito.

Håller med helt om vad du säger, utom det sista. Du upprepar din liknelse om grisen... Berätta istället vad som gör FTP så korkat. Vad mer än möjlighet till dubbel identifiering (dubbelriktad SSL) samt val mellan aktiv och passiv uppkoppling för att komma igenom brandväggar vill du ha?

Korkade delar av FTP:

#1 2 kanaler.. finns ingen anledning.

#2 sessionssetupen för en nedladdning, enda som saknas är att logga ut & in igen för att göra det mer omständigt.. hela data sessionen rivs och sätts upp igen för varje fil som du laddar ner..

#3 aktiv FTP, att servern skall aktivt ansluta till klienten är så urbota dumt i dagens ljus att det är fascinerande..

#4 passiv ftp, än en gång dubbla kanaler och det faktum att ett helt område portar måste öppnas för inkommande anslutningar, tom sättet som den får porten tilldelad i sessionen är så sjukt onödigt komplicerat att det är löjligt.

#5 det faktum att FTP nu mer är så pass överarbetat att det finns så få klienter som inte bryter mot den definerade standarden att servarna själva bryter mot den för att de skall fungera..

SSL/TLS har inget med FTPs autentisering att göra, där en MITM, replay & avlyssningsskydd så egna cert eller korrekt signerade cert av CA spelar som ingen roll, till skillnad mot för http, det är eg bara en fråga om trust av den maskinen..

punkt 1-5 gör att FTP är ett mörker i en brandvägg, saker som ftp-proxy används och andra saker för att komma runt det faktum att det är så pass trasigt som det är..

Som ett exempel på hur pass trasigt ftp är, FXP det är inte en funktion i ftp egentligen det är en bugg som är så pass stor att den nu används som en funktion av ftp..

OK, då är jag med lite mer på vad du menar.

Jag brukar inte anmärka på meningsbyggnad i vanliga fall, men den här meningen förstår jag faktiskt ingenting av!

orkade inte försvenska alla termier i den men annars inte så mycket underligt,

SSL/TLS har inget med FTPs autentisering att göra, det är ett MITM, replay & avlyssningsskydd så självsignerade cert eller korrekt signerade cert av CA spelar som ingen roll, till skillnad mot för http, handlar det bara om trust av servern..

hänger du med nu?

Det jag tyckte var underligt var som sagt meningsbyggnaden (vadå "spelar som"?). Om den är glasklar för dig är väl mindre intressant, åtminstone om du är ute efter att jag ska förstå.

Men visst, jag vet mycket väl SSL-lagrets roll i sammanhanget. (Det är ju mycket det som är dess styrka också, att det kan appliceras som ett extra lager på i grunden osäkra existerande protokoll.) Jag vet också att autentiseringen i FTP i grunden är oskyddad, men vad bättre än att göra det på en krypterad kanal? Vad skulle den stora skillnaden vara mot HTTP? Nog för att det finns DAA men i de allra flesta fall används ju vanlig forms-autentisering över SSL, vilket är precis lika (o)säkert.