Solutions to problems with SSH

Comments Off on Solutions to problems with SSH

Sometimes ‘ssh’ doesn’t behave as you were hoping. Here are some things to check when it goes awry.

Recall that you may have created your public/private key-pair like this:
ssh-keygen -t rsa -C "[email protected]"

You might have even gone for a heftier bit-length, or even used PKCS8:
ssh-keygen -t rsa -C "[email protected]" -b 4096 -m PKCS8

And you might have remembered to chmod the .ssh folder as 700, and any private keys as 600.

“Someone stole my laptop and got my private keys”
As quickly as you can, go delete the ~/.ssh/authorized_keys file on your destination computers. If your laptop was encrypted with FileVault you don’t have to rush.
1. update your authorised_keys file with new public keys
2. $ for host in othermachine; do scp ~/.ssh/authorized_keys $host:.ssh/; done

Do not trust the security you thought you had due to the passphrase on your private key (created by ssh-keygen) since brute forcing the passphrase only takes a few hours (read here) unless you upgraded to a more secure private key format like PKCS#8 (transparently supported by OpenSSL).
$ mv my_rsa_key my_rsa_key.old
$ openssl pkcs8 -topk8 -v2 des3 \
-in my_rsa_key.old -passin 'pass:snoopy loves secrets too' \
-out test_rsa_key -passout 'pass:snoopy loves secrets too'

Grab Brendan’s keycrypt script here.

“My private keys no longer work under 10.9 (Mavericks).”
Some suggest that Apple removed support for PKCS#8 private keys (sh-agent and keychain stopped supporting PKCS#8 ??).  You may need to undo your encryption or switch to AES256.
$ mv ~/.ssh/id_rsa_mykey ~/.ssh/id_rsa_mykey.pkcs8
$ openssl pkcs8 -in ~/.ssh/id_rsa_mykey.pkcs8 -out ~/.ssh/id_rsa_mykey
$ chmod 600 ~/.ssh/id_rsa_mykey
$ ssh-keygen -f ~/.ssh/id_rsa_mykey -p

A guy named ‘Joe’ suggested that manually adding the encrypted key, does work in 10.9:
# empty the ssh-agent and add the private encrypted key
ssh-add -D
ssh-add ~/.ssh/id_rsa

He then suggests that just reinstalling openssl solves the problem too:
brew update
brew install openssl
brew link openssl --force
brew install openssh

Finally, newer versions of ssh-keygen seem to handle PKCS#8 so openssl no longer needs to be called. Note that Windows users are out-a-luck using puttygen which doesn’t support PKCS#8.

“Roaming not allowed by server”
: Ensure that /etc/ssh/sshd_config has HostbasedAuthentication set to yes.
Remember to restart the ssh daemon: kill -HUP `cat /var/run/`

If you are dealing with a SynlogyDS5, and you don’t want to ssh into root, then you’ll quickly discover that ‘sudo’ won’t exist until you install it with ipkg update; ipkg install sudo. Of course, ‘ipkg’ isn’t available either (ipkg is for installing stuff that is not available in the package center), so start with that (link). Remember to add admin to the sudoers (link).

: Ensure your file permissions are correct.
As the default permissions on a SynlogyDS5 might be 777 (hard to believe) for the home folder of admin, set it them to 755 (in addition to 700 for .ssh/ and 600 for authorized_keys) and you’re good to go.

SMB over SSH from OSX to Linux

Comments Off on SMB over SSH from OSX to Linux

With a remote server (Linux) and a local MacBook Pro (OSX), I needed a way to access files (on the server) from the Finder (on the client). Here’s what worked for me.

Henceforth, I refer to the server as linuxserver and the client as macclient. On macclient, I edited ~/.ssh/config to include this:

Host linuxserver
    ##replace the following with your real IP address
    User shawn
    LocalForward 8139  localhost:139
    ## some people need the following, but not me
    #LocalForward 445 remote_ip_address:445


For the server, after having installed samba (sudo yum install samba), I edited /etc/samba/smb.conf like this:

    workgroup = HOME
    netbios name = SAMBA
    server string = Samba Server Version %v
    map to guest = Bad User
    log file = /var/log/samba/log.%m
    max log size = 50
    #replace the 2nd IP address with that of your server
    hosts allow =
    passdb backend = tdbsam
    socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
    preferred_master = No
    local master = No
    dns proxy = No
    security = User
    path = /home/shawn/sambashare
    valid users = shawn
    read only = No
    create mask = 0777
    directory mask = 0777


As usual, I restarted the smb.service (sudo systemctl restart smb.service).
On the Mac, I opened a terminal and ssh’d into the server. Then, still on the mac, I did command-k and filled the path with smb://localhost:8139/sambashare .

On days that I prefer CLI , this works for me:

mkdir ~/sambamount
mount_smbfs //[email protected]:8139/sambashare ~/sambamount


Other notes:

I did NOT have to set up a loopback interface for this to work (sudo ifconfig lo0 alias up). Using a port higher than 1024 avoids the problem that port 139 (from which SMB is often served) requires sudo to succeed; It also avoids the problem of a preexisting service using that port.

Windows machines do not respond to SMB requests on although with extra work, there are solutions; Consider limiting access to ‘file and printer sharing’.

I could have gone with an alternate networking protocol (such as AFP, NFS) but with OSX embracing SMB2 this route seemed reasonable and functions as I need it to.

This article presupposes that you have already configured your ssh (populated your .ssh/ folder), distributed your public key, and enabled an ssh daemon on your server.

Other solutions:

Using the FUSE project with sshfs, it’s possible to mount a remote filesystem over SSH. On the Mac you would use Fuse4x (install with ‘sudo port install sshfs’) and then just run this: sshfs linuxserver: local-mount-directory.

Other articles: