Tag: ssh

perl: warning setting locale failed unter debian

nach dem letzten update meines arbeitsplatz rechners mit linux mint, bekomme ich bei ssh verbindungen zu diversen servern bei perl basierten anwendungen meist sowas:

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = (unset),
LC_MEASUREMENT = "de_DE.UTF-8",
LC_PAPER = "de_DE.UTF-8",
LC_MONETARY = "de_DE.UTF-8",
LC_NAME = "de_DE.UTF-8",
LC_ADDRESS = "de_DE.UTF-8",
LC_NUMERIC = "de_DE.UTF-8",
LC_TELEPHONE = "de_DE.UTF-8",
LC_IDENTIFICATION = "de_DE.UTF-8",
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("en_US.UTF-8").
locale: Cannot set LC_ALL to default locale: No such file or directory
/usr/bin/locale: Cannot set LC_ALL to default locale: No such file or directory

da das problem nur bei ssh verbindungen auftritt, sollte beim ssh client die option SendEnv LANG LC_* in der datei /etc/ssh/ssh_config deaktiviert (auskommentiert) werden

“haengende” ssh session abschiessen

immer wieder kommts mal vor, dass eine ssh session “haengt”, weil z.b. gerade die internetverbindung abgekackt ist oder sowas. um die zu beenden, muss man “enter”, gefolgt von “~.” (tilde+punkt) druecken. die tilde ist der escape character und der punkt steht fuer disconnect.

hier noch ein paar andere von diesen sehr nuetzlichen kombinationen:

  • ~.: Disconnect.
  • ~^Z: Background ssh.
  • ~#: List forwarded connections.
  • ~&: Background ssh at logout when waiting for forwarded connection / X11 sessions to terminate.
  • ~?: Display a list of escape characters.
  • ~B: Send a BREAK to the remote system (only useful for SSH protocol version 2 and if the peer supports it).
  • ~C: Open command line. Currently this allows the addition of port forwardings using the -L, -R and -D options (see above). It also allows the cancellation of existing remote port-forwardings using -KR[bind_address:]port. !command allows the user to execute a local command if the PermitLocalCommand option is enabled in ssh_config(5). Basic help is available, using the -h option.
  • ~R: Request rekeying of the connection (only useful for SSH protocol version 2 and if the peer supports it).

ssh: no kex alg

es kommt doch vor, dass man steinalte linux installation hueten muss.. 😉
wenn der ssh client zu alt ist fuer die ssh server, stolpert man ueber diese meldung:

no kex alg

dann muss man am ende der datei /etc/ssh/sshd_config diese zeile einfuegen und den sshd neu starten:

KexAlgorithms diffie-hellman-group1-sha1,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1

das sind alte ciphers, die irgendwann mal standardmaessig bei opsenssh rausgeschmissen wurden und als “potentially-incompatible changes” deklariert sind.

supermicro ipmi board mit ssh tunneln

wenn man mal auf ein IPMI board zugreifen muss und der server nicht direkt, sondern nur ueber einen “hop-server” per ssh erreichbar ist…

ssh root@hophost -L 443:10.11.12.13:443 -L 5900:10.11.12.13:5900 -L 5901:10.11.12.13:5901 -L 5120:10.11.12.13:5120 -L 5123:10.11.12.13:5123 -L 5988:10.11.12.13:5988

in diesem falle handelt es sich um ein AMI-basierten IPMI chip auf einem supermicro board. wenn man noch mehr braucht, wie z.b. das lokale cd-rom durchgeschleift, dann brauchts noch mehr ports. da das remote console gedoense mit java funktioniert, muss man dann noch localhost in den java security einstellungen in die ausnahmeliste hinzufuegen.

ssh-copy-id mit anderem port

normalerweise nutzt man den befehl ssh-copy-id so:

ssh-copy-id -i path/my_id_rsa.pub user@host.tld 

wenn der zielserver allerdings einen vom standard (22) abweichenden port nutzt, dann kann es mit aelteren versionen des ssh-copy-id befehls probleme mit dem “-p” parameter geben. dann ist dieser mit dem hostnamen in hochkommata zu setzen:

ssh-copy-id -i path/my_id_rsa.pub "user@host.tld -p 19022"