Schlagwort-Archive: ssh

Vagrant issue Timed out while waiting for the machine to boot

Veröffentlicht am von
Antworten

vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'ubuntu/xenial64'...
==> default: Matching MAC address for NAT networking...
==> default: Checking if box 'ubuntu/xenial64' is up to date...
==> default: Setting the name of the VM: vagrant_default_1516452195026_53624
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
default: Adapter 1: nat
==> default: Forwarding ports...
default: 5000 (guest) => 5000 (host) (adapter 1)
default: 7474 (guest) => 7474 (host) (adapter 1)
default: 7687 (guest) => 7687 (host) (adapter 1)
default: 22 (guest) => 2222 (host) (adapter 1)
==> default: Running 'pre-boot' VM customizations...
==> default: Resized disk: old 10240 MB, req 51200 MB, new 51200 MB
==> default: You may need to resize the filesystem from within the guest.
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
default: SSH address: 127.0.0.1:2222
default: SSH username: vagrant
default: SSH auth method: private key
Timed out while waiting for the machine to boot. This means that
Vagrant was unable to communicate with the guest machine within
the configured ("config.vm.boot_timeout" value) time period.

If you look above, you should be able to see the error(s) that
Vagrant had when attempting to connect to the machine. These errors
are usually good hints as to what may be wrong.

If you're using a custom box, make sure that networking is properly
working and you're able to connect to the machine. It is a common
problem that networking isn't setup properly in these boxes.
Verify that authentication configurations are also setup properly,
as well.

If the box appears to be booting properly, you may want to increase
the timeout ("config.vm.boot_timeout") value.

Run
vagrant destroy

Upgrade Virtualbox and do the vagrant up again

Upload kippo ssh honeypot files to viper

Veröffentlicht am von
Antworten

You want to store all your samples catched by your SSH-Kippo Honeypot to your malware repository operated with viper?

Go that way:
Start Viper API:

foo@bar ~/scripts/viper $ ./api.py -H 0.0.0.0 -p 8080

and upload all your samples to viper:

for i in /home/pi/kippo-read-only/dl/*; do curl -F file=@$i -F tags="honeypot" http://covert:8080/file/add; done

Result:

{
    "message": "added"
}{
    "message": "added"
}

(you might want to modify the dir to your setup)
Why not automate uploading from kippo to viper?
– The „attacker“ might upload more then just malware / samples. You do not want to waste space in your malware zoo with another copy of netcat…

Aptana Eclipse SFTP remote arbeiten

Veröffentlicht am von
2

In einem älteren Artikel wurde beschrieben, wie Aptana, das frei Entwicklungswerkzeug auf Eclipse Basis genutzt werden kann, um remote auf einem FTP Server zu arbeiten.

Im täglichen Arbeitsablauf hat sich dieses Tool mittlerweile bewährt, doch Stillstand ist ja bekanntlich Rückschritt. Die konsequente Weiterentwicklung ist Verschlüsselung. Wie bekommt man diese Daten am einfachsten verschlüsselt. Die Lösung ist simpel: SFTP (SSH File Transfer Protocol).

Dieses wird mit SSH mitgeliefert und ist somit auf jedem Webserver mit SSH Zugang verfügbar. Da 99,9% aller Webserver, Rootserver und virtuellen Server über einen solchen Zugang verfügen ist die Verbreitung gewährleistet.

Technisch basiert es auf SCP, dem Secure Copy Protokol.

Um in Aptana SFTP nutzen zu können, muss ein Plugin installiert werden. Dieses ist über: http://aptana.com/plugins/ verfügbar, wird aktuell jedoch nicht unterstützt. Die Installation wird über Help -> Software Updates vorgenommen.

Danach ist SFTP als neue Möglichkeit im File Browser verfügbar. Dort kann dann eine neue Verbindung angelegt werden. Natürlich muss der SSH Nutzer Zugriff auf das public Verzeichnis des Webservers haben, diese Thematik muss aber gesondert bedacht werden.

SSH Key Linux OSX Problem

Veröffentlicht am von
Antworten

Mittels einer SSH Key authentication sichert man Verbindungen ab, bzw stellt sicher, dass die Person, die auf einen Server will, auch wirklich die Person ist, die sie vorgibt zu sein. DIeses Verfahren wird mit einem Schlüsselpaar sichergestellt, das aus einem public und einem private key besteht. Auf dem Server liegt dabei das public file, der Bneutzer muss das private file besitzen.

Solch ein Schlüsselpaar kann mittels putty generiert werden. Als Resultat erhällt man eine .ppk file und eine .pub file. Die .pub File, bzw dessen Inhalt kopiert man auf dem Server in die Datei

/home/user/.ssh/authorized_keys

Die ppk File speichert man an einem sicheren Ort. Möchte man nun mittels putty auf den Server zugreifen, kann man im ssh Menü einstellen, welchen key er dazu verwenden soll.

Kopiert man diesen ppk key jedoch auf ein unix system, und versucht dann auf den server mittels:

ssh -i /home/eigenerlocalerBenutzer/.ssh/private.ppk host.com -p 12345 -v

zuzugreifen, bekommt man die folgende Fehlermeldung:

debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>

Das Problem ist das ppk File, welches kein offenes Dateiformat ist. Um den private Key auch unter Linux zu nutzen, muss in puttygen der Schlüssel geöffnet werden und ein Export in das openssh Format vollzogen werden.

Verwendet man nun diesen openssh private Key, funktioniert es ohne Probleme.

Ein weiterer Stolperstein unter Unix Betriebssystemen sind die Zugriffsrechte. Ein server wird einen Key nicht akzeptieren, wenn auf dem Client die ssh Files von jedem änderbar sind. Dies äußert sich in der Fehlermeldung:

Permissions 0777 for ‚.ssh/key.priv‘ are too open.
It is recommended that your private key files are NOT accessible by others.
This private key will be ignored.
bad permissions: ignore key: .ssh/key.priv

Wobei 777 beispielhaft als negativstes Beispiel aufgeführt ist.

Korrekt müssen die Zugriffsrechte folgendermaßen gesetzt sein:

Der ssh Key und das Verzeichniss muss dem User gehören, der ihn benutzen soll.

chown username /Users/username/.ssh/*

chown username /Users/username/.ssh

Und die Rechte müssen gesetzt sein:

chmod 700 /Users/username/.ssh/

chmod 600 /Users/username/.ssh/*

Damit ist das Zugriffsproblem gelöst.

Um den Zugriff etwas einfacher zu gestaltetn, kann eine config File im ssh Ordner auf dem Client hinterlegt werden mit folgender beispielhafter Konfiguration:

Host host.de
IdentityFile ~/.ssh/key.priv
Port 12345
PreferredAuthentications publickey
Protocol 2

Host entspricht dem Host, auf den sich die Einstellungen beziehen. IndetityFile gibt den Ort des privaten Keys an. Port muss nur angegeben werden, wenn der SSH Server auf einen anderen Port eingestellt ist. PreferredAuthentications publickey stellt die Methode ein und Protocol stellt die verwendete SSH Version ein.

Svn über SSH Tunnel sichere Versionierung

Veröffentlicht am von
Antworten

 subclipse

Wer an einem etwas größeren Softwareprojekt arbeitet, an dem mehrere Entwickler beteiligt sind kommt an einer Versionierung nicht vorbei.

Besonders beliebt ist subversion (svn) welches mittels verschiedenen Freewaretools zugreifbar ist. Auch für die freie Entwicklungsplattform Eclipse gibt es Plugins wie z.b. subclipse.

Wenn das svn repository aufgesetzt wird sind folgende Schritte notwendig:

  1. SVN installieren(Debian Linux)
    apt-get install subversion
  2. Repository anlegen
    1. mkdir /srv/svn/ (Verzeichniss anlegen)
    2. svnadmin create /srv/svn/ (Subversion Infos hinterlegen etc.)
  3.  User anlegen
    1. adduser (siehe entsprechende Man Page)
    2. addgroup subgroup (Gruppe hinzufügen)
    3. chgrp subgroup o-rwx /srv/svn/ (Ordner der Gruppe zuordnen)
    4. chmod -R g+rw /srv/svn (Gruppe darf lesen schreiben)
    5. adduser neuerBenutzer subgrou (User der Gruppehinzufügen)
  4. Anlegen der Verzeichnisse im Verzeichniss:
    1. mkdir /srv/svn/test
  5. Starten des Servers
    1. srvserve -t (damit wird der svn über ssh getunnelt)
  6. Ab jetzt wird vom Client gearbeitet

    1. svn import Projekt svn+ssh://rechneradresse/srv/svn/test -m „Beschreibung der Änderungen“ (dadurch werden die ersten Files hinzugefügt.

    2. Nun kann im gewünschten Tool wie z.B. Subclipse die Adresse eingepflegt werden.