Archiwum kategorii: Zdalny dostęp

Linux i konsole szeregowe

Jakie konsole jakie szeregowe ma system?

Teoretycznie wszystkie pliki /dev/ttyS* są konsolami, jednak nie wszystkie są prawdziwe, cześć z nich po prostu rezerwują miejsce.

Prawdziwe możemy znaleźć przeszukując dmesg (ale pamiętać należy ze ten bufor jest cały czas nadpisywany więc może kłamać)

[root@server1 ~]# dmesg | grep tty
[    0.000000] console [tty0] enabled
[    0.842783] 00:05: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
[    0.863343] 00:06: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 16550A

Czy port szeregowy pracuje naprawdę, możemy użyć programu setserial:

[root@server1 ~]# setserial -g /dev/ttyS[0123]
/dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4
/dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3
/dev/ttyS2, UART: unknown, Port: 0x03e8, IRQ: 4
/dev/ttyS3, UART: unknown, Port: 0x02e8, IRQ: 3

Programy do pracy z konsolami szeregowymi to np. minicom.

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.


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

ser2net: czyli jak połączyć się telnetem na port szeregowy

Ostatnio spotkałem się z dość prostym problemem: otóż mam kilka urządzeń, do których mam dostęp także przez konsole szeregowe. Zwyczajowo do konsol szeregowych łączyłem się przez program minicom ale w takim przypadku, gdy chce kolegom umożliwić zdalny dostęp do maszyn oznacza to iż musze utworzyć lokalne konta na serwerze. Najlepiej byłoby tego unikąć. Moim rozwiązaniem okazało się udostępnienie portu szeregowego przez port TCP przypomocy ser2net.

Czytaj dalej ser2net: czyli jak połączyć się telnetem na port szeregowy

OpenVPN + VPS: problem z urządzeniem /dev/net/tun

W przypadku VPS (Virtual Private Server) często się zdarza, że OpenVPN nie startuje, jako że nie jest włąćzony dostęp do urządzenia /dev/net/tun. Objaw jest następujący:

[root@vz13505 openvpn]# cat /dev/net/tun
cat: /dev/net/tun: Operation not permitted

W przypadku prawidłowego dostępu komunikat jest następujący:

[root@vz13505 log]# cat /dev/net/tun
cat: /dev/net/tun: File descriptor in bad state

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

RPM – Remote Power Manager – podstawy

Jednym z ostatnich moich problemów w moim domowym labie było restartowanie serwerów czy ogólnie urządzeń, szczególnie, gdy nie jestem w pobliżu. Kupiłem sobie na Allegro RPM (Remote Power Manager) firmy Sentry, model COMMANDER R402-0-2. Zdalne zarządzanie jest możliwe tylko przez konsole RS 232 (a wolałbym bezpośrednie wbicie się na webowy interface albo przez telnet SSH) ale że dałem za niego 200 zł nie będę marudził :D.

Czytaj dalej RPM – Remote Power Manager – podstawy

OpenVPN: login i hasło w pliku

Korzystaj z prostych konfiguracji tego VPN-a użyteczne może być zapisanie w pliku konfiguracyjnym loginu i hasła. W opcji auth-user-pass należy podać nazwę pliku z danymi:

auth-user-pass auth.cfg

Pierwsza linia powinna zawierać nazwę użytkownika, druga hasło.

Dodatkowo należy spełnić następujące dwa warunki:

  • plik może być odczytywany tylko przez właściciela (chmod 600 auth.cfg)
  • w pliku konfiguracyjnym tunelu należy dodać opcję umożliwiającą wykonywanie skryptów użytkownika (script-security 2)

Linux: zdalny pulpit Windows-a z Linuksa – rdesktop (podstawy)

Jak wiadomo z poprzedniego postu, nie samym Linuksem człowiek żyje. Jako że postanowiłem popracować w architekturze klient – serwer (czytaj laptop na łóżku oraz serwer świadczący wirtualizację pod biurkiem) należało potestować możliwości pracy zdalnej pracy na Windowsie. Znam oczywiście VNC czy inne rozwiązania ale postanowiłem zacząć pod podstaw czyli: zdalnego pulpitu Windowsa i programu rdekstop.

Program rdesktop jest dostępny w każdej dystrybucji i można go wywołać poleceniem (a jakże trudno się domyśleć): rdesktop. Posiada on kilka ciekawych przełączników:

  • -u nazwa_uzytkownika – podajemy nazwę zdalnego użytkownika, np. Administrator,
  • -p hasło – podajemy hasło użytkownika (i wtedy nastąpi automatyczna authentyfikacja użytkownika),
  • -f – full screen czyli pełny ekran, wyjście z trybu pełnego ekranu przez alt + ctrl + Enter,

Screenshot będzie później…

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ę…