Connect and log in

When you open a control connection, the server greets you with 220. You send your username, the server may ask for a password with 331, and 230 means you are logged in.

That three-step dance is the front door to every classic FTP session. Learn to read it once and you can debug half of partner tickets from the transcript alone.

If you automate login, log the numeric codes, not just “success” or “failure.” 331 and 230 tell different stories than a boolean flag. Save the transcript. Your future self will need it when the password rotates.

Here is what that looks like:

$ ftp files.partner.test
Connected to files.partner.test.
220 FTP server ready
Name: alice
331 Password required
Password: ****
230 User logged in
ftp>

Classic FTP sends USER and PASS in cleartext. I show this transcript so you can read the protocol, not so you expose real passwords on the public Internet.

A bad password comes back as 530:

Name: alice
331 User name okay, need password
Password: ****
530 Login incorrect

After 530, you are not logged in. Do not keep sending get or put commands. Check the account name and any lockout rules before you retry.

Some servers defer the greeting with 120, or reject you with 421 and close the connection. Treat 421 as a hard stop.

With explicit FTPS, you send AUTH TLS and finish the TLS handshake before credentials go on the wire. SFTP is different. It uses SSH and never sends this USER/PASS sequence.

After 230, I usually run feat to see what the server supports:

ftp> feat
211-Features:
 MLST
 SIZE
 REST STREAM
211 End

Use a test account with narrow permissions. Capture the greeting and login result without saving the password in your notes. Redact before you paste into Slack.