KiTTY installer?
Het is gewoon dat sftp proces (root 1000 998 0 21:20 ? 00:00:00 /usr/libexec/openssh/sftp-server) dat aangesproken wordt, verder kan ik het ook reproduceren, mijn server doet hetzelfde. Mijn server is geen CentOS7. Ik ga even opzoek in de logfiles. Je zou ook even kunnen testen door een kill -9 1000 te doen. Je stopt dan met geweld even de sftp server.
Gewijzigd op 16/12/2014 22:59:36 door Aad B
Ik snap niet helemaal wat je bedoelt. Je bedoelt als ik die kill uitvoer dat dan ftp niet meer werkt? Maar dan kan ik toch ook m'n server niet meer bedienen via putty/kitty als sftp niet meer werkt?
Maar als ik het goed begrijp kan ik dit fenomeen(het aanroepen van ftp://123.45.67) dus simpelweg niet uitschakelen en zul je dus altijd die login-box krijgen, alleen kun je er nooit op inloggen?
> de laatste keer hebt ingelogd. Dat krijg ik in PuTTY nooit te zien.
Dat is vreemd, want die melding wordt gegenereerd door het login-proces. In mijn PuTTY krijg ik hem in ieder geval wel te zien. Maar goed, laten we dat probleem even aan de kant schuiven, want het is zo al ingewikkeld genoeg. ;-)
>> Kun je eens kijken in de rechter kolom (van yum list) uit welke repo dat package komt?
> Dit zegt ie: 1.3.5-cos7.build1200140807.16
Kijk, nú komen we ergens. Dit betekent dat je psa-proftpd v12.0.18 gebruikt die wordt meegeleverd als onderdeel van Plesk.
Ik vermoed -maar dat vermoeden is nergens op gebaseerd- dat je FTP kunt uitschakelen door het bestand /etc/xinetd/ftp_psa te wijzigen. Als dat bestand bestaat, dan zou er zomaar ergens een regel in kunnen staan met "disable=no". Verander dat in "disable=yes" en herstart xinetd met het commando "systemctl restart xinetd". Bestaat het bestand niet, dan moet je ergens anders iets wijzigen. ;-)
> Dit zegt ie: Failed to issue method call: Unit psa-proftpd.service not loaded.
Als inetd of xinetd wordt gebruikt om proftpd te starten, dan is bovenstaande melding wel verklaarbaar, ja. Waarschijnlijk heb je ook alleen maar een proftpd-proces wanneer er daadwerkelijk een FTP-client met je systeem is verbonden.
>> even checken: ps -ef |grep ftp
> Dit zegt ie:
> root 1000 998 0 21:20 ? 00:00:00 /usr/libexec/openssh/sftp-server
Had je op dat moment toevallig een sftp-sessie openstaan?
>> ... en wordt dus door de CentOS-installer aangemaakt (met homedir /var/ftp).
> De directory /var/ftp bestaat bij mij niet.
Dat kan; dat betekent dan dat er geen ftp-package (in ieder geval geen package uit de CentOS-repo) is geïnstalleerd. De gebruiker is dan wel aangemaakt en heeft ook een homedir toegewezen gekregen, maar die homedir hoeft niet per se te bestaan.
Zo, en nu even een uitspraak van Aad door de gehaktmolen draaien... ;-)
> Het is gewoon dat sftp proces (root 1000 998 0 21:20 ? 00:00:00 /usr/libexec/openssh/sftp-server)
> dat aangesproken wordt,
Hopelijk zeg ik het nu voor de laatste keer: SFTP is een protocol dat volkomen niets te maken heeft met FTP. FTP werkt op poort 21, SFTP werkt -aangezien het onderdeel is van SSH- via poort 22.
Die sftp-server is geen daemon-proces, maar een subsystem dat wordt gestart door sshd. Als je de complete output van ps -ef bekijkt, zul je zien dat het parent-proces (998 in dit geval) sshd is. Er is dus geen sftp-server-proces dat zelf een listen() doet op een socket (dat kun je zien in de output van lsof). Als er een sftp-server-proces draait impliceert dat, dat er ook ergens een sftp-client is die verbinding heeft gemaakt met deze server. Het killen van het proces betekent dan dat de actieve verbinding wordt afgebroken, maar voorkomt niet dat er een nieuwe verbinding wordt opgezet. En dat wil je ook niet, want we willen juist SFTP gaan gebruiken in plaats van FTP.
> Je bedoelt als ik die kill uitvoer dat dan ftp niet meer werkt? Maar dan kan ik toch ook m'n server
> niet meer bedienen via putty/kitty als sftp niet meer werkt?
Zie mijn vorige opmerking. Het killen van sftp-server stopt alleen een eerder gemaakte verbinding. Daarna kun je net zo vrolijk weer een nieuwe sessie starten. Met het uitzetten van FTP heeft het in ieder geval niets te maken. Overigens ook niet met het bedienen van je server via PuTTY, want daarvoor gebruik je SSH en geen SFTP. ;-)
> Maar als ik het goed begrijp kan ik dit fenomeen(het aanroepen van ftp://123.45.67) dus simpelweg niet uitschakelen
Natuurlijk kan dat. We moeten alleen even uitzoeken hoe. En wat ik van deze discussie heb geleerd, is dat ik nu echt zeker weet dat ik nooit, maar dan ook echt nooit, een adminpanel zal gaan gebruiken. Veel te lastig om erachter te komen wat zoiets allemaal uitspookt op je systeem. Het lijkt nondeju wel Windows.
Het bestand bestaat en die regel ook, maar ... bovenin het bestand staat:
#DO NOT MODIFY THIS FILE BECAUSE IT WAS GENERATED AUTOMATICALLY,
#SO ALL YOUR CHANGES WILL BE LOST AFTER YOU UPGRADE PARALLELS PLESK PANEL.
Dus dat gaat 'm niet echt worden.
>> Had je op dat moment toevallig een sftp-sessie openstaan?
Ja, ik denk dat WinSCP openstond op dat moment :)
>> want daarvoor gebruik je SSH en geen SFTP. ;-)
Oké ... dus we hebben SSH en SFTP is dan een soort "laag" die op ssh draait?
>> Het lijkt nondeju wel Windows.
Hihi :)
Willem, bedankt voor je toelichting en het is helder, ik begrijp je uitleg over sftp. Dank. Ik gebruik overigens ook geen enkele vorm van Admin/Plesk Panel gedoe.
Verder ben ik zeer benieuwd of:
> Maar als ik het goed begrijp kan ik dit fenomeen(het aanroepen van ftp://123.45.67) dus simpelweg niet uitschakelen
Daadwerkelijk wel of niet uit te schakelen is? Of wellicht is het al uitgeschakeld? Ozzie?
Ik kon het overigens ook reproduceren maar dat kwam door de vsftp deamon.
Gewijzigd op 17/12/2014 21:19:34 door Aad B
Aad, nee het is nog niet uitgeschakeld. Mocht je een oplossing weten hoor ik het graag en anders ga ik het binnenkort nog eens proberen uit te zoeken. Ik neem toch aan dat het uitgeschakeld moet kunnen worden.
> #DO NOT MODIFY THIS FILE BECAUSE IT WAS GENERATED AUTOMATICALLY,
> #SO ALL YOUR CHANGES WILL BE LOST AFTER YOU UPGRADE PARALLELS PLESK PANEL.
Tsja... dit suggereert dat je de functionaliteit dus moet uitzetten via Plesk. Ik ben voor de gein (nou ja, gein...) eens naar de online demo van Plesk gegaan om te kijken wat je daar allemaal mee kan doen.
Uitzetten van FTP lijkt inderdaad niet te kunnen, en ik krijg ook de indruk dat dat niet helemaal wenselijk is, omdat het best wel eens zou kunnen dat Plesk zijn interne backups via FTP op je server zet. Ergens in een forum was ik een bericht tegengekomen van iemand die de FTP-poort had veranderd, en vervolgens kon hij niet meer backuppen. Een ontwikkelaar reageerde daarop dat de backup het FTP-en naar een andere poort nog niet ondersteunde. Dat doet mij dus vermoeden dat FTP een essentieel onderdeel is van de Plesk-internals.
Wel kun je in je security-settings aangeven dat alleen FTPS (oftewel: FTP over SSL) moet worden ondersteund.
Een andere forumpost -en dat is iets waar ik zelf ook al aan zat te denken- sprak over het blokkeren van poort 21 in je firewall. Echter, de instructies die in dat bericht stonden (Setup -> Extensions -> Firewall) werkten niet op de Plesk-demosite.
Eventueel zou je dat blokkeren ook handmatig kunnen doen:
iptables -I INPUT -p tcp --dport 21 -j DROP
(en als dat ongewenste bijeffecten geeft, kun je de blokkering weer opheffen door in bovenstaand commando de -I te wijzigen in -D )
>> want daarvoor gebruik je SSH en geen SFTP. ;-)
> Oké ... dus we hebben SSH en SFTP is dan een soort "laag" die op ssh draait?
Zo zou je het inderdaad wel kunnen zien. Het SFTP-protocol haakt in op SSH om de authenticatie van de gebruiker te verzorgen. Op die manier worden bijvoorbeeld geen plaintext passwords over het netwerk verstuurd.
En we schakelen weer even over naar een opmerking van Aad:
> Ik kon het overigens ook reproduceren maar dat kwam door de vsftp deamon.
Dit geeft maar weer aan dat destijds de naam SFTP wat ongelukkig gekozen is. Uit de naam vsftpd valt niet af te leiden of het programma nu FTP of SFTP verzorgt. Of zelfs beide. Sowieso suggereert de naam SFTP dat je te maken hebt met een FTP-achtig programma. Dat heeft al voor heel wat verwarring gezorgd en ik vrees dat dat altijd wel zo zal blijven.
Tot zover in ieder geval erg bedankt!