The username for SFTP and ssh access is not the same as your member login; it is based on both your member login and the site name. The password, however, is the same as your member password. The specifics are listed in the "SSH/SFTP Information" box on each site's information panel in our member interface.
To find this information:
Visit the Sites panel to display your list of sites.
Select the site's "short name" in the "Sites" table to display the details about the site you want to access.
Find the box titled "SSH/SFTP Information."
Locate the username row and the appropriate hostname row for the protocol you wish to use.
Please keep in mind that if you are using FTP to access your site (not recommended), it uses these credentials as well, but you must enable it in two places.
This question depends largely on what tools you are using to create and manage the content of your site. There are four primary approaches people use.
Many web design tools have the built-in ability to upload content directly to our service through a "Publish" option. If you are using such a tool, you can set it up to publish your site via SFTP.
It is also possible to develop content in one tool and then upload it with a separate SFTP program, like WinSCP (for Windows) or Transmit (for Mac). (Linux also has graphical SFTP tools, but they vary widely by distribution and desktop environment.)
Some people prefer to hand-code their site, either directly on our servers via ssh or using a command-line tool like rsync or git to deploy remotely.
A less-common option is to use a tool like ExpanDrive or sshfs to make our web server appear like a local directory, allowing you to use whatever editor, graphical file manager or command line tools you wish to manage your content on our servers from your local computer.
In all cases, you'll need to check the documentation for the program you are using for specific instructions, but at a minimum you will require the connection information for your site to upload successfully.
We do not provide any "built-in" web tools in our member interface for content authoring. Such tools tend to be very limited and offer only basic functionality. As such, they do not provide the sophisticated and powerful options expected by our members.
The SSH key fingerprints for ssh.phx.nearlyfreespeech.net are in this FAQ entry.
SFTP and scp are supported. Port forwarding is supported but is only permitted for establishing secure remote connections to your MySQL database.
Important: Our ssh environment is provided solely for maintaining your website and is not to be used for any other purpose. This specifically prohibits using it for proxying, port forwarding, or anything similar. Automated access to the ssh server is likewise prohibited, with an exception allowing connections once per day for the purpose of making offsite backups.
To SFTP files to our service, use the same hostname that you use for ssh, not the one you use for FTP. You can get this hostname by clicking the "Sites" tab at the top of the page, then clicking the site name from the "Your Web Sites" list. The hostname will be listed under "SSH/SFTP Information." For convenience, we have created an sftp.xxx.nearlyfreespeech.net alias, where the xxx part is the same for you as it is for ssh and FTP.
Any working ssh client should be able to connect to our systems. The "reference" implementation in our opinion is the OpenSSH application, available on most Unix platforms (including MacOS X, most easily accessed using the included "Terminal" application) and on Windows via the Cygwin or Interix environments.
On Windows, the far-and-away best ssh application is VanDyke Technologies' Secure CRT. This program is rather expensive ($99) but worth every penny if ssh on Windows is a part of your daily life. PuTTY is a very popular free alternative. It is a little less pleasant to use, but is very workable. (PuTTY requires no local installation and is a perfect tool to slap on a USB memory stick for secure access from anywhere.)
Other alternatives do exist, but these are the most common and the ones we use ourselves.
FTP is an insecure protocol that should never be used, much less as part of any new development. It is strongly recommended that you leave FTP disabled and access your site with SSH or SFTP.
FTP access can be controlled on a per-member and a per-site basis. Although some people expect these settings to be related, or expect one to supersede the other, they are completely independent. Both the member accessing a site and the site being accessed must have FTP enabled in order for access to succeed.
This is to allow maximum access control granularity in situations where multiple members share access to multiple sites via our adjunct access feature. For example, if you don't want to allow FTP access to your site, and you want to make sure a member with adjunct access doesn't enable FTP access for himself and overrule you.
To enable FTP access for your membership, visit the Profile page and toggle that setting in the "Details" box.
To enable FTP access for your site, visit the Sites panel and select the site by its "short name" to view its Site Information page, where you'll see the FTP setting in the "FTP/SFTP/SSH Information" box.
Note that as of May 18, 2010, FTP access is deprecated. While we have no current plans to remove it, it is disabled by default on new sites and memberships. (And must therefore be enabled in both places if you want it.)
Our system does not access your site's filesystem until after you have authenticated yourself. Also, correct authentication depends on both member name and site (since more than one member name may have permission to access a given site and a given member name may be able to access more than one site). Therefore, you cannot place a public key file in your site's filesystem to bypass password authentication.
Instead, we keep a separate keychain for ssh keys for each member outside the filesystem. If you have a public key you wish to use to authenticate your ssh connection in lieu of your password, you can set that up on the profile tab.
Per current best security practices, here are the key types we support:
RSA keys of 2048+ bits (4096+ recommended) not on the Debian weak key blacklist are supported.
ECDSA keys of 256 and 521 bits (521 recommended) are supported. (Recommended for low-power mobile devices due to speed.)
Ed25519 keys are supported.
DSA/DSS ("ssh-dss") keys are not supported. This is a US government FIPS standard developed by the NSA and intended only for low-security usage. (Read: they are probably not secure.)
Once installed into your membership's keychain, an ssh key may be used to authenticate access to any site you are authorized to access, including all of your own sites and any sites you may have adjunct access to.
First, please consider using an uploading method other than FTP, such as SFTP or SCP. FTP is a complex, insecure protocol that does not work very well on the modern Internet. If you have an alternative, use it.
Please also keep in mind that, as of May 2010, memberships now come with FTP disabled by default, so if you must use it, you'll need to make sure it's properly enabled first.
With that said, almost all FTP problems are caused by NAT devices (especially cheap residential gateway routers) incorrectly processing FTP connections, or by personal firewall software blocking FTP access. These problems generally manifest as being able to connect to the FTP server, but not to upload or download any files. FTP has two operating modes, active and passive. The first response to any FTP connection problem should be to switch your FTP client from active mode to passive mode, or vice versa. Switching modes almost always clears up FTP issues.
Other potential problem areas for FTP include your local firewall configuration (hardware or software) and incorrect FTP connection information.
Easy way: You can use nfsnssh.com instead of ssh.phx.nearlyfreespeech.net if you prefer.
Better way: OpenSSH allows the creation of "nicknames" which serve this function admirably. To use this feature, create (or edit) the file ~/.ssh/config (on the client machine you will be connecting from, not ours!) and add content like this:
With this done, you can use "nfsnssh" as if it were a hostname in ssh, scp, and sftp. For example, just use ssh mylogin_mysite@nfsnssh to connect to mysite as mylogin.
You can even use the User option to create per-site nicknames to make commands even shorter:
Then you just ssh mysite_nfsn to connect to mysite and ssh othersite_nfsn to connect to othersite. It doesn't get much shorter than that! See the ssh_config man page for complete details.
If you don't happen to be using OpenSSH, a lot of other ssh tools offer similar options, many with graphical interfaces that make establishing a connection as simple as clicking, regardless of the hostname.
The first thing to check is to make sure you are using the correct connection information for your site, including your username and password as well as the correct name of the server for the service you are trying to use. You should always check this, even if you are sure it is correct, before exploring more exotic options.
If you are unable to connect at all, or if the connection appears to drop immediately, one possible explanation for this is that you are running firewall software (or have a hardware firewall) that is blocking your connection.
If you use P2P file sharing software, many "P2P block list" applications can block connections. As an example, the P2P application PeerBlock (formerly PeerGuardian) in its default configuration uses lists on which we appear and blocks FTP/ssh traffic.
In such cases you will need to either disable the application or set up a manual override to allow the connection.
The most common diagnostics that indicate problems with firewalls and blocking software are "Permission Denied," "No route to host," "Connection refused," "Host unreachable," or "General failure" when attempting to access our FTP or ssh servers, but no similar problem when trying to access your site(s) or ours by HTTP or HTTPS. If you can't access anything at all, the problem is likely something else.
As of October 2010, we are known to be listed on the Bluetack "level1" list and the TBG "PrimaryThreats" list. The stated reasons for listing us are dubious, but since these lists basically say "do not connect to these IPs for illegal P2P file sharing" we don't really mind being listed; that type of usage would not be concordant with our Terms & Conditions of Service.
This can also happen if you have non-functional IPv6 connectivity. Our ssh server supports IPv6 and some home network devices advertise IPv6 capability even if it is not supported by your ISP.
For the most part, no. We do not allow unattended, automated access because it is an excessive use of resources we currently do not charge for and because it can be very bad for our system security.
This means that the of use embedded devices that upload information via FTP automatically on a regular basis, such as web cams and certain "weather station" devices in conjunction with our service is strictly prohibited. Such devices are a security disaster; they broadcast your member password over the Internet every few minutes in plaintext, and we will not allow that. If we find evidence of FTP being used in this fashion it will be disabled or, after repeated problems, blocked entirely.
We are somewhat less strict about SSH access, as the focus is more on excessive resource usage. We will overlook unattended SSH access under the following conditions:
in all cases, an ssh public key must be used (no hardcoded passwords!)
for downloading, once per day for making backups of content hosted here
for uploading, so long as the ssh-based upload frequency is less than the web-based download frequency (in other words, people are viewing the file at least as often as it is being updated) or an average rate of one file per fifteen minutes, whichever is more permissive
Please be respectful of the shared resources assigned to FTP and SSH by observing these guidelines.
If you have an application that needs the ability to remotely upload on a regular/automated basis, it is entirely possible to do so. All you need to do is set those tasks up via HTTP, e.g. using POST or PUT requests and a small script to receive the files.
All these limits apply only to unattended access. As long as you are physically present at the keyboard initiating uploads or downloads yourself, no such limitations are imposed.
If you need FTP access for allowable purposes, but your FTP access to one of your sites has been blocked due to repeated or egregious violation of our policies in this area, and you are a subscription member, you can contact our support for assistance. If you are not a subscription member and you have FTP access blocked under this policy, you will have to alter your methodology to use SSH/SFTP (which you should be doing anyway) and to comply fully with the policies outlined above.