Sharing a disk on a Windows 11 bhyve VM and mounting it on FreeBSD over SSH.

Hello. I'm again here to learn how to make a secure samba v.1 connection.

Goal : to be able to mount a Windows share (configured inside a Windows 11 bhyve-VM) on a single remote host OS (FreeBSD) over SSH.

Take in consideration that mount_smbfs(8) on FreeBSD only supports SMBv1.mount_smbfs(8) only supports SMBv1. I know that it has been switched off on Windows,but if I want to share the Windows drives and access them on FreeBSD,I should turn it back on. But no problem,because my goal is to secure the SMBv1 connection over SSH. This is the goal of this project.

I've followed some instructions according with this tutorial :


Host / Local OS : FreeBSD 13R with IP = 192.168.1.3

where I have configured the network like this :


Code:
/etc/sysctl.conf

kern.maxfiles=25600

kern.maxfilesperproc=16384

net.inet.tcp.sendspace=65536

net.inet.tcp.recvspace=65536



/boot/loader.conf:

aio_load="YES"



nano /etc/rc.conf

hostname="marietto"

ifconfig_em0="DHCP"

samba_server_enable="YES"

local_unbound_enable="YES"

sshd_enable="YES"

gateway_enable="YES"

winbindd_enable="NO"

cloned_interfaces="bridge0 tap0 tap1 tap2 tap3 tap4 eth0 lo1"

ifconfig_bridge0="addm em0 addm tap0 addm tap1 addm tap2 addm tap3 addm tap4"


Guest / Remote OS Windows 11 with IP number = 192.168.1.4 :


0) started ssh server :

Code:
PS C:\Users\virtu\Downloads\cmder> Set-Service -Name sshd -StartupType 'Automatic'

PS C:\Users\virtu\Downloads\cmder> Start-Service sshd

1) blocked SMB and RDP port through Windows Firewall,following this tutorial :

View: https://www.youtube.com/watch?v=kk3XSSAeqOo


2) changed the list of services on which the lanmanserver services depends by adding the iphlpsvc service to the list of required
services

Code:
sc config lanmanserver depend= samss/srv2/iphlpsvc

3) added a portproxy rule to reroute TCP port 445 to a port of my choosing. I choose 44445 :

Code:
netsh interface portproxy add v4tov4 listenaddress=127.0.0.1 listenport=445 connectaddress=127.0.0.1 connectport=44445


on FreeBSD :


Now that I have configured both my loopback adapters I've launched a special OpenSSH connection and I've tried to mount the shares from the remote server 192.168.1.4 as a Windows share:

I've launched an openSSH session with some special port-forwarding rules and I tried to login on 192.168.1.4 as normal.


I've typed on FreeBSD terminal 1 :

Code:
# ssh -v -N -n -L 127.0.0.1:44445:192.168.1.4:445 marietto@192.168.1.4


OpenSSH_7.9p1, OpenSSL 1.1.1k-freebsd  24 Aug 2021

debug1: Reading configuration data /etc/ssh/ssh_config

debug1: Connecting to 192.168.1.4 [192.168.1.4] port 22.

debug1: Connection established.

debug1: identity file /root/.ssh/id_rsa type -1

debug1: identity file /root/.ssh/id_rsa-cert type -1

debug1: identity file /root/.ssh/id_dsa type -1

debug1: identity file /root/.ssh/id_dsa-cert type -1

debug1: identity file /root/.ssh/id_ecdsa type -1

debug1: identity file /root/.ssh/id_ecdsa-cert type -1

debug1: identity file /root/.ssh/id_ed25519 type -1

debug1: identity file /root/.ssh/id_ed25519-cert type -1

debug1: identity file /root/.ssh/id_xmss type -1

debug1: identity file /root/.ssh/id_xmss-cert type -1

debug1: Local version string SSH-2.0-OpenSSH_7.9 FreeBSD-20200214

debug1: Remote protocol version 2.0, remote software version OpenSSH_for_Windows_8.1

debug1: match: OpenSSH_for_Windows_8.1 pat OpenSSH* compat 0x04000000

debug1: Authenticating to 192.168.1.4:22 as 'marietto'

debug1: SSH2_MSG_KEXINIT sent

debug1: SSH2_MSG_KEXINIT received

debug1: kex: algorithm: curve25519-sha256

debug1: kex: host key algorithm: ecdsa-sha2-nistp256

debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none

debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none

debug1: expecting SSH2_MSG_KEX_ECDH_REPLY

debug1: Server host key: ecdsa-sha2-nistp256 SHA256:RGB7H9jbBp2utEo/wLncUl+eoslePaz2dF2lIA7IpCM

debug1: skipped DNS lookup for numerical hostname

The authenticity of host '192.168.1.4 (192.168.1.4)' can't be established.

ECDSA key fingerprint is SHA256:RGB7H9jbBp2utEo/wLncUl+eoslePaz2dF2lIA7IpCM.

No matching host key fingerprint found in DNS.

Are you sure you want to continue connecting (yes/no)? yes

Warning: Permanently added '192.168.1.4' (ECDSA) to the list of known hosts.

debug1: rekey after 134217728 blocks

debug1: SSH2_MSG_NEWKEYS sent

debug1: expecting SSH2_MSG_NEWKEYS

debug1: SSH2_MSG_NEWKEYS received

debug1: rekey after 134217728 blocks

debug1: Will attempt key: /root/.ssh/id_rsa

debug1: Will attempt key: /root/.ssh/id_dsa

debug1: Will attempt key: /root/.ssh/id_ecdsa

debug1: Will attempt key: /root/.ssh/id_ed25519

debug1: Will attempt key: /root/.ssh/id_xmss

debug1: SSH2_MSG_EXT_INFO received

debug1: Fssh_kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>

debug1: SSH2_MSG_SERVICE_ACCEPT received

debug1: Authentications that can continue: publickey,password,keyboard-interactive

debug1: Next authentication method: publickey

debug1: Trying private key: /root/.ssh/id_rsa

debug1: Trying private key: /root/.ssh/id_dsa

debug1: Trying private key: /root/.ssh/id_ecdsa

debug1: Trying private key: /root/.ssh/id_ed25519

debug1: Trying private key: /root/.ssh/id_xmss

debug1: Next authentication method: keyboard-interactive

debug1: Authentications that can continue: publickey,password,keyboard-interactive

debug1: Next authentication method: password

marietto@192.168.1.4's password:

debug1: Authentications that can continue: publickey,password,keyboard-interactive

debug1: Authentication succeeded (password).

Authenticated to 192.168.1.4 ([192.168.1.4]:22).

debug1: Local connections to 127.0.0.1:44445 forwarded to remote address 192.168.1.4:445

debug1: Local forwarding listening on 127.0.0.1 port 44445.

debug1: channel 0: new [port listener]

debug1: Requesting tun unit 2147483647 in mode 1

debug1: Fssh_sys_tun_open: /dev/tun100 mode 1 fd 6

debug1: Tunnel forwarding using interface tun100

debug1: channel 1: new [tun]

debug1: Requesting no-more-sessions@openssh.com

debug1: Entering interactive session.

debug1: pledge: exec

debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0


On FreeBSD terminal 2 : According with the tutorial I shouldn't make this step :


Code:
# mount_smbfs -I 127.0.0.1 -U marietto //Marietto-window/h /mnt/windows-drive-h


Password:

mount_smbfs: unable to open connection: syserr = RPC struct is bad


I've also tried on Linux as host/local OS,terminal 1 :


Code:
# ssh -v -N -n -L 127.0.0.1:44445:192.168.1.4:445 marietto@192.168.1.4


openSSH_8.4p1 Ubuntu-6ubuntu2.1, OpenSSL 1.1.1l  24 Aug 2021

debug1: Reading configuration data /root/.ssh/config

debug1: /root/.ssh/config line 1: Applying options for *

debug1: Reading configuration data /etc/ssh/ssh_config

debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files

debug1: /etc/ssh/ssh_config line 21: Applying options for *

debug1: Connecting to 192.168.1.4 [192.168.1.4] port 22.

debug1: Connection established.

debug1: identity file /root/.ssh/id_rsa type -1

debug1: identity file /root/.ssh/id_rsa-cert type -1

debug1: identity file /root/.ssh/id_dsa type -1

debug1: identity file /root/.ssh/id_dsa-cert type -1

debug1: identity file /root/.ssh/id_ecdsa type -1

debug1: identity file /root/.ssh/id_ecdsa-cert type -1

debug1: identity file /root/.ssh/id_ecdsa_sk type -1

debug1: identity file /root/.ssh/id_ecdsa_sk-cert type -1

debug1: identity file /root/.ssh/id_ed25519 type -1

debug1: identity file /root/.ssh/id_ed25519-cert type -1

debug1: identity file /root/.ssh/id_ed25519_sk type -1

debug1: identity file /root/.ssh/id_ed25519_sk-cert type -1

debug1: identity file /root/.ssh/id_xmss type -1

debug1: identity file /root/.ssh/id_xmss-cert type -1

debug1: Local version string SSH-2.0-OpenSSH_8.4p1 Ubuntu-6ubuntu2.1

debug1: Remote protocol version 2.0, remote software version OpenSSH_for_Windows_8.1

debug1: match: OpenSSH_for_Windows_8.1 pat OpenSSH* compat 0x04000000

debug1: Authenticating to 192.168.1.4:22 as 'marietto'

debug1: SSH2_MSG_KEXINIT sent

debug1: SSH2_MSG_KEXINIT received

debug1: kex: algorithm: curve25519-sha256

debug1: kex: host key algorithm: ecdsa-sha2-nistp256

debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none

debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none

debug1: expecting SSH2_MSG_KEX_ECDH_REPLY

debug1: Server host key: ecdsa-sha2-nistp256 SHA256:AG

The authenticity of host '192.168.1.4 (192.168.1.4)' can't be established.

ECDSA key fingerprint is SHA256:AG

Are you sure you want to continue connecting (yes/no/[fingerprint])? yes

Warning: Permanently added '192.168.1.4' (ECDSA) to the list of known hosts.

debug1: rekey out after 134217728 blocks

debug1: SSH2_MSG_NEWKEYS sent

debug1: expecting SSH2_MSG_NEWKEYS

debug1: SSH2_MSG_NEWKEYS received

debug1: rekey in after 134217728 blocks

debug1: Will attempt key: /root/.ssh/id_rsa

debug1: Will attempt key: /root/.ssh/id_dsa

debug1: Will attempt key: /root/.ssh/id_ecdsa

debug1: Will attempt key: /root/.ssh/id_ecdsa_sk

debug1: Will attempt key: /root/.ssh/id_ed25519

debug1: Will attempt key: /root/.ssh/id_ed25519_sk

debug1: Will attempt key: /root/.ssh/id_xmss

debug1: SSH2_MSG_EXT_INFO received

debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>

debug1: SSH2_MSG_SERVICE_ACCEPT received

debug1: Authentications that can continue: publickey,password,keyboard-interactive

debug1: Next authentication method: publickey

debug1: Trying private key: /root/.ssh/id_rsa

debug1: Trying private key: /root/.ssh/id_dsa

debug1: Trying private key: /root/.ssh/id_ecdsa

debug1: Trying private key: /root/.ssh/id_ecdsa_sk

debug1: Trying private key: /root/.ssh/id_ed25519

debug1: Trying private key: /root/.ssh/id_ed25519_sk

debug1: Trying private key: /root/.ssh/id_xmss

debug1: Next authentication method: keyboard-interactive

debug1: Authentications that can continue: publickey,password,keyboard-interactive

debug1: Next authentication method: password

marietto@192.168.1.4's password:

debug1: Authentication succeeded (password).

Authenticated to 192.168.1.4 ([192.168.1.4]:22).

debug1: Local connections to 127.0.0.1:44445 forwarded to remote address 192.168.1.4:445

debug1: Local forwarding listening on 127.0.0.1 port 44445.

debug1: channel 0: new [port listener]

debug1: Requesting no-more-sessions@openssh.com

debug1: Entering interactive session.

debug1: pledge: exec

debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0


On Linux as Host / local OS,terminal 2 : According with the tutorial I shouldn't make this step :


Code:
# mount -t cifs //127.0.0.1/g /mnt/windows-drive-g -o user=marietto,vers=1.0 --verbose


Password for marietto@//127.0.0.1/g:


mount.cifs kernel mount options: ip=127.0.0.1,unc=\\127.0.0.1\g,vers=1.0,user=marietto,pass=********

mount error: Server abruptly closed the connection.

This can happen if the server does not support the SMB version you are trying to use.

The default SMB version recently changed from SMB1 to SMB2.1 and above. Try mounting with vers=1.0.

mount error(112): Host is down

Refer to the mount.cifs ( manual  page (e.g. man mount.cifs) and kernel log messages (dmesg)


dmesg :


[ 4629.726125] FS-Cache: Loaded

[ 4629.779378] FS-Cache: Netfs 'cifs' registered for caching

[ 4629.782797] Key type cifs.spnego registered

[ 4629.782807] Key type cifs.idmap registered

[ 4629.783107] Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers

[ 4629.783111] CIFS: VFS: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers

[ 4629.783114] CIFS: Attempting to mount \\127.0.0.1\g

[ 4629.783623] CIFS: VFS: cifs_mount failed w/return code = -112


This is the step that I should make according with the tutorial :

Go to Start->Run and type \\127.0.0.1\

In the Console window I should now see a line : debug1: Connection to port 44445 forwarding to fs.example.org:445 requested.


But I never saw it. In Linux it seems a little bit better because I can see the folders that I have shared on Windows 11 and it says that can be mounted (while in FreeBSD I don't see them at all),anyway in both cases I'm not able to mount them :
 

Attachments

  • Screenshot_2022-04-22_21-32-26.jpg
    Screenshot_2022-04-22_21-32-26.jpg
    12.3 KB · Views: 123
  • Screenshot_2022-04-22_23-25-52.jpg
    Screenshot_2022-04-22_23-25-52.jpg
    104.3 KB · Views: 112
Well, to respond to your question/statement in regards to smb3 working on FreeBSD 13; the answer lies in the details.
In short, smb3 does work on FreeBSD 13.x; the issue lies in the direction used...
Going from FreeBSD -> Windows client works fine; going from Windows -> FreeBSD client not so great...
As you mentioned in the other thread, mount_smbfs works for smbv1, not higher; thus almost making it completely worthless.

The path forward:
From what I've been seeing, the path forward using smb/cifs is a rocky route.
Option 1: A possible solution if you really need to access an windows share; you could potentially check out sysutils/fusefs-smbnetfs. I haven't tested/used but saw it mentioned in another thread as an possibility.
Option 2: Using smbclientfrom the samba port package (samba48, 412, 413). Downside of that, is pulling in the whole samba mess. I don't know, if you can clobber something up to mount using that.
Option 3: For completeness wise, you can try to use gvfs to mount smb3. Again, untested but been mentioned before multiple times.

Overall, using Samba's official smbclient seems to be the path that has a more official supported feel to it.

Beyond that, it seems getting smb3 working better on FreeBSD seems to be a pipe dream at this point. From a little bit of research turns up the desire (even from FreeBSD devs) but it doesn't seem likely at this time. A possibility seems to be porting Linux kernel's CIFS module to FreeBSD kernel, but thar be sharks in the water in that path.
 
ok. option 4 : to secure the smb1 connection forwarding the port and using an SSH tunnel ? What I tried to do but it is not working. What do u think about this path ? did u read what I tried to do ? can u replicate it ? I've got the idea by reading this post :


but I have changed the method a little bit.
 
It is hard to say where the problem is. Right now, it is seeming like the portproxy is seeming to be the questionable variable. I've seen multiple posts indicating on doing the portproxy (none authoritative that you need to do this). The other part that raises a question on Windows SMB 1.0/CIFS feature it is separated to client and server. This to me, is making me think Windows is making all shares by default to using smb2/3 and you may have to jump through some hoops to specifically make a smb1/cifs share.

On a side note, for something else to keep an eye out for, is on the password authentication between windows and samba. I am unsure how that would affect smb1 and/or with Freebsd being the client. I know on When FreeBSD samba was the server hosting the share, windows used a different password authentication process than Samba used/accepted.
 
Back
Top