Tried a strong password. Was allowed to set it, but login using it failed. There are obviously some password symbol limitations that aren't disclosed. Any idea what they are? Attempted password was: 37*8/.q49BTR<6tkE{Fg
Some symbol was probably prohibited. Admins? How about a clue?
Edit: This was the login password for the website.
For the node password, or, for tunnel password?
If this question is the linux node's root password, then I recommend sticking with the ~95 Ascii printable characters, but most anything can technically be used except null. HOWEVER, one must be concerned what higher level entry through a client when typing in the password. There may be limitations, e.g. the linux shell or ssh may need some characters to be escaped, e.g. with a "\", when entering the password, the mesh node's perl gui may have some inherit limitation in the perl code (probably better not look like an html end tag). You certainly would want to avoid using a carraige retun in the password itself, etc.
You are using serveral suspect characters, while technically can be used in traditional linux as a password, may be problematic to enter in the perl UI or via ssh: "}", "*", "<".
Joe AE6XE
Either way it would be a bug.
Once we get confirmation on where the issue (VPN or Regular) is we should look into it and make sure we throw a warning where needed.
I'm guessing its a pass through flaw as Joe mentions but will be good to know which password we are talking about before we go digging deeper.
and, I do know VTUN has limitations
It must be the vtun password as I just took the pwd that he spec'd and tried it as the node pwd on a node. It save correctly and I was able to login with it.
D.
From KJ6UMY: "Edit: This was the login password for the website."
(in case someone missed this. Might be hard to find in update to original post.)
Thus, the password entered to access the "Basic Setup" UI page failed (did not take the password "37*8/.q49BTR<6tkE{Fg" ).
I can confirm Darryls comment that it works
I just ran the same password on a node.
My guess is a space or similar existed when you set the password (such as at the begining or end if copy pasted)
There hasn't been an official polciy written for it, I assume it will come up as we start writing the technical documentation (ongoing project right now).
For now it would appear Printable ASCII is fully acceptable for the code to handle
For SSH, I strongly recommend using only public key authentication and disabling password authentication entirely. This is the single most important thing you can do to beef up security on any network-connected machine that speaks it. I see constant brute-force attempts to break into the SSH servers on my own systems, but because I have disabled password authentication they will never succeed even if they were to correctly guess my nominal password.
You can upload your SSH public key through the "administration" subpage in the setup menu. In the standard SSH server on most Linux platforms you'd disable password authentication in the /etc/ssh/sshd_config file, but the SSH server in the AREDN/BBHN code is actually the "dropbear" package, a stripped-down implementation widely used on embedded platforms that's configured differently, through /etc/config/dropbear. I don't see any way to set it through the web config pages so you might try modifying the config file directly.
Unfortunately this leaves open the use of passwords on the configuration webpages. I don't see any easy way around this, especially since it appears the web passwords are sent over the network in the clear, other than to tunnel over SSH. And that's a bit involved to set up. In the meantime, don't use a password you also use on any other systems.
and technically, part97 prohibits you from using SSH (or other encryption) across an RF link...
Encryption for content obfuscation, no. But encryption for authentication is OK.
I'll have to dig into the SSH encryption suites to see if one can be modified for authentication only. I know that's not normally possible to guard against a man-in-the-middle downgrade attack. That's where the NSA intercepts your connection and plays each side off the other, claiming that the other can't support encryption, or only really weak encryption.
I have also heard others say that encryption for the purpose of administration of equipment (not message passing) is OK--and I've said this too :) . But, do we know where this precedence comes from? Spelled out in part 97? FCC published interpretation/guidelines? The ham community has done this in practice and the FCC has not challenged to date?
Specifically the prohibition is under Part 97.113(a)4 "...the purpose of obscuring their meaning, except as otherwise provided herein..."
I would question how encryption in this case does anything but obuscate as you do not REQUIRE encryption to authenticate specifically we can telnet which does not require encryption and theirfor there is a method and a reason to say that encryption during authentication is for the purpose to obfuscate. This has the follow question of "How does encryption authenticate you?" it generally does not (especially not in user/password combo) it only protects by obfuscating.
There was an argument for this at one time arguing that the key words "for the purpose" (intent) for using WEP (which with just the WEP key documented you could decode the transmissions that is not the case under modern WPA where you need to have the key exchange information) that it is valid for securing the wifi modem from replying to part 15 devices. http://www.n5dux.com/ham/files/pdf/Data%20Encryption%20is%20Legal.pdf This is an interesting argument, it hinges on the fact that 1) its purpose is to verify they are a ham (a form of authentication I'll admit) and 2) There is no other method to do this (unlike ssh/telnet) and is one area where the "its ok for authentication" argument has come from as many often forget the 2nd part that "no other method" exists. It has not been tested or approved by the FCC.
The other misquoted section i see used (either as they do not realize it does not apply or the argument is "its permitted there so it must be fine over here": is 97.211(b) "A telecommand station may transmit special codes intended to obscure the meaning of telecommand messages to the station in space operation." which was put in (to my knowledge) specifically because of the significant risk of compromise of a station in space. Compromised crednetails on the ground are an annoyance, but they would not cause for potential significant disruption of international operations like firing a thruster on a remote space station would. This is the only encryption that is permitted under Part 97 which is Space/Ground telecommand.
I generally suspect that the FCC hasn't received many complaints yet, I also suspect that if it becomes more an issue we may actually see the FCC come down hard as Part 97 is suppose to be self policing, with encryption we can't be sure we all are following the rules.
That is the other side of things too, many argue the FCC is too busy to come after most ham's and as such it will be fine. I don't personally believe that is an acceptable reason to bypass the rules.
Just my 2 cents on how I interpret the rules and what I have seen people suggest. I can say there is a reason my nodes run the block known encryption package from the code repo (so if your going through one of my nodes the whole SSH discussion is moot, my node is one of them that will block the packets so you won't be able to anyways.)
Authentication is closely related to but different than encryption.
Encryption obscures the meaning of a communication. Authentication ensures that the communication came from who it says it came from, and hasn't been changed in transit. These two are usually used together (e.g., in SSH and SSL), but this is not strictly necessary.
To do authentication without encryption, you'd send the actual data in the clear and add an "authenticator", a complex function of the data and a secret key known only to the originator. Although the complex function can be closely related to a cipher (sometimes it actually is a cipher), it is still OK under Part 97 as long as you're not actually using it to obscure the meaning of the content. For example, it would be perfectly legal to send over ham channels a PGP message with the "clearsign" option. It would also be OK to use SSH with a "cipher suite" that does authentication only, though it would require modifying SSH.
For this reason I would argue against merely blocking SSH. First of all, it's usually done by blocking its most commonly used TCP ports, and those ports are easily changed. Second, SSH with authentication only should not be blocked, even if it runs over the usual SSH ports. Third, there may well be a legitimate need to use encryption during a bona-fide emergency. Most of the rules are waived in emergencies, so you don't want to preclude this.
I would like to make a suggestion. First, you won't be able to stop someone who's really determined to use encryption, so don't bother trying. All you can do is provide the mechanisms to help those who want to follow the rules to avoid breaking them accidentally. You could do this by defining an IP Type of Service that means "encrypted traffic" and configuring each node with two routing tables (i.e. policy routing), one for encrypted traffic and one for amateur-legal traffic. The table for traffic marked as encrypted would use only non-Part 97 links (e.g., Part 15, Ethernet and Internet tunnels) while traffic not marked as encrypted would use a table that can use any kind of link.
It would be up to the user to set the appropriate type, which he could do regardless of application protocol and port number. And if it becomes necessary to send encrypted traffic in a bona-fide emergency, the user could simply change the type to use the full network.
High Performance SSH has preserved the NUL encryption option:
http://www.psc.edu/index.php/hpn-ssh