Hello,

Using CentOS 5.5. I have ssh setup to use a radius server for authentication. When I use filezilla to test sftp I can successfully authenticate and get directory listings, but every time I try to download or upload a file filezilla attempts to re-authenticate which fails because the radius server uses token auth with one time passwords, so the original password used to authenticate is no longer valid. However I can browse directories all I want and it never tries to re-authenticate.

1. is this re-auth just how sftp protocol was designed? like re-auth anytime a user tries a different action, like browse vs download vs upload?

2. or am I just missing something? (very likely, I'm not real experienced with linux)

sftp in itself certainly does not do this. How do you know it is reauthentications? Not doubting it, but it might shed some light where you are seeing this. Try with a different client, maybe winscp.

1 members found this post helpful.

thanks for the response acid_kewpie. Now that I know the sftp protocol itself is not by design forcing re-auths, I can focus on other areas, like the client config or maybe, but I'm thinking less likely, the server config. I was thinking if the protocol itself were forcing re-auths, then the clients just resending the credentials already input would always fail due to the nature of the token auth and OTP's, and if this were the case I would just be sol. But if it's not inherent to the protocol I should be able to fix.

as for your question, I know it is re-authenticating because I can see the commands filezilla is sending to the server, I see it passing user and pass. I also noticed the following:

1. successful initial connection and auth.

2. success on first download of a remote file, but see that the client disconnects after the download, don't know if this disconnect is initiated by the client or server though.

3. try another download and of course fails, because since it was disconnected it has to reconnect, and re-auth, but it automatically tries this with the credentials you have already provided, which will fail in my case because they contain a OTP.

example log snipped from filezilla showing a previous success message followed by another attempt which fails:

Status: File transfer successful, transferred 442,115 bytes in 1 second
Status: Disconnected from server
Status: Connecting to my.ip.add.res...
Response: fzSftp started
Command: open "myusername@my.ip.add.res" 22
Command: Pass: **********
Error: Authentication failed.
Error: Critical error
Error: Could not connect to server

Filezilla contains a 'manual transfer' feature which would allow me to work around this issue because it allows you to re-enter your credentials, but I would rather not have to do that.

1. why is it disconnecting after a file transfer? is this a client or server thing? I'm thinking it's possible that I will find its common for clients to do this, or maybe the server, to avoid maintaining open connections, and normally re-sending creds would work seemlessly but in a OTP scenario, no worky worky.

I'll try winscp just to compare, but I think most of my users are already using filezilla.

WinSCP works flawlessly. Must just be a Filezilla thing. I'll poke around the Filezilla options to see if there is a way to stop this behavior, just so I know, but I think my plan will be to ask users to use WinSCP.

Thanks for the help