Items tagged with: SSH

"A PI-powered #Plan9 cluster, an #SSH tarpit, rdist for when Ansible is too much, falling in love with #OpenBSD again, how I created my first #FreeBSD port, the Tilde Institute of OpenBSD education and more."
The SSH Tarpit | BSD Now 294
If you have an IoT device in your home, you could be receiving an average of 13 login attempts to these devices per minute.That’s what I found in my latest research project.Over the past 3 months,I’ve setup and monitored 10 honeypots located across 5 different continents.These have been waiting patiently for SSH login attempts to better understand how often you face cybercriminals knocking at your network’s metaphorical front door.
The Problem with #SSH Agent Forwarding https://defn.io/2019/04/12/ssh-forwarding/ #security #bsd #unix

The problem with ssh agent forwarding

After hacking the matrix.org website today, the attacker opened a series of GitHub issues mentioning the flaws he discovered. In one of those issues, he mentions that “complete compromise could have been avoided if developers were prohibited from using [SSH agent forwarding]“.
#ssh #security #root #server #configuration #matrix #hack

S9 Antminer's root password "admin" - change immediately!!!

I now own a #S9 #Antminer from #Bitmain for some weeks (already). It runs really loud and I turn it only on when I'm out of house or want to have it running. It has a nice web interface and even #SSH with root (some #Linux embeded system). I setup quickly everthing and mining #Peercoins is working as expected (I run it in eco-mode). But what I later found out is that the SSH root password is simply "admin" which is a well-known password.

So here is my advice: If you intend to buy and run it (locally or on public Internet) please *do change* your SSH password! If you fail to do so, somebody might be able to change your pool login data and then he is receiving the coins you want to mine on your electricity bill! And I'm sure that he will then change root password to his own so you have to (somehow?) flush the memory to have factory-default settings (including password, I hope) back.

Here are some pictures of my miner, including screenshots which is just below my computer table (and it can be very noisy): #Nextcloud
Basic #tmux #Tutorial - Windows, Panes, and Sessions over #SSH #linux #terminal [partagé via #DiasporaForAndroid]

Using a Yubikey as smartcard for SSH public key authentication

Contributed by Paul 'WEiRD' de Weerd on 2019-03-21 from the shire lease dept. Ken Westerback (krw@) writes in with his report from a2k19, the hackathon in New Zealand: Due to an earlier (pre-737Max)…
Article word count: 128

HN Discussion: https://news.ycombinator.com/item?id=19566126
Posted by sverige (karma: 4874)
Post stats: Points: 117 - Comments: 39 - 2019-04-03T18:56:11Z

#HackerNews #authentication #for #key #public #smartcard #ssh #using #yubikey
Article content:

Contributed by [1]Paul ʼWEiRDʼ de Weerd on 2019-03-21 from the shire lease dept.

Ken Westerback (krw@) writes in with his report from [2]a2k19, the hackathon in New Zealand:
Due to an earlier (pre-737Max) airplane problem on the flight back from n2k18 in Usti nad Labem, a loosely worded compensation coupon and the cooperation of beck@ in exploiting said wording, I was able to fly Business Class over the Pacific and thus arrived well rested in BNE. Could have been even more rested if I hadnʼt had to rouse myself to raise a(nother) glass of champagne as we crossed the date line and it became someoneʼs birthday. First world problems.

 The alert reader will have noted that BNE is not where a2k19 was. But beck@ and I had decided to personally drag various Australians onto the flight to Wellington the next day.

[3]Read more…

Contributed by [4]Peter N. M. Hansteen on 2019-03-10 from the table of the man dept.

Ingo Schwarze wrote in with the announcement of a new [5]mandoc release. Ingo writes,
I just released mandoc-1.14.5. This is a regular maintenance release. As structural changes are quite limited, i expect it to be very stable, so all downstream systems are encouraged to upgrade from any earlier version.

[6]Read more…

Contributed by [7]rueda on 2019-03-06 from the do devices hotplug counterclockwise down under dept.

We are delighted to have received an [8]a2k19 hackathon report: Antoine Jacoutot (ajacoutot@) writes:
Better (very) late than never… hereʼs my small report about my [9]a2k19 hackathon slacking time in Wellington (NZ).

 The "Antipodean" hackathon they call it. Indeed, it took me 28h to get there from Paris via Singapore! Fortunately, I met with phessler@ and cheloha@ right on arrival at the airport. From there we went directly into town to visit the different bars with mlarkin@ as our guide :-).
 The challenge was to find a way to keep us awake (12h of jet lag for me), and going around 6 different bars did the trick :-)

[10]Read more…

Contributed by Sebastian Benoit (benno@) on 2019-02-26 from the token dept.

SSH is an awesome tool. Logging into other machines securely is so pervasive to us sysadmins nowadays that few of us think about whatʼs going on underneath. Even more so once you start using the more advanced features such as the [11]ssh-agent, [12]agent-forwarding and [13]ProxyJump. When doing so, care must be taken in order to not compromise oneʼs logins or ssh keys.

[14]Read more…

4 comments (27d18:05 ago)

Contributed by [15]Paul ʼWEiRDʼ de Weerd on 2019-02-27 from the time flies dept.

Itʼs that time of year again; Theo (deraadt@) has [16]just tagged [17]6.5-beta. A good reminder for us all run an extra test install and see if your favorite port still works as you expect.

CVSROOT: /cvs Module name: src Changes by: deraadt@cvs.openbsd.org 2019/02/26 15:24:41 Modified files: etc/root : root.mail share/mk : sys.mk sys/conf : newvers.sh sys/sys : ktrace.h param.h usr.bin/signify: signify.1 sys/arch/macppc/stand/tbxidata: bsd.tbxi Log message: crank to 6.5-beta

Contributed by [18]rueda on 2019-02-23 from the Virtually Problematic Njetworks dept.

Landry Breuil (landry@) has [19]committed a work-in-progress FAQ section "[20]Virtual Private Networks (VPN)":

CVSROOT: /cvs Module name: www Changes by: landry@cvs.openbsd.org 2019/02/22 15:07:05 Modified files: faq : index.html Added files: faq : faq17.html Log message: Add a (wip!) VPN FAQ, because ʼHow do i VPN with OpenBSD?ʼ seems to be a frequently asked question, and IPSec is hard. Now is the time to polish it in-tree. With feedback from solene@, tj@, tb@ & sthen@, thanks! ok tb@ tj@

Contributed by [21]rueda on 2019-02-23 from the all your returns are belong to us dept.

Todd Mortimer (mortimer@) has [22]committed improvements to (the anti-[23]ROP) [24]"X86FixupGadgets" pass of [25]clang(1) for amd64 and i386:

CVSROOT: /cvs Module name: src Changes by: mortimer@cvs.openbsd.org 2019/02/22 08:28:43 Modified files: gnu/llvm/lib/Target/X86: X86FixupGadgets.cpp X86InstrCompiler.td X86MCInstLower.cpp gnu/llvm/tools/clang/include/clang/Driver: Options.td gnu/llvm/tools/clang/lib/Driver/ToolChains: Clang.cpp share/man/man1 : clang-local.1 Log message: Improve the X86FixupGadgets pass: - Target all four kinds of return bytes (c2, c3, ca, cb) - Fix up instructions using both ModR/M and SIB bytes - Force alignment before instructions with return bytes in immediates - Force alignment before instructions that have return bytes in their encoding - Add a command line switch to toggle the functionality. ok deraadt@

This extends the [26]previous work to cover even more cases which (previously potentially) could be exploited as return instructions.

Contributed by [27]Peter N. M. Hansteen on 2019-02-19 from the ffwd all the vlans dept.

Hrvoje Popovski wrote in to alert us that Martin Pieuchot (mpi@) has written a new blog post entitled [28]Faster vlan(4) forwarding?, which leads in with
Two years ago we [29]observed that [30]vlan(4) performances suffered from the locks added to the [31]queueing API. At that time, the use of [32]SRP was also pointed out as a possible responsible for the regression. Since dlg@ [33]recently [34]reworked if_enqueue() to allow pseudo-drivers to bypass the use of queues, and their associated locks, letʼs dive into [35]vlan(4) performances again.

Read the whole thing here: [36]Faster vlan(4) forwarding?

Contributed by [37]rueda on 2019-02-11 from the diving-into-base dept.

[38]openrsync, a clean-room implementation of [39]rsync, is being developed by [40]Kristaps Dzonsons as part of [41]the rpki-client(1) project [featured in an [42]earlier article]. openrsync(1) has been [43]imported into the tree (as "rsync") by Sebastian Benoit (benno@):

CVSROOT: /cvs Module name: src Changes by: benno@cvs.openbsd.org 2019/02/10 16:18:28 Added files: usr.bin/rsync : Makefile TODO.md blocks.c child.c client.c downloader.c extern.h fargs.c flist.c hash.c io.c log.c main.c md4.c md4.h mkpath.c receiver.c rsync.1 rsync.5 rsyncd.5 sender.c server.c session.c socket.c symlinks.c uploader.c Log message: Import Kristapsʼ openrsync into the tree. OK deraadt@

The "Security" section on the [44]GitHub site contains a description of openrsyncʼs use of OpenBSDʼs security features.

At the time of writing, rsync is not yet linked to the build.


Visible links
1. https://undeadly.org/
2. https://www.openbsd.org/hackathons.html#a2k19
3. http://www.undeadly.org/cgi?action=article;sid=20190324141227
4. http://bsdly.blogspot.com/
5. http://man.openbsd.org/mandoc
6. http://www.undeadly.org/cgi?action=article;sid=20190310175719
7. https://www.openbsdfoundation.org/donations.html
8. https://www.openbsd.org/hackathons.html#a2k19
9. https://www.openbsd.org/hackathons.html#a2k19
10. http://www.undeadly.org/cgi?action=article;sid=20190309000023
11. https://man.openbsd.org/ssh-agent
12. https://man.openbsd.org/ssh#A
13. https://man.openbsd.org/ssh_config#ProxyJump
14. http://www.undeadly.org/cgi?action=article;sid=20190302235509
15. https://undeadly.org/
16. https://marc.info/?l=openbsd-cvs&m=155124147409929&w=2
17. http://www.openbsd.org/65.html
18. https://www.openbsdfoundation.org/donations.html
19. https://marc.info/?l=openbsd-cvs&m=155087324104898&w=2
20. https://www.openbsd.org/faq/faq17.html
21. https://www.openbsdfoundation.org/donations.html
22. https://marc.info/?l=openbsd-cvs&m=155084933828723&w=2
23. https://en.wikipedia.org/wiki/Return-oriented_programming
24. https://man.openbsd.org/clang-local
25. https://man.openbsd.org/clang
26. https://undeadly.org/cgi?action=article;sid=20180606064444
27. http://bsdly.blogspot.com/
28. http://www.grenadille.net/post/2019/02/18/Faster-vlan%284%29-forwarding
29. http://www.undeadly.org/post/2017/02/13/What-happened-to-my-vlan
30. http://man.openbsd.org/OpenBSD-current/man4/vlan.4
31. http://man.openbsd.org/OpenBSD-current/man9/ifq_enqueue.9
32. http://man.openbsd.org/OpenBSD-current/man9/srp_enter.9
33. https://marc.info/?l=openbsd-cvs&m=154699647614720&w=2
34. https://marc.info/?l=openbsd-cvs&m=154699664314769&w=2
35. http://man.openbsd.org/OpenBSD-current/man4/vlan.4
36. http://www.grenadille.net/post/2019/02/18/Faster-vlan%284%29-forwarding
37. https://www.openbsdfoundation.org/donations.html
38. https://github.com/kristapsdz/openrsync
39. https://rsync.samba.org/
40. https://github.com/kristapsdz
41. https://medium.com/@jobsnijders/a-proposal-for-a-new-rpki-validator-openbsd-rpki-client-1-15b74e7a3f65
42. http://www.undeadly.org/cgi?action=article;sid=20181130162059
43. https://marc.info/?l=openbsd-cvs&m=154984072229951&w=2
44. https://github.com/kristapsdz/openrsync

HackerNewsBot debug: Calculated post rank: 91 - Loop: 164 - Rank min: 80 - Author rank: 34
Ab sofort gibt es offizielle eine Raspberry-Pi-Maus und ein Pi-Keyboard. Sie sind in den üblichen Farben rot und weiß gehalten. Sowohl bei Tastatur als auch Maus gibt aber eine farbliche Variation (schwarz / grau). Die Tastatur an sich sieht recht schnuckelig aus, ist aber wohl nichts für große Hände. Offizielle Tastatur Das offizielle Raspberry Pi Keyboard ist deswegen interessant, weil sie gleichzeitig […]
Offizielle Maus und Tastatur für Raspberry Pi vorgestellt - auch Deutsch
#Maus #osbn #RaspberryPi #ssh #Tastatur #USB-Hub #
"This program opens a socket and pretends to be an #SSH server. However, it actually just ties up SSH clients with false promises indefinitely"

Endlessh: An SSH Tarpit

March 22, 2019 nullprogram.com/blog/2019/03/22/ I’m a big fan of tarpits: a network service that intentionally inserts delays in its protocol, slowing down clients by forcing them to wait. This…
Article word count: 9

HN Discussion: https://news.ycombinator.com/item?id=19465967
Posted by stargrave (karma: 1913)
Post stats: Points: 202 - Comments: 61 - 2019-03-22T19:22:13Z

#HackerNews #endlessh #ssh #tarpit
Article content:

March 22, 2019


I’m a big fan of tarpits: a network service that intentionally inserts delays in its protocol, slowing down clients by forcing them to wait. This arrests the speed at which a bad actor can attack or probe the host system, and it ties up some of the attacker’s resources that might otherwise be spent attacking another host. When done well, a tarpit imposes more cost on the attacker than the defender.

The Internet is a very hostile place, and anyone who’s ever stood up an Internet-facing IPv4 host has witnessed the immediate and continuous attacks against their server. I’ve maintained [1]such a server for nearly six years now, and more than 99% of my incoming traffic has ill intent. One part of my defenses has been tarpits in various forms. The latest addition is an SSH tarpit I wrote a couple of months ago:

[2]Endlessh: an SSH tarpit

This program opens a socket and pretends to be an SSH server. However, it actually just ties up SSH clients with false promises indefinitely — or at least until the client eventually gives up. After cloning the repository, here’s how you can try it out for yourself (default port 2222):

$ make
$ ./endlessh &
$ ssh -p2222 localhost

Your SSH client will hang there and wait for at least several days before finally giving up. Like a mammoth in the La Brea Tar Pits, it got itself stuck and can’t get itself out. As I write, my Internet-facing SSH tarpit currently has 27 clients trapped in it. A few of these have been connected for weeks. In one particular spike it had 1,378 clients trapped at once, lasting about 20 hours.

My Internet-facing Endlessh server listens on port 22, which is the standard SSH port. I long ago moved my real SSH server off to another port where it sees a whole lot less SSH traffic — essentially none. This makes the logs a whole lot more manageable. And (hopefully) Endlessh convinces attackers not to look around for an SSH server on another port.

How does it work? Endlessh exploits [3]a little paragraph in RFC 4253, the SSH protocol specification. Immediately after the TCP connection is established, and before negotiating the cryptography, both ends send an identification string:

SSH-protoversion-softwareversion SP comments CR LF

The RFC also notes:
The server MAY send other lines of data before sending the version string.

There is no limit on the number of lines, just that these lines must not begin with “SSH-“ since that would be ambiguous with the identification string, and lines must not be longer than 255 characters including CRLF. So Endlessh sends and endless stream of randomly-generated “other lines of data” without ever intending to send a version string. By default it waits 10 seconds between each line. This slows down the protocol, but prevents it from actually timing out.

This means Endlessh need not know anything about cryptography or the vast majority of the SSH protocol. It’s dead simple.

Implementation strategies

Ideally the tarpit’s resource footprint should be as small as possible. It’s just a security tool, and the server does have an actual purpose that doesn’t include being a tarpit. It should tie up the attacker’s resources, not the server’s, and should generally be unnoticeable. (Take note all those who write the awful “security” products I have to tolerate at my day job.)

Even when many clients have been trapped, Endlessh spends more than 99.999% of its time waiting around, doing nothing. It wouldn’t even be accurate to call it I/O-bound. If anything, it’s timer-bound, waiting around before sending off the next line of data. The most precious resource to conserve is memory.

The most straightforward way to implement something like Endlessh is a fork server: accept a connection, fork, and the child simply alternates between sleep(3) and write(2):

for (;;) { ssize_t r; char line[256]; sleep(DELAY); generate_line(line); r = write(fd, line, strlen(line)); if (r == -1 && errno != EINTR) { exit(0); }

A process per connection is a lot of overhead when connections are expected to be up hours or even weeks at a time. An attacker who knows about this could exhaust the server’s resources with little effort by opening up lots of connections.

A better option is, instead of processes, to create a thread per connection. On Linux [4]this is practically the same thing, but it’s still better. However, you still have to allocate a stack for the thread and the kernel will have to spend some resources managing the thread.

For Endlessh I went for an even more lightweight version: a single-threaded poll(2) server, analogous to stackless green threads. The overhead per connection is about as low as it gets.

Clients that are being delayed are not registered in poll(2). Their only overhead is the socket object in the kernel, and another 78 bytes to track them in Endlessh. Most of those bytes are used only for accurate logging. Only those clients that are overdue for a new line are registered for poll(2).

When clients are waiting, but no clients are overdue, poll(2) is essentially used in place of sleep(3). Though since it still needs to manage the accept server socket, it (almost) never actually waits on nothing.

There’s an option to limit the total number of client connections so that it doesn’t get out of hand. In this case it will stop polling the accept socket until a client disconnects. I probably shouldn’t have bothered with this option and instead relied on ulimit, a feature already provided by the operating system.

I could have used epoll (Linux) or kqueue (BSD), which would be much more efficient than poll(2). The problem with poll(2) is that it’s constantly registering and unregistering Endlessh on each of the overdue sockets each time around the main loop. This is by far the most CPU-intensive part of Endlessh, and it’s all inflicted on the kernel. Most of the time, even with thousands of clients trapped in the tarpit, only a small number of them at polled at once, so I opted for better portability instead.

One consequence of not polling connections that are waiting is that disconnections aren’t noticed in a timely fashion. This makes the logs less accurate than I like, but otherwise it’s pretty harmless. Unforunately even if I wanted to fix this, the poll(2) interface isn’t quite equipped for it anyway.
Raw sockets

With a poll(2) server, the biggest overhead remaining is in the kernel, where it allocates send and receive buffers for each client and manages the proper TCP state. The next step to reducing this overhead is Endlessh opening a raw socket and speaking TCP itself, bypassing most of the operating system’s TCP/IP stack.

Much of the TCP connection state doesn’t matter to Endlessh and doesn’t need to be tracked. For example, it doesn’t care about any data sent by the client, so no receive buffer is needed, and any data that arrives could be dropped on the floor.

Even more, raw sockets would allow for some even nastier tarpit tricks. Despite the long delays between data lines, the kernel itself responds very quickly on the TCP layer and below. ACKs are sent back quickly and so on. An astute attacker could detect that the delay is artificial, imposed above the TCP layer by an application.

If Endlessh worked at the TCP layer, it could [5]tarpit the TCP protocol itself. It could introduce artificial “noise” to the connection that requires packet retransmissions, delay ACKs, etc. It would look a lot more like network problems than a tarpit.

I haven’t taken Endlessh this far, nor do I plan to do so. At the moment attackers either have a hard timeout, so this wouldn’t matter, or they’re pretty dumb and Endlessh already works well enough.

asyncio and other tarpits

Since writing Endless [6]I’ve learned about Python’s asycio, and it’s actually a near perfect fit for this problem. I should have just used it in the first place. The hard part is already implemented within asyncio, and the problem isn’t CPU-bound, so being written in Python [7]doesn’t matter.

Here’s a simplified (no logging, no configuration, etc.) version of Endlessh implemented in about 20 lines of Python 3.7:

import asyncio
import random async def handler(_reader, writer): try: while True: await asyncio.sleep(10) writer.write(bʼ%x\r\nʼ % random.randint(0, 2**32)) await writer.drain() except ConnectionResetError: pass async def main(): server = await asyncio.start_server(handler, ʼ0.0.0.0ʼ, 2222) async with server: await server.serve_forever() asyncio.run(main())

Since Python coroutines are stackless, the per-connection memory overhead is comparable to the C version. So it seems asycio is perfectly suited for writing tarpits! Here’s an HTTP tarpit to trip up attackers trying to exploit HTTP servers. It slowly sends a random, endless HTTP header:

import asyncio
import random async def handler(_reader, writer): writer.write(bʼHTTP/1.1 200 OK\r\nʼ) try: while True: await asyncio.sleep(5) header = random.randint(0, 232) value = random.randint(0, 232) writer.write(bʼX-%x: %x\r\nʼ % (header, value)) await writer.drain() except ConnectionResetError: pass async def main(): server = await asyncio.start_server(handler, ʼ0.0.0.0ʼ, 8080) async with server: await server.serve_forever() asyncio.run(main())

Try it out for yourself. Firefox and Chrome will spin on that server for hours before giving up. I have yet to see curl actually timeout on its own in the default settings (--max-time/-m does work correctly, though).

Parting exercise for the reader: Using the examples above as a starting point, implement an SMTP tarpit using asyncio. Bonus points for using TLS connections and testing it against real spammers.

« [8]An Async / Await Library for Emacs Lisp


Visible links
1. https://nullprogram.com/blog/2017/06/15/
2. https://github.com/skeeto/endlessh
3. https://tools.ietf.org/html/rfc4253#section-4.2
4. https://nullprogram.com/blog/2015/05/15/
5. https://nyman.re/super-simple-ssh-tarpit/
6. https://nullprogram.com/blog/2019/03/10/
7. https://nullprogram.com/blog/2019/02/24/
8. https://nullprogram.com/blog/2019/03/10/

HackerNewsBot debug: Calculated post rank: 155 - Loop: 134 - Rank min: 100 - Author rank: 113
Cómo configurar claves #SSH
Cómo configurar claves SSH
You're probably right that #xclip doesn't work for remote #ssh connections. I've used ssh but never came across this idea. It would be very cool if there was this functionality built into ssh! What about #ansible; have you used it for running #remote commands on machines. I did a 20 minute tutorial on it about 6 months ago and it was easy to get some remote commands to run. Like intstead of sshing into a machine and running a command you set up a #playbook to run that command and then no need for ssh
SSH-Software: Kritische Sicherheitslücken in Putty #Putty #Datensicherheit #EU #SSH #Sicherheitslücke #Server #Applikationen #Internet #Security
"A kernel of failure, IPv6 fragmentation vulnerability in #OpenBSD ’s pf, a guide to the terminal, using a #Yubikey for #SSH public key authentication, #FreeBSD desktop series, and more."
Microkernel Failure | BSD Now 289
#Security : #KaliLinux Forensics Tools, #SSH Primer and “Yelp, but for MAGA” Mad About Holes

Wipe and reinstall a running Linux system via SSH, without rebooting (2017)

Wipe and reinstall a running Linux system via SSH, without rebooting. You know you want to. - marcan/takeover.sh
Article word count: 34

HN Discussion: https://news.ycombinator.com/item?id=19357153
Posted by 1nvalid (karma: 483)
Post stats: Points: 146 - Comments: 25 - 2019-03-11T06:50:04Z

#HackerNews #2017 #and #linux #rebooting #reinstall #running #ssh #system #via #wipe #without
Article content:


You can’t perform that action at this time.

You signed in with another tab or window. [1]Reload to refresh your session. You signed out in another tab or window. [2]Reload to refresh your session.


Visible links
1. file:///dev/
2. file:///dev/

HackerNewsBot debug: Calculated post rank: 105 - Loop: 129 - Rank min: 100 - Author rank: 150

Fedora SSH Too many authentication failures

#ssh #fedora too many authentication failures #config #Links
https://got-tty.org/fedora-ssh-too-many-authentication-failures #ssh
Fedora SSH Too many authentication failures
SSHd and AuthorizedKeysCommand https://jpmens.net/2019/03/02/sshd-and-authorizedkeyscommand/ #ssh #openssh
In bed, too early to sleep so decide to watch a film. Too lazy to go fetch my laptop.

So I use #ConnectBot to open an #SSH session on the laptop and run #kdeconnect's kdeconnect-cli -d xxxxx --share file:///path/to/that/film.mp4

And watch the film on #VLC on me phone.

If I hadn't been on the same #LAN I would have copied the file into my #Nextcloud directory and synchronised from there.

All the apps mentioned available on @fdroidorg.
#RDP Servers Can Hack Client Devices: Researchers
https://techbizweb.com/rdp-servers-can-hack-client-devices-researchers/ use #ssh instead. #security
RDP Servers Can Hack Client Devices: Researchers
English version below.

Sorry, #Google und #Cloudflare, Eure #Abuse-Formulare und -Bedingungen machen keinen Spaß.
Also sperre ich jetzt Eure User-Clouds aus. Zwei Tage lang mehrere tausend SSH brute-force Versuche von Euren Systemen aus sind genug.

Das haben sogar die Chinesen zu Hochzeiten selten geschafft.
Sorry #Google and #Cloudflare, your #Abuse forms are full of unacceptable and complicated processes and requirements.
Thus I'll lock out your user-#cloud systems. Two days with a couple of thousand #SSH brute-force connections from your sytems are more than enough.
One should think infrastructure providers that big do have at least some kind of abuse monitoring...

Even the chinese didn't do that bad in their worst times.

I do not apologize for any inconvenience and if anybody has a problem now, reach out to me directly, but not from Google or Cloudflare.

In #Germany we have such bad mobile internet connections, you can't even work on a server with #SSH, we are literally the use case for #mosh and #screen on #Linux.
Вот это весьма интересно. Один (одна, если быть точнее) активных коммитеров FreeBSD написала статью про разработанный ею фреймворк по защищённому хранилищу с многофакторной (до 5FA !) авторизацией доступа и как она до такой жизни дошла.

Multi-Factor (4FA and 5FA) Authentication with FreeBSD and SSH | Devin Teske
I was asked on twitter today to explain some recent work I have done in the multi-factor authentication department. I can write this article because I have recently released my work under the title “secure_thumb.” While many 2FA and beyond methodologies implement SMS as a factor in authentication, I was uncomfortable sending factors over the wi...
#FreeBSD #ssh #cryptography #security
OpenSSH & Putty: Sicherheitlücke in SCP ermöglicht Dateiaustausch #SSH #F-Secure #Fernwartung #OpenSSH #Putty #Sicherheitslücke #Server #Applikationen #Security
Imagine some people being gullible enough to run #ssh (with private keys and all) under #malware #vista10 that comes with #nsa back doors, #listeningDevices and file #surveillance

SSH Examples, Tips and Tunnels

Bounce through the network with SSH tunnels and proxies. Take your remote system administration skills to the next level with our practical SSH examples.
Article word count: 3606

HN Discussion: https://news.ycombinator.com/item?id=18775604
Posted by thewanderer1999 (karma: 246)
Post stats: Points: 116 - Comments: 24 - 2018-12-28T08:44:44Z

\#HackerNews #and #examples #ssh #tips #tunnels
Article content:


[1]SSH examples, tips and tunnelsPractical [2]SSH examples to take your remote system admin game to the next level. Commands and tips to not only use SSH but master ways to move around the network.

Knowing a few ssh tricks will benefit any system administrator, network engineer or security professional.

First The Basics
Breaking down the SSH Command Line
The following ssh example command uses common parameters often seen when connecting to a remote SSH server.

localhost:~$ ssh -v -p 22 -C neo@remoteserver

-v : Print debug information, particularly helpful when debugging an authentication problem. Can be used multiple times to print additional information.
-p 22 : Specify which port to connect to on the remote SSH server. 22 is not required as this is the default, but if any other port is listening connect to it using the -p parameter. The listening port is configured in the sshd_config file using the Port 2222 format.
-C : Compression is enabled on the connection using this parameter. If you are using the terminal over a slow link or viewing lots of text this can speed up the connection as it will compress the data transferred on the fly.
neo@ : The string before the @ symbol denotes the username to authenticate with against the remote server. Leaving out the user@ will default to using the username of the account you are currently logged in to (~$ whoami). User can also be specified with the -l parameter.
remoteserver : The hostname that the ssh is connecting to, this can be a fully qualified domain name, an IP address or any host in your local machines hosts file. To connect to a host that resolves to both IPv4 and IPv6 you can specify add a parameter -4 or -6 to the command line so it resolves correctly.

Each of the above a parameters are optional apart from the remoteserver.
Using a Configuration File
While many users are familiar with the sshd_config file, there is also a client configuration file for the ssh command. This defaults to ~/.ssh/config but can also be specified as a parameter with the -F option.

Host * Port 2222 Host remoteserver HostName remoteserver.thematrix.io User neo Port 2112 IdentityFile /home/test/.ssh/remoteserver.pub

In the above example ssh configuration file you can see that there are two Host entries. The first is a wildcard denoting all hosts have the Port 2222 configuration option applied. The second says for a hostname of remoteserver as seen on the ssh command line - use a different username, port, FQDN and IdentityFile.

The configuration file can save a lot of typing by including advanced configuration shortcuts any time a connection is made to particular hosts.
Copy Files over SSH with SCP
The ssh client comes with two other very handy tools for moving files around over an encrypted ssh connection. The commands are scp and sftp, see the examples below for basic usage. Note that many parameters for the ssh can be applied to these commands also.

localhost:~$ scp mypic.png neo@remoteserver:/media/data/mypic_2.png

In this example the file mypic.png was copied to the remoteserver to file system location /media/data and was renamed to mypic_2.png.

Donʼt forget the difference in the port parameter. This is a gotcha that hits everyone using scp on the command line. The port parameter is -P not -p as it is in the ssh client.!. You will forget, but donʼt worry everyone does.

For those familiar with command line ftp, many of the commands are similar when using sftp. You can push, put and ls to your hearts desire.

sftp neo@remoteserver

Practical Examples

In many of these examples we could achieve the result using a number of methods. As in all our [3]tutorials and example command sheets, the focus is practical examples that simply get the job done.
  • Proxy Traffic over SSH using SOCKS
    The SSH Proxy feature has been placed at number 1 for good reason. It is more powerful than many users realise giving you access to any system that the remote server can reach, using almost any application. The ssh client can tunnel traffic over the connection using a SOCKS proxy server with a quick one liner. A key thing to understand is that traffic to the remote systems will have a source of the remote server. For example in a web server log file.

    localhost:~$ ssh -D 8888 user@remoteserver localhost:~$ netstat -pan | grep 8888 tcp 0 0* LISTEN 23880/ssh

    Here we start the socks proxy server running on TCP port 8888, the second command checks that the port is now listening. The indicates the service is running on localhost only. We can use a slightly different command to listen on all interfaces including ethernet or wifi, this will allow other applications (browsers or other) on our network to connect to the ssh socks proxy service.

    localhost:~$ ssh -D user@remoteserver

    Now we can configure our browser to connect to the socks proxy. In Firefox select preferences | general | network settings. Add the IP address and the port for the browser to connect to.

    [4]SSH Socks Proxy with DNS

    Note the option at the bottom of the form to force browser DNS requests to also go over the socks proxy. If you are using the proxy to encrypt your web traffic on the local network you will definitely want to select this option so the DNS requests are also tunnelled over the SSH connection.

    Enable Socks Proxy on Chrome

    Using a command line parameter when launching Chrome will use the socks proxy and also tunnel DNS requests from the browser over the socks5 proxy. Trust but verify, use [5]tcpdump (tcpdump not port 22) to confirm the DNS requests are no longer visible.

    localhost:~$ google-chrome --proxy-server="socks5://"

    Using other applications with the Proxy

    Keep in mind that there are many other applications that can utilise a socks proxy. A web browser is simply the most popular. Some applications will have configuration options for use of the proxy. Others may need some help by using a helper program that talks the socks protocol. An example of this is [6]proxychains. Using this tool we can for example use Microsoft RDP over the socks proxy.

    localhost:~$ proxychains rdesktop $RemoteWindowsServer

    The configuration options for the socks proxy are set in the proxychains configuration file.

    Hot Tip: Using remote desktop from Linux to Windows? Try the [7]FreeRDP client. A more modern implementation than rdesktop with much smoother interaction.

    Use Case for the SSH Socks Proxy

    You are in a cafe or hotel having to use the somewhat sketchy WIFI. From our Laptop we run the ssh proxy locally and establish an ssh tunnel into our home network using a our local Rasberry Pi. Using the browser or other applications configured for the SOCKS proxy we can access any network services on our home network or browse to the Internet via our Home Network Connection. Everything between our Laptop and the Home Server (across the WIFI and Internet to home) is encrypted in the SSH tunnel.
  • SSH Tunnel (port forward)
    In its simplest form an SSH tunnel simply opens a port on your local system that connects through to another port at the other end of the tunnel.

    localhost:~$ ssh -L 9999: user@remoteserver

    Lets break down the -L parameter. Think of -L as the Local listening side. So in our example above the port 9999 is listening on localhost and port forwards through to port 80 on remoteserver, note that the refers to localhost on the remote server!

    Lets take it up a notch. In this following example the port that is listening can be connected to from other hosts on the local network.

    localhost:~$ ssh -L user@remoteserver

    In these examples the port we are connecting is a listening web server. It could also be a proxy server or any other TCP service.
  • SSH Tunnel Forward to Secondary Remote host
    We can use the same options seen above to have the tunnel connect to another service running on a secondary system from the remote server.

    localhost:~$ ssh -L user@remoteserver

    In this example we are forwarding the tunnel from remoteserver to the web server running on The traffic from remoteserver -> is no longer within the ssh tunnel. The web server on will see remoteserver as the source of the web requests.
  • SSH Reverse Tunnel
    In this scenario we want to setup a listening port on the remote server that will connect back to a local port on our localhost (or other system).

    localhost:~$ ssh -v -R user@remoteserver

    With this ssh session established a connection to the remoteserver port 1999 will be forwarded to port 902 on our local client.
  • SSH Reverse Proxy
    In this case we are establishing a SOCKS proxy with our ssh connection, however the proxy is listening at the remote server end. With connections to that remote socks proxy now emerging from the tunnel as traffic originating from our localhost.

    localhost:~$ ssh -v -R user@remoteserver

    Troubleshooting Remote SSH Tunnels

    If you are having trouble getting the remote SSH options to work, check with netstat which interface the listening port is attached too. Even though we have specified in the above examples, if GatewayPorts is set to no in the sshd_config then the listener will only bind to localhost (

    Security Warning
    Note that when you are opening tunnels and socks proxies you may be exposing internal network resources to untrusted networks (like the Internet!). This can be a serious security risk so ensure you understand what is listening and what it has access too.
  • Establish a VPN over SSH
    A common term amongst offensive security folks (pentesters / red teams / etc), is to pivot into a network. Once you have a connection established on one system that system becomes a gateway point for further access to the network. This is known as pivoting and enables lateral movement through the network.

    We can use the SSH proxy for this and proxychains, however there are some limitations. For example we cannot use raw sockets, so [8]Nmap SYN scans cannot be used to port scan the Internal network.

    Using this more advanced VPN option we move the connectivity down to layer 3. We can then simply route traffic through the tunnel using standard network routing.

    This technique uses ssh, iptables, tun interfaces and routing.

    First we need these options set in the sshd_config. Since we are making interface changes on the remote system and the client system, we will need root privileges on both sides.

    PermitRootLogin yes PermitTunnel yes

    Then we will establish our ssh connection using the parameter that requests tun devices be initialised.

    localhost:~# ssh -v -w any root@remoteserver

    Now you should have a tun device when you show interfaces (# ip a). Next step is to add IP addresses to the tunnel interfaces.

    SSH Client Side:

    localhost:~# ip addr add peer dev tun0 localhost:~# ip tun0 up

    SSH Server Side:

    remoteserver:~# ip addr add peer dev tun0 remoteserver:~# ip tun0 up

    Now we should have a direct route to the other host (route -n and ping

    It is now possible to route any subnet through the other side host.

    localhost:~# route add -net netmask dev tun0

    On the remote side we need to enable ip_forward and iptables.

    remoteserver:~# echo 1 > /proc/sys/net/ipv4/ip_forward remoteserver:~# iptables -t nat -A POSTROUTING -s -o enp7s0 -j MASQUERADE

    Boom! Layer three VPN through an SSH tunnel. Now thatʼs winning.

    Any trouble, try [9]tcpdump and ping to see where its broken. Since we are playing at layer 3 our icmp packets should be jumping through that tunnel.
  • Copy your SSH key (ssh-copy-id)
    There are multiple ways to achieve this however this command is a shortcut that saves time. What does it actually do? Well this command simply replicates what you can also do manually. Copying the ~/.ssh/id_rsa.pub (or the default) key from your system and adds it to an ~/.ssh/authorized_keys file on the remote server.

    localhost:~$ ssh-copy-id user@remoteserver
  • Run Command Remotely (non-interactive)
    The ssh command can be chained to other commands for the usual piping fun. Simply add the command you want to run on the remote host as a final parameter in quotes.

    localhost:~$ ssh remoteserver "cat /var/log/nginx/access.log" | grep badstuff.php

    In this example the grep is being performed on the local system after the log file has been pushed across the ssh session. If the file is large it would be more efficient to run the grep on the remote side simply by enclosing the pipe and grep in the double quotes.

    Another example performs the same function as the ssh-copy-id short cut in Tip 7.

    localhost:~$ cat ~/.ssh/id_rsa.pub | ssh remoteserver ʼcat >> .ssh/authorized_keysʼ
  • Remote Packet Capture & View in Wireshark
    I grabbed this one from our [10]tcpdump examples. Use it for a remote packet capture with the results feeding directly into your local Wireshark GUI.

    :~$ ssh root@remoteserver ʼtcpdump -c 1000 -nn -w - not port 22ʼ | wireshark -k -i -
  • SSH Copy Folder from Local to Remote
    A neat trick that compresses a folder using bzip2 (thatʼs the -j in the tar command), then extracts the bzip2 stream on the other side creating a duplicate of the folder on the remote server.

    localhost:~$ tar -cvj /datafolder | ssh remoteserver "tar -xj -C /datafolder"
  • Remote GUI Applications with SSH x11 Forwarding
    If the client and remote server both have X installed. It is possible to run a GUI command remotely, with the Window appearing on your local desktop. This feature has been around since the beginning of time, but can still be very useful. Run a remote web browser or even the VMWawre Workstation console as I do in this example.

    localhost:~$ ssh -X remoteserver vmware

    Requires X11Forwarding yes in the sshd_config.
  • Copy files remotely with rsync and SSH
    Using the rsync has many advantages over scp, if periodically need to backup a directory, large numbers of files or very large files it should be used. It has the ability to recover from failed transfers and only copy differences between two locations saving bandwidth and time.

    The example here uses gzip compression (-z) and archive mode (-a) that includes recursive copy.

    :~$ rsync -az /home/testuser/data remoteserver:backup/
  • SSH over Tor Network
    The anonymised Tor Network can tunnel SSH traffic by using the torsocks command. The following command will proxy the ssh connection through the Tor network.

    localhost:~$ torsocks ssh myuntracableuser@remoteserver

    [11]Torsocks will use the localhost port 9050 to proxy traffic. As always when using tor serious consideration must be taken to understand what traffic is being tunnelled and other operational security (opsec) concerns. Where are your DNS requests going?
  • SSH to EC2 instance
    When using SSH to connect to your EC2 instance within Amazon you will need to use a certificate. Download the certificate from your Amazon EC2 control panel and change the permissions (chmod 600 my-ec2-ssh-key.pem. Keep this key somewhere safe or put it in your ~/.ssh/ folder.

    localhost:~$ ssh -i ~/.ssh/my-ec2-key.pem ubuntu@my-ec2-public

    The -i parameter simply tells the ssh client to use this key. This would be an ideal example of where to use the ~/.ssh/config to configure the use of the key automatically when connecting to the ec2 host.

    Host my-ec2-public Hostname ec2???.compute-1.amazonaws.com User ubuntu IdentityFile ~/.ssh/my-ec2-key.pem
  • Edit text files with VIM over ssh/scp
    For all those vim users out there, this one can save some time. Using vim we can edit files over scp with one command. Using this method simply creates a file in /tmp on the local system and then copies it back once we write the file in vim.

    localhost:~$ vim scp://user@remoteserver//etc/hosts

    Note the format is slightly different to regular scp. After the host we have a double //. This references the absolute path. A single slash will have a path that is relative to the users home directory.

    warning (netrw) cannot determine method (format: protocol://[user@]hostname[:port]/[path])

    If you see this error, double check the format of your command. It usually means there is a syntax error.
  • Mount remote SSH location as local folder with SSHFS
    Using sshfs - an ssh filesystem client, we can mount a local directory to a remote location with all file interaction taking place over the encrypted ssh session.

    localhost:~$ apt install sshfs

    On Ubuntu and Debian based system we install the sshfs package and then simply mount the remote location.

    localhost:~$ sshfs user@remoteserver:/media/data ~/data/
  • SSH Multiplex using ControlPath
    By default when you have an existing connection to a remote server with ssh, a second connection using ssh or scp will establish a new session with the overhead of authentication. Using the ControlPath options we can have the existing session be used for all subsequent connections. This will speed things up significantly. It is noticeable even on a local network but even more so when connecting to remote resources.

    Host remoteserver HostName remoteserver.example.org ControlMaster auto ControlPath ~/.ssh/control/%r@%h:%p ControlPersist 10m

    ControlPath denotes a socket that is checked by new connections to see if there is an existing ssh session that can be used. The ControlPersist option above means even after you exit the terminal, the existing session will remain open for 10 minutes, so if you were to reconnect within that time you would use that existing socket. See the ssh_config man page for more information.
  • Stream Video over SSH using VLC + SFTP
    Long time users of ssh and vlc (Video Lan Client) are not always of aware of this handy option for when you simply need to watch video over the network. Using the vlc option to File | Open Network Stream one can simply enter the location as a an sftp:// location. A prompt will appear for authentication details if password is required.

  • Two Factor Authentication
    Most readers will understand the value in using Two Factor Authentication, the same benefits that apply to your banking or Google Account can be applied to your SSH service.

    Of course ssh comes with a form of Two Factor capability included, that being a passphrase and an SSH key. An advantage of using a hardware based token or the [12]Google Authenticator App is the fact that they are generally coming from a second physical device.

    See our 8 minute guide to getting started with [13]Google Authenticator and SSH.
  • Bouncing through jump hosts with ssh and -J
    When network segmentation means you are jumping through multiple ssh hosts to get to a final destination network or host, this jump host shortcut might be just what you need.

    localhost:~$ ssh -J host1,host2,host3 user@host4.internal

    A key thing to understand here is that this is not the same as ssh host1 then user@host1:~$ ssh host2, the -J jump parameter uses forwarding trickery so that the localhost is establishing the session with the next host in the chain. So our localhost is authenticating with host4 in the above example; meaning our localhost keys are used and the session from localhost to host4 is encrypted end to end.

    To use this ability in the ssh_config use the ProxyJump configuration option. If you regularly have to jump through multiple hosts; use the config file and your alias to host4 will save you a lot of time.
  • Block SSH Brute Force Attempts with iptables
    Anyone who has managed an SSH service on the Internet, and viewed the logs will be aware of the amount of SSH brute force attempts that take place every hour of every day. An immediate way to reduce the noise in your logs is to move SSH to a port other than 22. Make the change in the sshd_config file using the Port ## configuration option.

    Using iptables we can also simply block attempts to connect to the port from sources that reach a certain threshold. A simple way to do this is to use [14]OSSEC, as this not only blocks SSH but will also perform a bunch of other host based intrusion detection functions (HIDS).
  • Modify Port Forwarding within a session with ~C
    And our final ssh example is for modifying port forwarding on the fly within an existing ssh session. Picture this example scenario. You are deep in a network; perhaps you have jumped through half a dozen jump hosts and need a local port on your workstation forwarded to Microsoft SMB on the old Windows 2003 system you spotted (ms08-67 anyone?).

    After hitting enter try typing ~C in your terminal. This a control escape sequence within the session that allows to make changes to the existing connection.

    localhost:~$ ~C ssh> -h Commands: -L[bind_address:]port:host:hostport Request local forward -R[bind_address:]port:host:hostport Request remote forward -D[bind_address:]port Request dynamic forward -KL[bind_address:]port Cancel local forward -KR[bind_address:]port Cancel remote forward -KD[bind_address:]port Cancel dynamic forward ssh> -L 1445:remote-win2k3:445 Forwarding port.

    You can see here we have forwarded our local port 1445 to the Windows 2003 host we found on the internal network. Now simply launch msfconsole and we are good to go (assuming you were planning on exploiting that host).
Wrapping Up

These ssh examples, tips and commands are intended to give you a starting point; additional detail on each of the commands and capabilities is available using the man pages (man ssh, man ssh_config, man sshd_config).

Being able to reach out and run commands on systems anywhere in the world has always fascinated me. By developing your skills with tools such as ssh you will become more productive and effective at whatever game you play.

Thanks for reading and if you have any comments or suggestions please drop me a note using the contact form. Have fun!


Visible links
2. https://en.wikipedia.org/wiki/Secure_Shell
3. https://hackertarget.com/research/#tutorial
5. https://hackertarget.com/tcpdump-examples/
6. https://github.com/haad/proxychains
7. https://github.com/FreeRDP/FreeRDP
8. https://hackertarget.com/nmap-online-port-scanner/
9. https://hackertarget.com/tcpdump-examples/
10. https://hackertarget.com/tcpdump-examples/
11. https://github.com/dgoulet/torsocks
12. https://hackertarget.com/ssh-two-factor-google-authenticator/
13. https://hackertarget.com/ssh-two-factor-google-authenticator/
14. https://hackertarget.com/enable-ossec-active-response/

HackerNewsBot debug: Calculated post rank: 85 - Loop: 86 - Rank min: 80 - Author rank: 410
Oh! A new record. 338 IPs blacklisted by fail2ban.


!Friendica Admins #fail2ban #ssh
Halle (Saale) 

Wizards can do it. Gods can do it. 😎🆒

And you can do it now, too, with free and open source software.

Control servers remotely. 🖥👩‍💻🕸🐧

#SSH -> https://en.wikipedia.org/wiki/Secure_Shell

#floss #foss #gnu #linux #thanks #magic #control #monitoring #software #administration

Linux Kernel Updaten und alten Kernel sicher löschen

Als erstes sollte man überprüfen ob es eine neue #Kernelversion für eure #Linux Maschine gibt.
Wenn es einen neuen #Kernel gibt und wen man diese direkt installieren möchte kann man das folgende Kommandoabfolge benutzen und es in der #Shell oder über #SSH als #root durchlaufen lassen.
Anschließend muss man, wenn man gefragt wird, alle Fragen mit „J“ also einem Ja beantworten.
sudo apt-get update && sudo apt-get upgrade && sudo apt-get dist-upgrade && sudo apt-get update && sudo apt-get autoremove && sudo apt-get autoclean
Jetzt muss man den #Rechner oder #Server mit einem
neu starten. Beim Hochfahren zieht sich der Rechner/Server die neuste Kernel Version und man kann anschließend den alten Kernel mit folgender Befehlsabfolge löschen. Natürlich erst wenn man festgestellt hat das alles ordnungsgemäß läuft.
sudo dpkg -l ‚linux-[ihs]*‘ | sed ‚/^ii/!d;/'“$(uname -r | sed „s/\([-0-9]*\)-\([^0-9]\+\)/\1/“)“‚/d;s/^[^ ]* [^ ]* \([^ ]*\).*/\1/;/[0-9]/!d‘ | tee zu_entfernende_Kernel && cat zu_entfernende_Kernel | xargs sudo apt-get -y purge && rm zu_entfernende_Kernel
#Update #Ubuntu
@thomas Completely agreed, even when the more common reason to change the port is, that your logs contain less failed attempts.

But there are also solutions.

1. Use banlists like https://github.com/virus2500/blocklist-with-ipset

2. Use geoip based bans https://www.axllent.org/docs/view/ssh-geoip/

3. Use port-knocking http://portknocking.org/

4. Restrict ssh port access to your well-known IP ranges https://www.cyberciti.biz/tips/linux-iptables-how-to-specify-a-range-of-ip-addresses-or-ports.html

#linux #servers #SSH
Later posts Earlier posts