Don't use a password. Generate a passphrase-less SSH key and push it to your VM.
If you already have an SSH key, you can skip this step…
Just hit Enter for the key and both passphrases:
$ ssh-keygen -t rsa -b 2048
Generating public/private rsa key pair.
Enter file in which to save the key (/home/username/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/username/.ssh/id_rsa.
Your public key has been saved in /home/username/.ssh/id_rsa.pub.
Copy your keys to the target server:
$ ssh-copy-id id@server
id@server's password:
Now try logging into the machine, with ssh 'id@server', and check-in:
.ssh/authorized_keys
Note: If you don't have .ssh dir and authorized_keys file, you need to create it first
to make sure we haven’t added extra keys that you weren’t expecting.
Finally, check to log in…
$ ssh id@server
id@server:~$
You may also want to look into using ssh-agent if you want to try keeping your keys protected with a passphrase.
I am not familiar with the specifics of 10.10, but I am going to assume that it is pretty close to Debian.
One thing you could do, is basically setup to separate stunnel configurations. On that accepts SSL, and forwards it to a local port, and another that listens on that local port, and then makes SSL connections to the external host. These two can be bound to the loopback interface only so unencrypted data will not cross the network. Just keep in mind that you are basically performing a MITM attack against yourself. I used a setup like this while I was helping diagnose some issues with a web service a guy was developing.
The packaged version of stunnel in Debian/Ubuntu should make this easy. The startup scripts will basically start an instance of stunnel for every configuration file (*.conf) found in /etc/stunnel4. So you can put the two separate configurations in /etc/stunnel4, generate your keys, restart stunnel and it should work.
So here is the first config that accepts the SSL
; /etc/stunnel/ssl_in.conf
; Certificate/key is needed in server mode and optional in client mode
cert = /etc/stunnel/srv1.keys
; Some security enhancements for UNIX systems - comment them out on Win32
chroot = /var/lib/stunnel4/
setuid = stunnel4
setgid = stunnel4
; PID is created inside chroot jail
pid = /srv1.pid
debug = 4
output = /var/log/stunnel4/ssl_in.log
; Some performance tunings
socket = l:TCP_NODELAY=1
socket = r:TCP_NODELAY=1
[ssl_in_imap]
accept = 993
connect = localhost:10993
[ssl_in_smtp]
accept = 587
connect = localhost:10587
Your second instance that creates outgoing connections.
; /etc/stunnel/ssl_out.conf
; Some security enhancements for UNIX systems - comment them out on Win32
chroot = /var/lib/stunnel4/
setuid = stunnel4
setgid = stunnel4
; PID is created inside chroot jail
pid = /clt1.pid
; Some performance tunings
socket = l:TCP_NODELAY=1
socket = r:TCP_NODELAY=1
client=yes
CAfile = clt1.ca
verify = 0
[ssl_out_imap]
accept = 10993
connect = remote_server:993
[ssl_out_smtp]
accept = 10587
connect = remote_server:10587
To generate the filename.keys for the server.
# Create a new key and preparte a CSR
openssl req -new -keyout filename.pem -out filename.csr
# Remove the passphrase from the key
openssl rsa -in filename.pem -out filename.key
# Self sign
openssl x509 -in filename.csr -out filename.cert -req -signkey filename.key -days 720
# combine files to get the keys file stunnel needs.
cat filename.key filename.cert > filename.keys
Your file will look like this.
-----BEGIN RSA PRIVATE KEY-----
MIICXAIBAAKBgQDkwzyKrPRXGyvEgITm/7oC9fDU4Y7L9mtMXmcIR98cp0g1ndcz
...
qhP3y97k67EVdSC+92pIGrAL7kBWckpJ2HP1El4KeZg=
-----END RSA PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
MIICHzCCAYgCCQDq/33qh7Dq5TANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJV
...
ebbhvhYLx1KkhD8/dXEbU0+kNg==
-----END CERTIFICATE-----
Best Answer
So to clarify: You want passwords to be allowed from the office network, but not from anywhere else. You, however, need to be able to connect from anywhere.
On my network SSH keys are required when logging in from outside but either keys or passwords can be used when connecting from another host on the inside.
Here's how that works:
/etc/ssh/sshd_config
If you substitute your office subnet for 192.168.0.*, users will be able to use passwords to connect, but only from the office subnet. You, however, will be able to use your SSH keypair to connect from anywhere.
When an ssh client connects to the server, it is presented with a list of authentication mechanisms it can try. Typically the list is "publickey, password." In this case, when someone connects from outside, they are only presented with "publickey" so their client will not even attempt to send a password. If they attempt to authenticate with any mechanism other than an SSH public key, the connection is immediately shut down by the server. So no possibility exists for brute-forcing the passwords.