Hello, sorry in advance, I'm a first time poster and somewhat new to UNIX (Mac OS X) I've searched on your boards and have been unsuccessfull in finding information on this. I have found some info at Google but not enough to validate my stance in a debate.
I'm trying to FTP into a server and the responsed server gives me:
230-No directory! Logging in with home=/
I cannot perform a "ls" or "dir" without it hanging. Basically can't see anything.
The administrator also states that I don't have a "home" directory and once I log in I will be placed into a "shared" directory with other users. I've yet to successfully view anything.
The admininstrator has told me its my FTP clients or my firewall blocking FTP traffic. I've been unsuccessfully to log into his server with a number of FTP clients, command lines, 2 different locations, 3 different OS (Windows2000, Linux and MacOSX) and all have reported the above response.
I believe the error is Unix administrator issue and not my FTP clients (which all do work on different FTP sites) The administrator is stating that its not their site. I just don't know enough Unix to converse efficiently.
My guess is that you're trying to use passive mode ftp and the server doesn't support passive mode. Open a connect to the server and type "rhelp". Does the list of commands include PASV? (The list of commands should be returned back down the control connection so this should work.)
If that's not it, you will need a network engineer with a sniffer to watch the packets and see who is fumbling. It may indeed be a firewall issue. You are ok when the server and client establish a control connection. But you are locking up when the client and server attempt to establish a data connection.
Don't let that message throw you. It's not related to your problem although it may indicate another problem once you can establish a data connection. And like I said, you now need to to capture and decode the packets to see what's going on. This may be a firewall issue on his end.
The 'no home' message you are seeing is because the admin on the other end doesn't know what he's doing. A home directory hasn't been setup for the account you are logging in under, so it defaults to /, which usually isn't a good idea.
If you are able to ftp to other sites successfully then the problem isn't on your end. Its on the server side and that admin needs to do the debugging of his setup.
And a bit of a rant -- ftp is insecure! If you are using an account and password you are at the least revealing this info to anyone sniffing in-between. If this login and password is the same as your login/email to the server then you have just given away the farm to anyone listening in.
Use ssh, scp, sftp instead. Lobby your sysadmins to do the same.
The SANs report for SSH vulnerabilities is for older releases and in particular and more broadly open SSH releases. My advise would be to not quickly berate SSH just because of that. SSH (older versions) had problems, but with the exception for a trogan at the OpenSSH and mirror sites, the commercial distributions (like SSH) are much more secure than FTP, etc.
A single release problem ior two in an application does not merit the negative SSH blurbs. Recent releases are fine...... so far Let's tone down the SSH negative comments. Might be better to say:
"with SSH, make sure you are using the most recent version..."
because the recent version is OK, according to SANS ......
I understand that, I definitely use ssh when connecting via the internet. I don't think it's right to dump on FTP or telnet, though, especially when similar problems occur with other protocols/applications.
The problem with so-called "secure" software, like ssh, is that it's taken for granted. Most users jump and say what the poster above said. Security is about mitigating the ineviatable. There is no security catch-all. Let's not delude ourselves.
So are you more likely to get your passwords sniffed by some man-in-the-middle, or are you more likely to get hit by the next ssh-exploiting worm that floats by? It's hard to say...
And don't forget, the versions with holes in them were at one time "the most recent version"...
My point was that ssh is not foolproof. It takes as much work to secure a box with only ssh remote access as it does to secure one using telnet or ftp or whatever. I by no means think everyone should stop using ssh, but I also don't believe that telnet should not be used either.
I don't want to interrupt your ssh debate, but I would like to point out another option. The company that I work for uses ftp to distribute data to our clients. I don't like ftp very much. But we have to use a protocol that is widely available to our clients. This simply shuts the door on sftp.
But just about every web browser can handle HTTPS. It has its flaws too. But it's firewall friendly. It is truly very secure. If you really trust that "third party" who issues the certificates, you can argue that it is more secure than ssh because the "initial contact" problem goes away.
And HTTPS runs on a service called SSL which really could be used for any TCP based service. Yeah, that's a big "could be". But HTTPS is very secure and very available today.
I haven't had much luck promoting HTTPS around here. Still, I thought it might be worth a mention in this thread...
Let's tone down the SSH negative comments. Might be better to say: