RSSEinträge zu Tag: ssh
-bash: /dev/null: Permission denied beim SSH-Login
Erstellt: 14.04.2011 15:48
Die Fehlermeldung "-bash: /dev/null: Permission denied" beim Login per SSH oder ähnliche Meldungen können entstehen, wenn die Dateirechte von /dev/null nichtmehr korrekt sind.
Kontrolliert man /dev/null zeigt sich folgendes Bild:
# ls -lh /dev/null
crw------- 1 root adm 1, 3 Mär 30 16:48 /dev/null
Korrekt wäre:
# ls -lh /dev/null
crw-rw-rw- 1 root root 1, 3 Mär 30 16:48 /dev/null
Wie kann das passieren?
Die sind die Standardrechte wie sie syslog-ng anlegt für Logfiles. syslog-ng gibt allen Logfiles die voreingestellten Rechte, so auch dem Verzeichnis /dev/null, wenn man direkt darauf verweist.
destination d_drop { file("/dev/null"); };
Dies umgeht man, indem man Nachrichten welche man verwerfen will ohne definierte Destination angibt:
destination d_drop { };
/dev/null repariert man am einfachsten wieder indem man es löscht und korrekt wieder anlegt:
# rm /dev/null
# mknod -m 0666 /dev/null c 1 3
Und schon ist wie Welt wieder in Ordnung:
# ls -lh /dev/null
crw-rw-rw- 1 root root 1, 3 Mär 30 16:52 /dev/null
ssh_config und sshd_config in cygwin finden
Erstellt: 22.11.2010 09:56
Die Config-Dateien von SSH (und anderen Programmen) sind unter cygwin ein wenig versteckt.Sie liegen nicht in /etc/ssh, sondern in /cygdrive/c/cygwin/etc/defaults/etc/.
Also /etc/ssh/ssh_config wird zu:
/cygdrive/c/cygwin/etc/defaults/etc/ssh_config
...und /etc/ssh/sshd_config zu:
/cygdrive/c/cygwin/etc/defaults/etc/sshd_config
...zumindest bei der Standardinstallation.
MySQLDump über SSH
Erstellt: 13.10.2010 18:14
Auch "mysqldump" lässt sich wie so vieles recht einfach über SSH übertragen:
# mysqldump -uUser -pPassword --opt --lock-tables=false -A | ssh root@192.168.0.123 "cat > /path/to/dump.sql"
root@192.168.0.123's password: Password [Enter]
...und einen Kaffee holen! :D
Festplatten-Images mit dd und ssh über das Netzwerk
Erstellt: 06.05.2010 16:12
Ein Image von einer Festplatte anfertigen, dies macht wohl jeder hin und wieder. Ein prominentes Werkzeug dazu ist ganz klar dd. Netterweise funktioniert das Ganze auch direkt über ssh, so vermeidet man ein Zwischenspeichern des Images:
# dd if=/dev/quelle | ssh user@host dd of=/pfad/ans/ziel.img
SSH-Login sehr langsam
Erstellt: 23.10.2009 11:04
Beim Versuch sich auf dem System einzuloggen verstreichen etwa 10 (oder mehr gefühlte ;) ) Sekunden bis es weitergeht mit der Passwortabfrage.
Das liegt daran, dass der SSH-Server versucht einen Reverse-DNS-Lookup für die IP zu machen von welcher die SSH-Verbindung aufgebaut wird.
Funktioniert dies nicht gibt es einen Timeout für diese Aktion. Dies kann daran liegen dass in der Datei /etc/resolv.conf eine falsche oder keine IP-Adresse für einen funktionierenden DNS-Server eingetragen ist.
Startet man ssh im "verbose mode" also "ssh -v domain.tld" zeigt sich folgendes Fehlerbild:
OpenSSH_5.1p1 Debian-6, OpenSSL 0.9.8k 25 Mar 2009
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to domain.tld [ip-adresse] port 22.
debug1: Connection established.
debug1: identity file /home/[username]//.ssh/identity type -1
debug1: identity file /home/[username]//.ssh/id_rsa type -1
debug1: identity file /home/[username]//.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-5
debug1: match: OpenSSH_5.1p1 Debian-5 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.1p1 Debian-6
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'domain.tld' is known and matches the RSA host key.
debug1: Found key in /home/[username]//.ssh/known_hosts:4
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
Hier sind die 10 Sekunden wartezeit.
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/[username]/.ssh/identity
debug1: Trying private key: /home/[username]/.ssh/id_rsa
debug1: Trying private key: /home/[username]//.ssh/id_dsa
debug1: Next authentication method: password
Pause bis zur Passworteingabe.
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = de_CH.UTF-8
Last login: Thu Oct 22 18:35:04 2009 from 72-225*
Trägt man nun seinen funktionierenden Nameserver in die /etc/resolv.conf ein sollte das Problem behoben sein:
nameserver ip.meines.name.servers
Wünsche ein schönes Wochenende ;)