Do the instructions on this wiki work?
https://dallasmakerspace.org/wiki/JumpServerFAQ
There is a section titled “How can I mount the Member Storage (from *NIX)?”
Does this still work? Has anyone tried it lately?
1 Like
Ssh access has worked for me recently.
2 Likes
Has sshfs access worked for you?
Yup…
pi@raspberrypi:~ $ ssh [email protected] -p 2222
The authenticity of host '[physical.dallasmakerspace.org]:2222 ([47.190.37.3]:2222)' can't be established.
ECDSA key fingerprint is SHA256:Mu6NRsykSxayZjcyw/lx+Mkje7kWtdXOchsA3L/DyXI.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[physical.dallasmakerspace.org]:2222,[47.190.37.3]:2222' (ECDSA) to the list of known hosts.
Ubuntu 14.04.5 LTS prlxjump ssh-pty
Password:
Last login: Fri Sep 11 20:27:35 2015 from pool-173-57-132-20.dllstx.fios.verizon.net
roughvagabond@prlxjump:~$ ls -l
total 0
roughvagabond@prlxjump:~$
2 Likes
Nice. I got it working.
Edit your .ssh/config file…
nano ~/.ssh/config
Add a section like the following. “roughvagabond” is your Maker Manager user name.
Host dms
HostName physical.dallasmakerspace.org
User roughvagabond
Port 2222
Create a place to mount the drive…
mkdir ~/dms
Mount…
sshfs dms:/mnt/files ~/dms
Enjoy…
cd ~/dms/members/roughvagabond
ls -l
When you are finished…
cd ~
sudo umount -f ~/dms
rmdir ~/dms
Ideally you would also enable public key authentication (I have not tested).
If anyone tries this please respond. If the steps work for another person I will update the wiki.
3 Likes
all you really need to do, is combine these 2 commands
I’ve chosen to leave that out of the wiki (not that I would remove it if someone else added it, but…)
2 Likes
Thanks very much! This works for me and is greatly appreciated.
I’ve lost too many thumb drives already and this lets me send me files over before come over to print/laser etc.
That’s a weird way to enter
vi ~/.ssh/config
3 Likes
It seems like the instructions should say:
sshfs -p2222 [email protected]:/mnt/files /some_directory_on_your_home_machine
That way you don’t need to add anything to your config file.
This appears to only work from offsite though. Ports 22 and 2222 are both apparently filtered from onsite. I don’t know anything about that.
1 Like
For those unfamiliar with / new to Linux, failing to include the creation of the mount point (mkdir) in the instructions guarantees failure. I prefer instructions that increase the chances of success.
For those who want to access DMS storage a second time, which strikes me as highly likely, adding an entry to the .ssh/config file reduces the amount of information needed to accomplish the task and reduces the amount of typing. I prefer instructions that simplify tasks that are likely to be repeated.
I just meant that the sshfs instructions currently on the wiki are wrong because they leave out the -p2222 part and so for anyone who’s tried it, that’s why it didn’t work. I still like your more verbose instructions better for the reasons you mentioned.
1 Like
It looks like the reason this doesn’t work internally is because physical.dallasmakerspace.org resolves to our external ip address while port 2222 on that ip isn’t open from onsite.
I don’t know whether that’s intentional. It seems like we would either want to have physical.dallasmakerspace.org resolve to an internal ip address from onsite, or adjust the port 2222 forwarding rule so that it accepts forwards from the internal interface in addition to the external interface.
However currently it’s possible to work around this by just substituting the internal ip address 192.168.200.36 and port 22 for physical.dallasmakerspace.org and port 2222. Port 22 is the default so you can leave it off and end up with:
which will not work from offsite but will work from onsite.
So… I noticed “roughvagabond” added a bunch of stuff to the wiki that looks a lot like this. Whom “roughvagabond” is remains a mystery…
At any rate, the phrase “Maker Manager user name” appears repeatedly, but I think is erroneous. This is your dms.local credential, I do believe. Can anyone confirm/refute? I would like to “make that correction”, but figured I’d run it by here first…
1 Like
I believe Maker Manager and dms.local credentials are the same.
As far as I know I have just two sets of DMS credentials: the one for accessing this forum and the one for accessing everything else. The “everything else” credentials were automatically created. The forum credentials were created through the forum then linked with the other set by having a common email address.
But, it has been more than a year since I joined so my recollection could easily be different from reality.
Edit: And if that turns out to be true, then “Maker Manager / dms.local credentials” strikes me as a good replacement for “Maker Manager credentials”.
A play on words. The moniker is derived from being quite terrible (rough) at using my Nomad (vagabond) 883 when it arrived. A moniker based in making that is nicely a double entendre.
1 Like
They are not the same, though for most folks, they are coincidental.
MakerManager is “the master”, which is to say, is created first. Then it populates Active Directory. Because we do not require periodic changes, these credentials typically stay the same for most folks. However a change in MM will write to AD in a one-way periodic sync. For what my opinion is worth, I think it is confusing to use “Maker Manager credentials” when that is NOT actually what is used, and otherwise reference “dms\username” as the model in that document (as well as many other places). This is also confusing if/when someone has problems because it masks the way the system actually works. Thus, I prefer to see something more like “dms.local domain credentials” or “dms domain credentials” where this says “Maker Manager credentials”. The MM creds really don’t enter into it for this purpose.
1 Like
SSH Public Keys are not supported. Original setup was concerned that allowing ssh keys would allow access even if account was disabled in AD, IIRC. Have been meaning to look to see if there is a solution for that but it has been low priority.
2 Likes
That’s doable; basically a script runs and checks the users status; if the user doesn’t have valid AD status, the shell is forced out and set to /bin/nologin or /bin/false. You can do it using the ForceCommands operations for user groups that OpenSSH Server supports.
-Jim
Sounds good. “Maker Manager credentials” will be axed.
However, these phrases are used on the wiki (could be more)…
- active directory user name / password
- dms\username domain account
- active directory login
- username of your LDAP/AD account
These are proposed…
- dms.local domain credentials
- dms domain credentials
“LDAP/AD account” has too much acronym. I suggest not using that.
Microsoft uses the phrases “domain name” (DMS) and “domain user name” (roughvagabond). I assume “domain user password” would be used for the password.
The SSH documentation uses the phrase “username”.
The label “Username” is used on the accounts.dallasmakerspace.org form.
What would be the least confusing / most likely to help with troubleshooting / most consistent?
I really don’t like “domain user name”. In my mind that implies something restricted to Windows.
1 Like
Public keys are currently working.
Most linux systems have an ssh-copy-id script, so you can just do:
ssh-copy-id -p 2222 [email protected]
Afterwards ssh and sshfs work without a password prompt.
2 Likes
This goes down the tubes quickly, since “domain user name” is the probably the most widely understood name for an entity most accurately labeled “sAMAccountName” in the Microsoft Active Directory, which is where this information is stored.
Buuuut… It’s being employed here largely as an LDAP, wherein I would call that a “commonName”, or cn i.e. cn=jast,dc=local,dc=dms, although, when used in Linux, that’s usually labelled a “user id (UID)”, i.e. “uid=jast,dc=local,dc=dms”. But I expect roughly nobody to get that; least of all, the folks who most need help. So, against your preferences, and mine, I would continue to try to hone in on “dms.local domain user name” for this type of thing, because it seems least confusing to the most people…