jaksi/sshesame

An easy to set up and use SSH honeypot, a fake SSH server that lets anyone in and logs their activity

sshesame's Issues

field debug not found in type main.loggingConfig

struct contains the debug field, but sshdsame.conf does not.

sshesame/config.go

Line 29 in ba0ef8e

type loggingConfig struct {

ERROR 2021/08/16 15:45:43 Failed to get config: yaml: unmarshal errors: line 9: field debug not found in type main.loggingConfig

Failed to get config: yaml

Could just be I maybe doing something wrong with specifying the .yaml file, however the following file path both absolute and relative file path return an error. I have not changed the example .yaml file in anyway just to make sure it worked or failed. Unfortunately I keep receiving the error :

“Failed to get config: yaml: line 13: did not find expected key”

what’s interesting is the pointer from the error doesn’t point to any lines having to do with the keys responsible for connection. Originally I had thought after looking at the config file that maybe it was talking about the sshesame program itself, so I downloaded a clone from github so I could read it not in binary like the already compiled go version but line 13 in the main.go also has nothing to do with any of the keys either. I even attempted to point to the directory where they were stored with the flag -data_dir and still got the same error. What could this mean?

listen_address it is not a valid snap option name

Using snap does not work well with listen_address since it is not a valid snap option name.
Please use an appropriate option name to feed the --listen_address argument.

Combine it with ChatGPT or similar

To generate realistic output for user's commands and see how far it will go.
For example, cat /etc/passwd should yield something realistically looking.

This could solve #119

Add support to seperate source IP and port

Are we able to add and option for separating the source IP and port in the json logs?

Example:
{"time":"2022-06-07T06:43:19Z","source":"10.10.10.10:45888","event_type":"connection_close","event":{}}
Becomes:
{"time":"2022-06-07T06:43:19Z","source":"10.10.10.10","source-port":"45888","event_type":"connection_close","event":{}}

Or something along those lines?

This will assist greatly with compatibility in other packages that just require just an IP.

option to let in clients before password authentication

Many clients don't offer password authentication:

ttime="2017-10-02T01:29:33-07:00" level=info msg="Client connected" client="8.8.8.8:55398"
time="2017-10-02T01:29:38-07:00" level=warning msg="Failed to establish SSH connection:ssh: disconnect, reason 11: "
time="2017-10-02T01:30:05-07:00" level=warning msg="Failed to establish SSH connection:read tcp 8.8.8.8:22->8.8.8.8:55063: read: connection reset by peer"
time="2017-10-02T01:30:40-07:00" level=info msg="Client connected" client="8.8.8.8:51635"
time="2017-10-02T01:30:54-07:00" level=warning msg="Failed to establish SSH connection:ssh: disconnect, reason 11: "
time="2017-10-02T01:31:13-07:00" level=info msg="Client connected" client="8.8.8.8:41782"
time="2017-10-02T01:31:18-07:00" level=warning msg="Failed to establish SSH connection:[no auth passed yet]"
time="2017-10-02T01:31:36-07:00" level=info msg="Client connected" client="8.8.8.8:52254"
time="2017-10-02T01:31:36-07:00" level=warning msg="Failed to establish SSH connection:ssh: no common algorithm for host key; client offered: [ssh-rsa ssh-dss], server offered: [ssh-ed25519]"
time="2017-10-02T01:32:37-07:00" level=info msg="Client connected" client="8.8.8.8:51105"
time="2017-10-02T01:32:39-07:00" level=warning msg="Failed to establish SSH connection:ssh: no common algorithm for host key; client offered: [ssh-rsa ssh-dss], server offered: [ssh-ed25519]"

Handle session channels

This is the channel type over which shells and command execution work.
For starters anything that kinda-sorta behaves like a shell will work (provide some basic prompt, respond to all commands with $COMMAND: command not found).
Eventually we should obviously have something more elaborate, based on what clients (attackers) try to do.
An overkill but maybe fun approach would be to create something like toybox or busybox, except everything being fake, and hook that up to session channels.

More installation methods

• Binary releases on GitHub
• More Docker architectures
• Snap

sshesame doesn't generate a host key

The host_key part is an opaque mystery, which is fine if sshsame can generate its own key file.

"illegal padding" error when trying to connect

I compiled sshesame (using go1.7.3), but each time I try to connect to it, I get an error on the server, disconnecting the ssh client (Ubuntu, OpenSSH 6.6.1p1):

2016/11/04 14:57:36 Listen: 127.0.0.1:2022
2016/11/04 14:58:19 Connection: client=127.0.0.1:56326
2016/11/04 14:58:23 Failed to establish SSH connection: ssh: illegal padding 77
2016/11/04 14:58:32 Connection: client=127.0.0.1:56328
2016/11/04 14:58:35 Failed to establish SSH connection: ssh: illegal padding 74

Restrict channel requests to channel types they are relevant for

Like, pty-req and shell requests should probably not be accepted on direct-tcpip channels.
We should first check how OpenSSH server reacts to such requests.

This is not directly useful to get more data from and information about clients (attackers), but it would get us a bit closer to how OpenSSH server behaves and might convince clients to engage.

Ability to log the IP address of a rejected connection?

I set up my sshesame server to only allow public key auth, and, of course, when hackers try to break into my system, these attempts are usually rejected (which I want). When a remote host is rejected by my sshesame server in this way, I get the following warning message:

WARNING 2023/08/11 14:15:46 Failed to accept connection: Failed to establish SSH server connection: ssh: disconnect, reason 11: Normal Shutdown, Thank you for playing

Is there any way to get the remote host's IP address to show up in this warning message?

Thank you very much in advance.

Feature request: make the software available as a snap

Hey

You may be interested in using snapcraft to build snaps and offer them for download to anyone on a number of distributions. For some marketing details see http://snapcraft.io. For a simple golang example look at https://github.com/snapcore/snapcraft/blob/master/demos/gopaste/snapcraft.yaml

Improve logging

• Debug and error logs are a bit inconsistent
• Activity logs IMHO ended up being overly verbose and difficult to understand. Maybe they are fine when using JSON logging, but not so much in plain text

Handle direct-tcpip channels

This is the channel which is requested when using ssh -L to request port forwarding.

ssh -f -N -L 8080:github.com:80 sshesame_host  # Sets up the SSH client to accept TCP connection on localhost:8080
curl 127.0.0.1:8080  # A connection made to localhost:8080 makes the SSH client request a direct-tcpip channel and forward traffic to github.com:80 from the server

We should obviously not do any actual network requests.
For starters, it would be fine to just assume everything is HTTP and return some basic hard-coded HTTP response.
Eventually we should have more protocols supported, see how clients (attackers) behave and improve each protocol handler.

Add support for email protocols over direct-tcpip

SMTP (25), POP3 (110), IMAP (143)

• SMTP
• POP3
• IMAP

release as snap packages?

I made the two files that transform this into a Snap package. You can take over releasing packages into the several distros that support Snap packages, do nothing, or give me permission to distribute packages with the name "sshesame". It's pretty easy to manage these yourself, and not rely on others to get sshesame into distros. I think you should do that. Maybe include these two files in your repo too.

http://bazaar.launchpad.net/~cmiller/+junk/sshesame-snap/files

http://snapcraft.io/

https://myapps.developer.ubuntu.com/

(The second file, implementing configuration of the port and listen address, won't be supported in released "snapcraft" until next week.)

I uploaded a candidate with my name in it. You can try on Ubuntu 16.04, for instance, with

sudo apt install snapd; sudo snap install sshesame-cmiller --candidate

and maybe

sudo snap set sshesame-cmiller port=2203 listen_address=42.42.42.42

Your packages won't have "-cmiller" on it.

You're awesome. Thanks for writing sshesame.

Unsupported global request type [email protected]

This is an OpenSSH-specific global request. It is supposed to prevent future session channels from being open.
From the OpenSSH protocol documentation:

On receipt of such a message, an OpenSSH server will refuse to open future channels of type "session" and instead immediately abort the connection.

This is not directly useful to get more data from and information about clients (attackers), but it would get us a bit closer to how OpenSSH server behaves and might convince clients to engage.

Regarding motivation, don't leave us hanging; what were those bots up to?

You never told us what the result was of letting them in? What did they try to do? We cannot recreate this ourselves.

Don't leave us hanging!

Add argument to override logging.file configuration

This is very useful when run sshesame with init.d (system v init) or systemd or rc.d - whatever.

So the idea is to run executables something like sshesame -logging null to redirect output to stdout, so for example systemd could write logs to /var/log/blah.log with root owner while the app itself runs under nobody or any non-privileged user

Feature request: add support for logging to a database

It would be nice to log events such as log ins, and payloads, to a database, for analysis.

For example,

Table logins:
Source address, source port, time, username, password

Table payloads:
Source address, source port, time, payload

listen address: 0.0.0.0:2022 doesn't listen on tcp4, only tpc6

Not sure what has changed but by default my sshesame instance is only listening on ipv6 despite being configured with a listen address of 0.0.0.0:2022:

# using listen_address: 127.0.0.1:2022
Sep 24 23:42:53 my-hostname sshesame[1950846]: INFO 2023/09/24 23:42:53 Listening on 127.0.0.1:2022
Sep 24 23:43:26 my-hostname systemd[1]: Stopping sshesame.service - sshesame...
Sep 24 23:43:26 my-hostname systemd[1]: sshesame.service: Deactivated successfully.
Sep 24 23:43:26 my-hostname systemd[1]: Stopped sshesame.service - sshesame.
Sep 24 23:43:26 my-hostname systemd[1]: Started sshesame.service - sshesame.
Sep 24 23:43:26 my-hostname sshesame[1951085]: INFO 2023/09/24 23:43:26 No host keys configured, using keys at "/home/USER/.local/share/sshesame"


# using listen_address: 0.0.0.0:2022
Sep 24 23:43:26 my-hostname sshesame[1951085]: INFO 2023/09/24 23:43:26 Listening on [::]:2022

go version
go version go1.20.7 linux/amd64

[email protected]/

Crypto error when installing

I'm getting this. Can't find much on the googs about it.

% go get -u github.com/jaksi/sshesame
# golang.org/x/crypto/ed25519
src/golang.org/x/crypto/ed25519/ed25519.go:54: undefined: crypto.SignerOpts

Support TLS-encrypted protocols over direct-tcpip

For HTTPS and eventually SMTP, POP3 and IMAP over TLS (#64).
We'll obviously have to use some invalid self-signed cert but maybe attackers won't notice? 👀 One way to find out.

Failed to read host key

Hi - installed go and got the sshesame from github but I get a "failed to read host key" error when I run sshesame

Create custom commands that the attacker can use?

Are we able to create custom commands that the attacker can use?
For example uname -r should return a random set bogus value so the bots that attack feel like they have achived something and the attacker actually might go on the system to try and do something

Lacks documenation and configuration ability

Documentation does not explicitly state where logs are kept or written
No option in the configuration file to change the log location
No option to for logtypes as if i just want plain lined text and find JSON unneeded
Documentation is also very vague on setting the configuration file change the listen_address. I had to rummage through the program and systemctl to determine that I need to add listen_address to the configuration file for it to allow remote hosts.

not connecting

Every time I enter a username and password nothing happens and it gets stuck.
SSH Client:
login as: cfp cfp@localhost's password:(me entering some random bullshit here)

SSH Fakeserver:
2021/06/30 16:27:00 No host keys configured, using keys at C:\Users\chaos\AppData\Local/sshesame 2021/06/30 16:27:00 Listening on 127.0.0.1:2022 time="2021-06-30T16:27:09+02:00" level=info msg="Connection accepted" remote_address="127.0.0.1:2035" time="2021-06-30T16:27:10+02:00" level=info msg="Client attempted to authenticate" client_version=SSH-2.0-PuTTY_Release_0.73 method=none remote_address="127.0.0.1:2035" session_id=BgDT5oUqAqtuMuc6B/YGnjIQ9JRXGEEG/2GkI5sSV8g success=false user=cfp time="2021-06-30T16:27:12+02:00" level=info msg="Password authentication attempted" client_version=SSH-2.0-PuTTY_Release_0.73 password=cfp remote_address="127.0.0.1:2035" session_id=BgDT5oUqAqtuMuc6B/YGnjIQ9JRXGEEG/2GkI5sSV8g success=true user=cfp time="2021-06-30T16:27:12+02:00" level=info msg="Client attempted to authenticate" client_version=SSH-2.0-PuTTY_Release_0.73 method=password remote_address="127.0.0.1:2035" session_id=BgDT5oUqAqtuMuc6B/YGnjIQ9JRXGEEG/2GkI5sSV8g success=true user=cfp time="2021-06-30T16:27:12+02:00" level=info msg="SSH connection established" client_version=SSH-2.0-PuTTY_Release_0.73 remote_address="127.0.0.1:2035" session_id=BgDT5oUqAqtuMuc6B/YGnjIQ9JRXGEEG/2GkI5sSV8g user=cfp time="2021-06-30T16:27:12+02:00" level=info msg="New channel accepted" channel_id=1 channel_type=session client_version=SSH-2.0-PuTTY_Release_0.73 remote_address="127.0.0.1:2035" session_id=BgDT5oUqAqtuMuc6B/YGnjIQ9JRXGEEG/2GkI5sSV8g user=cfp time="2021-06-30T16:27:12+02:00" level=info msg="Channel request accepted" channel_id=1 channel_type=session client_version=SSH-2.0-PuTTY_Release_0.73 remote_address="127.0.0.1:2035" request_payload="Term: xterm, Size: 80x24 (0x0 px), Modes: VERASE=127, OPCODE_42=1, TTY_OP_ISPEED=38400, TTY_OP_OSPEED=38400" request_type=pty-req request_want_reply=true session_id=BgDT5oUqAqtuMuc6B/YGnjIQ9JRXGEEG/2GkI5sSV8g user=cfp time="2021-06-30T16:27:12+02:00" level=info msg="Channel request accepted" channel_id=1 channel_type=session client_version=SSH-2.0-PuTTY_Release_0.73 remote_address="127.0.0.1:2035" request_payload= request_type=shell request_want_reply=true session_id=BgDT5oUqAqtuMuc6B/YGnjIQ9JRXGEEG/2GkI5sSV8g user=cfp

Can someone help me this is confusing and there is so much log output

Somehow test and compare the behavior between sshesame and OpenSSH server

Questions:

• What version and configuration of OpenSSH?
• What scenarios (channels, requests, data)?

Idea: Create a basic SSH client in Go which records and dumps server behavior (requests, channels, data, ordering), run it against OpenSSH and sshesame, compare the two results.

Pressing Ctrl-D to terminate a command terminates the whole session

E.g. running cat and trying to terminate it by pressing Ctrl-D terminates the whole session.

Seems like the terminal we're using handles Ctrl-D (ASCII EOT) in a way that prevents further input processing. We might have to use another terminal implementation or roll our own.

Limit size of log file or rotate

Thank you for maitaing this project, I'm a very happy user.

Recently my VPS ran out of disk space, the culprit was a very large, 160GB sshesame log file.

While I am sure it wouldn't be hard to set up a limit outside of sshesame, perhaps by creating a separate partition, or by setting up a service to periodically delete the file, it would be nice if a log file size limit could be specified directly in sshesame.yaml. Alternatively, some documentation pointing to the recommended way of setting this up externally would be very useful.

unmarshal error for field Language of type disconnectMsg"

time="2017-10-02T00:44:46-07:00" level=warning msg="Failed to establish SSH connection:ssh: unmarshal error for field Language of type disconnectMsg"