Archiwum kategorii: ssh

OpwnWRT, ssh i logowanie bez kluczy

Mam dwa routery z zainstalowanym openwrt. Chciałem móc wykonywać jedno polecenie wydane z jednego routa na drugim bez podawania hasła.

1. Na źródłowym serwerze stworzyłem klucze i następnie przekonwertowałem aby dropbear mógł go używać:

ssh-keygen -t rsa
dropbearconvert openssh dropbear id_rsa /etc/dropbear/server1_identity

2. Na serwerze docelowym klucz publiczny dodaje do pliku authorized_keys:

root@Gargoyle:/etc/dropbear# ls -l /etc/dropbear/authorized_keys
-rw-------    1 root     root           394 Mar 27 20:30 /etc/dropbear/authorized_keys

I teraz mogę się logować bez podawania hasła!

root@router:~/.ssh# ssh -i /etc/private_rsa_key root@192.168.200.30


BusyBox v1.19.4 (2014-01-22 14:20:14 CET) built-in shell (ash)
Enter 'help' for a list of built-in commands.


             _____                             _
            |  __ \                           | |
            | |  \/ __ _ _ __ __ _  ___  _   _| | ___
            | | __ / _` | '__/ _` |/ _ \| | | | |/ _ \
            | |_\ \ (_| | | | (_| | (_) | |_| | |  __/
             \____/\__,_|_|  \__, |\___/ \__, |_|\___|
                              __/ |       __/ |
                             |___/       |___/

sftponly + chroot – wbudowane w sshd rozwiązanie

Zmieniamy sftp-server dostępny standardowo na wbudowany sftp:

#Subsystem sftp /usr/lib/openssh/sftp-server
Subsystem sftp internal-sftp -l VERBOSE

Następnie tworzymy grupę sftp, dodajemy do niej użytkowników i konfigurujemy zasady dla tych użytkowników:

Match group sftp
    X11Forwarding no
    ChrootDirectory %h
    AllowTcpForwarding no
    ForceCommand internal-sftp

Wady rozwiązania:
* nie działa scp
* nie działa rsync (możesz oczywiście zbudować w chroot środowisko dla rsync ale nie o to chodzi w łatwych rozwiązaniach…)

Plusy:
* wbudowane rozwiązanie

Używanie ssh na linuksie i historia co było robione

W windowsowym programie Putty jest ciekawa opcja pozwalająca zapisywać wszystko co robiliśmy w danej sesji. Ciekawiło mnie, czy jest to także możliwe w linuskie. I co? jest to banalne choć na początek upierdliwe ;). Ogólna idea jest bardzo prosta, należy przesłać strumień do kolejnego programu, którym będzie tee!:

ssh uzytkwonik@server | tee plik_logu.txt

Wypadałoby pliki historii tworzyć z uwzględnienem nazwy serwera i daty, więc prosi się o mały skrypt do tego. Ale to już zostawiam wam jako samodzielną pracę…

Linux – ssh – sprawdzanie poprawności kluczy w authorized_keys

Czasamy  kopiujemy klucze publiczne między serwerami, jak jednak sprawdzić czy klucze są poprawne?

[root@centos .ssh]# ssh-keygen -B -f authorized_keys
2048 xonip-tihir-cezol-bahuf-tanyh-lehum-vapon-hucet-telid-venyv-luxax authorized_keys
[root@centos .ssh]# ssh-keygen -B -f authorized_keys_fails
key_read: uudecode AAAAB3NzaC1yc2EAAAABIwAAAQEAonUZYUEc4bTAg6MQSuEgHNmWdKYsmk4krXO0eOL+lC+H4NcIetzY8zzuoGd0tgpQq/DnD3LkMdRmgez/pczsm9UnOsIcG+tQia/l22+aXcm5qUNEYLRka+kcoSjeHe5d6g5f8zoDvJ62x050+W77BkAUBJ3DoTLfDfN9nd+3a50axhWewh1aE19xen3uGlCCPLzRHwfzI3VWdcFUtbw0Fy/EDWhq5HOmm8McZKX2aisOtfMRgRc91sVxd3g/pdoOiw9l/ziZAS7+68dKnqHfx9om741Ua1NmX9XXhwBIFzlKwMTeHqOr15uM5HIfS/u+x+suG2+P+gKjwO+nuviyfQ= krzysztof.jozwiak@linuxexpert.pl
failed
authorized_keys_fails is not a public key file.