**SSH or Secure Shell or Secure Socket Shell,** is a network protocol that gives users a **secure way to access a computer over an unsecured network.**
* [openSSH](http://www.openssh.org/) – OpenBSD SSH, shipped in BSD, Linux distributions and Windows since Windows 10
* [Dropbear](https://matt.ucc.asn.au/dropbear/dropbear.html) – SSH implementation for environments with low memory and processor resources, shipped in OpenWrt
* [PuTTY](https://www.chiark.greenend.org.uk/~sgtatham/putty/) – SSH implementation for Windows, the client is commonly used but the use of the server is rarer
* [CopSSH](https://www.itefix.net/copssh) – implementation of OpenSSH for Windows
**SSH libraries \(implementing server-side\):**
* [libssh](https://www.libssh.org/) – multiplatform C library implementing the SSHv2 protocol with bindings in [Python](https://github.com/ParallelSSH/ssh-python), [Perl](https://github.com/garnier-quentin/perl-libssh/) and [R](https://github.com/ropensci/ssh); it’s used by KDE for sftp and by GitHub for the git SSH infrastructure
* [wolfSSH](https://www.wolfssl.com/products/wolfssh/) – SSHv2 server library written in ANSI C and targeted for embedded, RTOS, and resource-constrained environments
* [Apache MINA SSHD](https://mina.apache.org/sshd-project/index.html) – Apache SSHD java library is based on Apache MINA
[https://github.com/jtesta/ssh-audit](https://github.com/jtesta/ssh-audit) is an updated fork from [https://github.com/arthepsy/ssh-audit/](https://github.com/arthepsy/ssh-audit/)
**Features:**
* SSH1 and SSH2 protocol server support;
* analyze SSH client configuration;
* grab banner, recognize device or software and operating system, detect compression;
* gather key-exchange, host-key, encryption and message authentication code algorithms;
* output algorithm information \(available since, removed/disabled, unsafe/weak/legacy, etc\);
* output algorithm recommendations \(append or remove based on recognized software version\);
* output security information \(related issues, assigned CVE list, etc\);
* analyze SSH version compatibility based on algorithm information;
* historical information from OpenSSH, Dropbear SSH and libssh;
## Brute force usernames, passwords and private keys
### Username Enumeration
In some versions of OpenSSH you can make a timing attack to enumerate users. You can use a metasploit module in order to exploit this:
```text
msf> use scanner/ssh/ssh_enumusers
```
### [Brute force](../brute-force.md#ssh)
Some common ssh credentials [here ](https://github.com/danielmiessler/SecLists/blob/master/Passwords/Default-Credentials/ssh-betterdefaultpasslist.txt)and [here](https://github.com/danielmiessler/SecLists/blob/master/Passwords/Common-Credentials/top-20-common-SSH-passwords.txt) and below.
### Private/Public Keys BF
If you know some ssh private key that could be used... lets try it. You can use the nmap script:
By default most SSH server implementation will allow root login, it is advised to disable it because if the credentials of this accounts leaks, attackers will get administrative privileges directly and this will also allow attackers to conduct bruteforce attacks on this account.
Another common SSH misconfiguration is often seen in SFTP configuration. Most of the time when creating a SFTP server the administrator want users to have a SFTP access to share files but not to get a remote shell on the machine. So they think that creating a user, attributing him a placeholder shell \(like `/usr/bin/nologin` or `/usr/bin/false`\) and chrooting him in a jail is enough to avoid a shell access or abuse on the whole file system. But they are wrong, **a user can ask to execute a command right after authentication before it’s default command or shell is executed**. So to bypass the placeholder shell that will deny shell access, one only has to ask to execute a command \(eg. `/bin/bash`\) before, just by doing:
This configuration will allow only SFTP: disabling shell access by forcing the start command and disabling TTY access but also disabling all kind of port forwarding or tunneling.
The **sftp** have the command "**symlink**". Therefor, if you have **writable rights** in some folder, you can create **symlinks** of **other folders/files**. As you are probably **trapped** inside a chroot this **won't be specially useful** for you, but, if you can **access** the created **symlink** from a **no-chroot****service** \(for example, if you can access the symlink from the web\), you could **open the symlinked files through the web**.
For example, to create a **symlink** from a new file **"**_**froot**_**" to "**_**/**_**"**:
```text
sftp> symlink / froot
```
If you can access the file "_froot_" via web, you will be able to list the root \("/"\) folder of the system.
On high security environment it’s a common practice to enable only key-based or two factor authentication rather than the simple factor password based authentication. But often the stronger authentication methods are enabled without disabling the weaker ones. A frequent case is enabling `publickey` on openSSH configuration and setting it as the default method but not disabling `password`. So by using the verbose mode of the SSH client an attacker can see that a weaker method is enabled:
```text
$ ssh -v 192.168.1.94
OpenSSH_8.1p1, OpenSSL 1.1.1d 10 Sep 2019
...
debug1: Authentications that can continue: publickey,password,keyboard-interactive
```
For example if an authentication failure limit is set and you never get the chance to reach the password method, you can use the `PreferredAuthentications` option to force to use this method.
* You can find interesting guides on how to harden SSH in [https://www.ssh-audit.com/hardening\_guides.html](https://www.ssh-audit.com/hardening_guides.html)
