DSSH was written as a direct replacement for the OpenSSH client. It adds SSH over SSH tunneling capabilities (for example, to log in to a network hidden by a firewall), scripting support (using BeanShell), an advanced agent (which allows storing of passwords) and "su -" interactive logging for machines that have disabled direct root login. All of this was done to enable automated scripting and logging to many machines based on a few simple rules.

1. DSSH
Juraj Bednár

2. The problem
● SSH clients allow for a simple kind of “VPN access”
● access control
● channel protection through cryptography
● Not well suited for “traversing through VPNs”
● I have to login to our company's server
● Then I can login to a customer's firewall (or use a VPN)
● From there I can login to the server

3. The problem
● What if I need to restart application on ten servers?
● In addition, there's PermitRootLogin no
● Passwords are (of course) different on each server
● I have to decrypt the passwords (I can't remember passwords for
hundreds of servers), do an ssh, login through key, type “su -”, cut &
paste the password
● Takes me tens of minutes

4. The solution: DSSH
● Enter DSSH
● Secure storage of key material through dssh-agent (much more
secure than ssh-agent)
● Scriptable
● In the end
● Populate agent with material (one script involving gpg)
● for i in 1 2 3 4 5 6 7 8 9 10;do dssh root@server${i} svcadm refresh
applicationname; done

5. DSSH: Authentication
● It is not always possible to use public key cryptography for
authentication
● PermitRootLogin no
● Some devices (network infrastructure) have no support for keys
● Administrator does not need to know the passwords, he needs
them properly used at the right time
● Randomly generated passwords (different for each server)

6. DSSH: Authentication
● DSSH<->Agent mutual authentication using X.509 certificates
● Agent never reveals private key
● DSSH client on your (trusted) machine does the key validation (even
if it's forwarded) and then decides if it will communicate with the server
(unlike ssh-agent from OpenSSH)

7. DSSH: scriptability
● Scriptability through the use of BeanShell
● Authentication, target server and how to connect there fully scriptable
● Can have “internal hostnames”, that are resolved by script
● Different paths for different servers
● Some servers need to use “su” or “ena” for leveraging privileges
● Logging and auditing support (root is root, but who used that
privilege?)

8. DSSH: portability and security
● Uses Java (no buffer overflows, no integer overflows, ...)
● Uses JCA (well-audited cryptography standards implementation)
● Is open-source
● Uses proven Java SSH library (used by Google or JetBrains)
● Passwords don't matter at all -> can be changed by script
● Needs only terminal emulator (xterm, linux console, mac os x
terminal) => works almost everywhere (haven't tried on Windows'
xterm or putty)

9. DSSH: Why Open-Source?
● People know what we use to access their servers
● Better quality of libraries and code (if we write code just for us, the
“let's document it later” approach will prevail)
● We use a lot of open-source in DSSH, let's give something back
● DSSH uses code from OpenSSH, Trilead-SSH, BeanShell, Java,
GNU GetOpt, OpenCSV – we build on open technologies

10. History and future
● Started as a tiny project, now supports most of the standard ssh
features (port forwarding, scp, ...)
● Switched from Groovy to Beanshell, cut startup time to a third (the
rest is Java), project size and memory footprint from 2.2MB to 500KB
● Future: Auditing “transit server” that records session for auditability
purposes
● Users never ever store key material (other than their X.509 certificate)
on their computers, even in encrypted form

11. Thank you
Questions?
http://opensource.digmia.com/