[How-To] How to Access Your FreeNAS Server Remotely (and Securely)

[Jeren]

I had issues getting the "disable world-writing for home directory" setting to stick. To resolve:

1. Open Shell prompt
2. Enter:

Code:

su - username
sudo chmod go-w $HOME $HOME/.ssh $HOME/.ssh/authorized_keys

Then I was able to ssh in

 

[f8340fidsolfwhf20]

@Glorious1

Thank you so much for the post, the documentation provides some info on each subject but it's by no means a how-to guide for beginners like me :)

I've been following your guide and digging through forums/posts for almost a week now trying to get ssh to work but to no avail. So far I've generated a key using ssh-keygen (client pc is dual booting win10 and linux mint, I'm setting this all up from mint), setup the port forwarding, cron job, and ddns, however I'm stuck at the very beginning of trying to even locally ssh into my NAS.

I've set my port forwarding to use an arbitrary high port both internally/externally on my router and set this as the port in the GUI. I've also copied the contents of the public key in the root user's SSH key field via the GUI. Finally I've went through all of the troubleshooting section and verified the permissions/ownership for everything, but I still get "Permissions denied (publickey)" when trying to ssh with: "ssh -p <port> <clientusername>@<static ip of freenas>". Running the command with -v I get the following (with certain info <hidden>):

ssh -p <port> <cleintusername>@<nas ip> -v
OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to <nas ip> [<nas ip>] port <port>.
debug1: Connection established.
debug1: identity file /home/<cleintusername>/.ssh/id_rsa type 1
debug1: identity file /home/<cleintusername>/.ssh/id_rsa-cert type -1
debug1: identity file /home/<cleintusername>/.ssh/id_dsa type -1
debug1: identity file /home/<cleintusername>/.ssh/id_dsa-cert type -1
debug1: identity file /home/<cleintusername>/.ssh/id_ecdsa type -1
debug1: identity file /home/<cleintusername>/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/<cleintusername>/.ssh/id_ed25519 type -1
debug1: identity file /home/<cleintusername>/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.3
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1_hpn13v11 FreeBSD-20140420
debug1: match: OpenSSH_6.6.1_hpn13v11 FreeBSD-20140420 pat OpenSSH_6.6.1* compat 0x04000000
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5-etm@openssh.com none
debug1: kex: client->server aes128-ctr hmac-md5-etm@openssh.com none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA <key>
debug1: Host '[<nas ip>]:<port>' is known and matches the ECDSA host key.
debug1: Found key in /home/<cleintusername>/.ssh/known_hosts:1
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/<cleintusername>/.ssh/id_rsa
debug1: Authentications that can continue: publickey
debug1: Trying private key: /home/<cleintusername>/.ssh/id_dsa
debug1: Trying private key: /home/<cleintusername>/.ssh/id_ecdsa
debug1: Trying private key: /home/<cleintusername>/.ssh/id_ed25519
debug1: No more authentication methods to try.
Permission denied (publickey).

Most people who had this issue seemed to get it resolved by going through the troubleshooting section, but I've already done that and, as far as I can tell, all is good. I don't expect you to know exactly whats going on from any of this, but do you have any recs for what I can do/check next? Thank you so much!

 

[Glorious1]

@Glorious1

Thank you so much for the post, the documentation provides some info on each subject but it's by no means a how-to guide for beginners like me :)

I've been following your guide and digging through forums/posts for almost a week now trying to get ssh to work but to no avail. So far I've generated a key using ssh-keygen (client pc is dual booting win10 and linux mint, I'm setting this all up from mint), setup the port forwarding, cron job, and ddns, however I'm stuck at the very beginning of trying to even locally ssh into my NAS.

I've set my port forwarding to use an arbitrary high port both internally/externally on my router and set this as the port in the GUI. I've also copied the contents of the public key in the root user's SSH key field via the GUI. Finally I've went through all of the troubleshooting section and verified the permissions/ownership for everything, but I still get "Permissions denied (publickey)" when trying to ssh with: "ssh -p <port> <clientusername>@<static ip of freenas>". Running the command with -v I get the following (with certain info <hidden>):



Most people who had this issue seemed to get it resolved by going through the troubleshooting section, but I've already done that and, as far as I can tell, all is good. I don't expect you to know exactly whats going on from any of this, but do you have any recs for what I can do/check next? Thank you so much!

The preface to the how-to suggests that you establish a local SSH into FreeNAS before you start doing any of the modifications, as it is a bit simpler then. And it is hard to diagnose remotely. But one thing that jumps out is, you said you pasted the key into the root-user's SSH key field. But then you are trying to ssh as "clientusername". Note that the guide suggests you log in as your normal user on FreeNAS, not root. The user where you pasted the key and the user named in your ssh command have to be the same.

Then the "static ip of freenas" - that's the local IP, right, not the public-facing IP of your router? For instance, mine is 192.168.0.xxx.

 

[f8340fidsolfwhf20]

The preface to the how-to suggests that you establish a local SSH into FreeNAS before you start doing any of the modifications, as it is a bit simpler then. And it is hard to diagnose remotely. But one thing that jumps out is, you said you pasted the key into the root-user's SSH key field. But then you are trying to ssh as "clientusername". Note that the guide suggests you log in as your normal user on FreeNAS, not root. The user where you pasted the key and the user named in your ssh command have to be the same.

Then the "static ip of freenas" - that's the local IP, right, not the public-facing IP of your router? For instance, mine is 192.168.0.xxx.

Yeah I figured I shouldn't have skipped getting that to work but wanted to try out the other stuff anyways, at least I can still diagnose it locally.

I guess that's something I'm confused by on the guide; it mentions ssh'ing in with "username@ip", but I'm not sure which username I should use. As in, do I use the username of my user on my computer (in this case lets say it's"kkc" on my laptop), the username "root" on freenas, or do I need to create a user account on the freenas and use that? For a while I was trying to ssh using a user account I made on my freenas, but then I ran into the issue of ownership where the home directory (/~) would have a .ssh folder owned by root, and the home directory for the user (/~/mount/volume/dataset) had a .ssh folder for the user, and as far as I can tell it was trying to access the key in the one owned by root even though I was logging in as the user's username (this is why I switched to just trying to ssh as the root user). Basically I have all my permissions set correctly but I believe something is getting lost in the ownership, which would explain the emails I got from my security report when attempting the original method of logging in as the user with the home .ssh folder owned by root: "Authentication refused: bad ownership or modes for file /mount/volume/dataset/.ssh/authorized_keys"

When I say static ip, I mean when I was first setting up freenas, I configured a network interface from the command line (option 1) so it would always be the same ip for the gui (and just in general) of the format 192.168.1.xxx

 

[Glorious1]

kkc, this sounds like it should be easy to fix. Sounds like you've got the IP right, just the user problem. The user on your client computer doesn't matter. Your ssh command needs to specify the user whose account you're logging into on the NAS. That could be root, or it could be a regular user.

I gather a lot of people log in as root, but I think it's officially deprecated, and I don't - I have root login disabled in the GUI. I have a user "jim" on my NAS, just like on my laptop. If you need root-like privileges, you can log in as you, type "su", and enter the root password (there's a setting in the GUI to allow this per user). Somehow it's more secure than just logging in as root.

If you go the way I do, you would make a user 'kkc' on the NAS, and paste the public key into that user's dialog, and use that user's name in the SSH command. Should work, in theory. Make sure the command specifies the right IP and SSH port that you set in the GUI.

 

[f8340fidsolfwhf20]

Finally got it working locally; the source of the issue was the user account was located in /~/mount/volume/ and the permissions for the /volume/ (controlled in the storage section of the GUI) had write enabled for the group. What I don't understand is I had noticed this days ago, but when I'd try to change it, it wouldn't actually change, reporting an error that indicated chmod was an invalid operation. This was why I sort of abandoned trying to log on with the user account and switched to the root account instead. For some reason this time it let me change the permissions and it actually retained the change without giving the error. Either way, thanks for all of the extra info! I've gotten it to work, gotten port forwarding to work, and my cron job gave me the OK :) I still need to try it remotely but at this point I've gotten the jist of what I've been doing wrong.

For anyone else that comes across this later on, here's another strange issue I ran into that I managed to fix: the first time ssh worked and it asked for my key's passphrase, I couldn't remember it, so I just clicked cancel and went to go find it. When I came back and tried ssh'ing again, it would outright refuse my connection. Upon -v inspection, the Agent was reporting an admitted failure to provide a passphrase, even though it wouldn't prompt me for one and would just outright deny the connection. I found this (https://chrisjean.com/ubuntu-ssh-fix-for-agent-admitted-failure-to-sign-using-the-key/) article which explains the issue in depth and a few easy (and a few not so easy) ways to get around this. What worked for me was simply rebooting the client, but if that doesn't work, try generating a new key pair and using that.

 

[Glorious1]

Finally got it working locally; the source of the issue was the user account was located in /~/mount/volume/ and the permissions for the /volume/ (controlled in the storage section of the GUI) had write enabled for the group.

This doesn't make any sense. The path to the user's home directory is designated as ~, so how could it be at ~/mount/volume/? My home directory has no 'mount' directory in it. Seems like you must have set up things a bit oddly.
If you ever set up your FreeNAS again, I suggest you don't touch permissions of your volume, only the datasets within it.

 

[f8340fidsolfwhf20]

I might have just explained it poorly. When I ssh in, I'm at my home directory (~) and a call to ls shows the directory for the user account as well as the directories for the jails and the dataset. If I cd up a couple directories to the root directory (/), I can see that to get back to my home directory, I can either call "cd home" or "cd mount/volume" where mount is the disk and volume is the volume the dataset, user, and jails are in. I read through the documentation and tried following a few articles and video guides but no one ever seemed to mention the recommenced conventions on where to place user home directories and things like that- where should I be placing all of my stuff such as users and jails relative to where all of my data is?

 

[intelligence]

Trying to get this to work, but have no luck. I get connection failed after setting up the proxy in Firefox.
On OSX 10.10.5, if it makes a difference.

Edit: Adding

Code:

AllowTCPForwarding yes

in /etc/ssh/sshd_config solved it!

Code:

local:~ user$ ssh -v -D 15443 -p 52739 user@xxx.duckdns.org -g
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /Users/user/.ssh/config
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: /etc/ssh_config line 102: Applying options for *
debug1: Connecting to xxx.duckdns.org [x.x.x.x] port 52739.
debug1: Connection established.
debug1: identity file /Users/user/.ssh/id_rsa type 1
debug1: identity file /Users/user/.ssh/id_rsa-cert type -1
debug1: identity file /Users/user/.ssh/id_dsa type -1
debug1: identity file /Users/user/.ssh/id_dsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1_hpn13v11 FreeBSD-20140420
debug1: match: OpenSSH_6.6.1_hpn13v11 FreeBSD-20140420 pat OpenSSH*
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5-etm@openssh.com none
debug1: kex: client->server aes128-ctr hmac-md5-etm@openssh.com none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA a1:7b:05:11:08:51:65:13:96:17:84:f3:0a:28:a7:28
debug1: Host ’[xxx.duckdns.org]:52739' is known and matches the RSA host key.
debug1: Found key in /Users/user/.ssh/known_hosts:17
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/user/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug1: Authentication succeeded (publickey).
Authenticated to xxx.duckdns.org ([x.x.x.x]:52739).
debug1: Local connections to *:15443 forwarded to remote address socks:0
debug1: Local forwarding listening on :: port 15443.
debug1: channel 0: new [port listener]
debug1: Local forwarding listening on 0.0.0.0 port 15443.
debug1: channel 1: new [port listener]
debug1: channel 2: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = sv_SE.UTF-8
Last login: Fri Dec 18 23:12:33 2015 from x.x.x.x
FreeBSD 9.3-RELEASE-p13 (FREENAS.amd64) #0 r281084+3bda974: Tue May 12 21:03:11 PDT 2015

    FreeNAS (c) 2009-2015, The FreeNAS Development Team
    All rights reserved.
    FreeNAS is released under the modified BSD license.

    For more information, documentation, help or support, go here:
     http://freenas.org
Welcome to FreeNAS
[user@server ~]$ debug1: Connection to port 15443 forwarding to socks port 0 requested.
debug1: channel 3: new [dynamic-tcpip]
channel 3: open failed: administratively prohibited: open failed
debug1: channel 3: free: direct-tcpip: listening port 15443 for 192.168.1.10 port 80, connect from ::1 port 49333, nchannels 4
debug1: Connection to port 15443 forwarding to socks port 0 requested.
debug1: channel 3: new [dynamic-tcpip]
channel 3: open failed: administratively prohibited: open failed
debug1: channel 3: free: direct-tcpip: listening port 15443 for 192.168.1.10 port 80, connect from ::1 port 49334, nchannels 4

 

[nojohnny101]

@Glorious1

Thank you so very much for your write up! It has helped me tremendously and I feel as though I have everything up and running fine. I can connect locally to the freenas box through SSH in the terminal using the static IP address. However I am having problems when trying to login through my domain with duckdns.org

i get a "port 22: operation timed out" error message in terminal. Any ideas? I am connecting from the internal network because I thought I would make sure it worked before going outside the new network. I can't figure out where the connecting is failing. I have confirmed my cron job is running correct as I get an "OK".

I even made sure to add the static IP address under the global configuration screen in the freenas gui in the "host name data base" section. Some people suggested when you give the freenas box a static IP, it reset the hostname file and it can mess things up.

Any ideas?

 

[Glorious1]

Try it from outside your local network. I think for some reason going through the dynamic domain doesn't work from inside the local network it points to. Maybe someone else can explain that. No harm in going somewhere else and trying it.

I'm confused by your last paragraph. If you really have a static (=permanent) internet IP address, you don't need a dynamic DNS service like duckdns.org. Typically your internet IP address is subject to change by your internet service provider.

 

[nojohnny101]

Try it from outside your local network. I think for some reason going through the dynamic domain doesn't work from inside the local network it points to. Maybe someone else can explain that. No harm in going somewhere else and trying it.

I'm confused by your last paragraph. If you really have a static (=permanent) internet IP address, you don't need a dynamic DNS service like duckdns.org. Typically your internet IP address is subject to change by your internet service provider.

hey glorious1!

i actually did have my brother who is in another state try accessing the freenas and he got the same "timed out" error.

And sorry, what i meant in that last paragraph is that i assigned a static IP to the freenas within the internal network. i do not have a public facing static IP from the ISP.

any other ideas or leads i can investigate? your instructions were so thorough and everything checks out (SSH is working internally with the IP address, curl command returns "OK", etc.). there has to be something missing though.....

 

[Glorious1]

Just guessing here - maybe it's a port issue between your router and FreeNAS?
1. Make sure whatever port you're using in your external SSH command (52739 in following example)
ssh -p 52739 <you>@<subdomain>.duckdns.org
is the external start/end port that is forwarded by your router.
2. Also make sure that internal port in your router forwarding is the same as the SSH port assigned in FreeNAS SSH settings, TCP port (22 by default).
3. Also make sure that the router forwarding uses the correct local IP address for your FreeNAS box.

 

[SweetAndLow]

You can also try to ping your domain name and see what ip you get back and make sure that it's correct. The ping probably won't work but its an easy way to test that the name resolves.

Also try just using the external ip and not the DNS name.

 

[Glorious1]

Also try just using the external ip and not the DNS name.

Good suggestion. I actually thought of that but forgot to mention it. That should help determine if it is a problem with the dynamic domain vs. your local setup.

 

[nojohnny101]

hey
thanks guys. i was reading around the internet also and i found a suggestion to set the route to DMZ host to see if the ISP is blocking port 22 or if it is a firewall issue.

Well the router I am using is a cable modem and router in one. So i went into the configuration settings and when it asked for the IP address to set as the DMZ host I put the one of the computer I am trying to SSH from to the freenas server....and it made a difference! I tried the regular command:
"ssh username@makrinos.duckdns.org" and it gave me a prompt for my password, which i assume is my SSH passphrase. well i enter that passphrase and it gives me this:
"permission denied (publickey, keyboard-interactive)"

i read that that message can mean a whole host of things but does that point to permissions problems. and since it is working (or seem so to be) now that I have the computer (not the freenas) as the DMZ host, does that show the ISP is blocking port 22?

Lastly, i get the same permission denied with the external IP address as you guys suggested.

 

[Glorious1]

Just my opinion, you might be making it more complicated with the DMZ stuff.

It sounds like you have a second problem, which is likely a key or permission issue. Make sure you put the public key in the right place, and check all the permissions described in the Troubleshooting section in the first post.

 

[nojohnny101]

@Glorious1
thanks for the tip. It is interesting though that once I changed the DMZ setting, I got further along in the authentication process with SSH then before. Before changing that setting, I wouldn't even get to the passphrase prompt.

What can I do to check permission of the SSH files on the server? I have only ever made changes through the GUI of the freenas box. Do you know the commands to check the permission on say, the id_rsa files?

i appreciate the continued help!
------------------------------------------
EDIT: one other interesting note. when i SSH directly both the internal static IP address of the freenas box through the terminal on mac os X, it brings up a prompt window outside of the terminal window prompting for the ssh passphrase. when i enter it, it connects. doing the same thing while trying to connect to the subdomain, the password prompt is within the terminal window, not a separate prompt like with the static IP address. Strange.

Does that mean that when i access through the subdomain, it tries to authentic with a password instead of the ssh passphrase? i unchecked the option "allow password authentication" in the GUI of the freenas box under the SSH settings. is this what it is trying to do when connecting through the subdomain? and if that is the case, of course it would be denied because it is not setup to handle that.

 

[Glorious1]

@Glorious1
thanks for the tip. It is interesting though that once I changed the DMZ setting, I got further along in the authentication process with SSH then before. Before changing that setting, I wouldn't even get to the passphrase prompt.

I don't know about DMZ, but I suspect it is bypassing a problem. It shouldn't be necessary.

What can I do to check permission of the SSH files on the server? I have only ever made changes through the GUI of the freenas box. Do you know the commands to check the permission on say, the id_rsa files?

I think you said you can successfully SSH in locally? After you do, you should be in your home folder if you've set it up right. Type "ls -la" and one thing you see should be your .ssh folder. If it isn't there, you didn't set things up right. If it is, just go "cd .ssh" to get into your .ssh folder, then "ls -la" to see the files and permissions. Everything should be owned by you. The .ssh folder should have permissions 700 (drwx------), and the authorized keys file 644 (-rw-r--r--). Also check the permissions/owners in the .ssh folder in your home folder on the Mac. There id_rsa should be 600 (-rw-------).

when i SSH directly both the internal static IP address of the freenas box through the terminal on mac os X, it brings up a prompt window outside of the terminal window prompting for the ssh passphrase.

This is the ssh program on the mac requiring you to give the passphrase before it will open your private key on the mac. It shouldn't always do that except after you restart or a long time or something. I'm not sure why it is inside your window sometimes and outside others. In any case, you definitely don't want password authentication on your FreeNAS box - that defeats the whole system you're trying to set up.

 

[nojohnny101]

@Glorious1
Ok thanks for the help, I cd into the .ssh folder (it's there!) and this is the screenshot of the permissions:

i think it differs a bit from you said it should.