Schlagwort: ssh

SCP Funktioniert nicht auf aktuellem Debian 12

Auf einem aktuellen Debian funktioniert zwar der Zugriff per SSH und SSH-Keys, aber scp funktioniert nicht. Vor allem bei der Provisionierung mit Ansible tritt dieser Fehler auf.

Problem war eine Fehlerhafte Zuweisung des SFTP Subsystems in der Datei /etc/ssh/sshd_config

Dort musste die Direktive „Subsystem sftp internal-sftp-server“ abgeändert werden, und der letzte Part „-server“ entfernt werden.

Anbei das Kommando für die Änderung mit sed

sed -i 's/internal-sftp-server/internal-sftp/' /etc/ssh/sshd_config
systemctl restart ssh

SFTP-Server unter Linux konfigurieren

How To Configure SFTP for a Web Server Document Root


How do I force group and permissions for created files inside a specific directory?

find /var/www/html -type d -exec setfacl -m d:g::rwx {} +

Sorgt dafür, dass die Gruppe (bspw. www-data, also der Webserver Apache) zusätzlich zu den Lese- auch die Schreib- und Ausführungsrechte auf via SFTP angelegte Dateien erhält.


Weitere Infos:

https://de.wikipedia.org/wiki/Setuid

https://de.wikipedia.org/wiki/Setgid

RS-232 via SSH mit MikroTik

# settings for port "usb1"
/port set usb1 baud-rate=115200 data-bits=8 flow-control=none parity=none stop-bits=1

# disable system console for serial usb
# cave: "0" may be the integrated serial port
/system console disable 0

/user add name=rs232_ssh group=read password=my-secret-password

/special-login add port=usb1 user=rs232_ssh

Quelle

Eingesetzte Hardware:

  • MikroTik Router (z.B. mAP oder hEX S; beide können PoE-In und benötigen daher kein extra Netzteil)
  • USB auf RS-232

MikroTik: SSH Login ab Debian 9.0

UPDATE: Diese Information ist nur noch für ältere RouterOS Versionen vor 6.33 gültig, für neuere Versionen gibt es hier eine ordentliche Lösung.

Nachdem ich vor Kurzem meinen Backup-Server auf das aktuelle Debian 9.0 (stretch) aktualisiert habe, läuft mein Backup-Script für meine MikroTiks nicht mehr. Kein Ein Fall für eine akute Fehlersuche. Meine RouterOS-Config ist im Moment recht statisch, denoch wichtig genug um ein paar Minuten am Wochenende dafür zu opfern. Denn wie heißt es so schön im Buch „Zeitmanagement für Systemadministratoren“ — „Backups, Backups und Backups…“.
Das Backup läuft über SSH mit Key-Authentication mit einem eigenen Script:

#!/bin/bash
MT_HOSTS="mikrotik01.example.com mikrotik02.example.com"
MT_PORT=22
MT_USER=backup
MT_KEY="/root/.ssh/id_dsa"
MT_DIR="/backup/mikrotik"
MT_DATE=$(date +"%Y%m%d-%H%M")
for MT in ${MT_HOSTS}; do
[ ! -d ${MT_DIR}/${MT} ] && mkdir -p ${MT_DIR}/${MT}
ssh -p ${MT_PORT} -i ${MT_KEY} ${MT_USER}@${MT} "/export file=${MT}.rsc"
scp -P ${MT_PORT} -i ${MT_KEY} -B -q ${MT_USER}@${MT}:${MT}.rsc ${MT_DIR}/${MT}/${MT}_${MT_DATE}.rsc
done

Leider akzeptiert MikroTik bisher nur DSA und keine RSA-Keys. Hier liegt auch schon der Fehler: Debian stretch verwendet OpenSSH 7.4 und ab OpenSSH 7.0 wird der DSA-Algorithmus als „weak“ nicht mehr unterstützt. Solange MikroTik keinen RSA-Support implementiert, kann man den DSA-Algorithmus explizit wieder erlauben. Hierfür hab ich im Home-Directory meines Backup-Servers die Config-Datei (~/ssh/config) mit folgender Zeile ergänzt:

PubkeyAcceptedKeyTypes +ssh-dss

Ab dann funktioniert der SSH-Login per PublicKey (und damit mein Backup) wieder tadellos. Alternativ kann auch die Option nur bei dem BackupScript mitgegeben werden. Dafür müssen die SSH Aufrufe im Script mit folgender Option ergänzt werden:

ssh -oHostKeyAlgorithms=+ssh-dss

Quellen:
OpenSSH