W jaki sposób długość i szerokość terminala są przekazywane przez SSH i telnet?

Kiedy patrzę na długość i szerokość mojego emulatora terminali, stty sizewówczas ma on 271 znaków długości i 71 linii wysokości. Kiedy loguję się do innego serwera przez SSH i wykonuję stty size, ma on również 271 znaków długości i 71 linii wysokości. Mogę nawet zalogować się do niektórych urządzeń Cisco IOS, a terminal ma nadal 271 znaków i 71 linii wysokości:

C1841#show terminal | i Len|Wid
Length: 71 lines, Width: 271 columns
C1841#

Teraz, jeśli zmienię rozmiar okna emulatora terminala (terminal Gnome) na maszynie lokalnej, zarówno stty sizena zdalnym serwerze, jak i „pokaż terminal” w IOS pokaż inną długość linii i liczbę linii. W jaki sposób długość i szerokość terminala są przekazywane przez SSH i telnet?

Protokół Telnet, opisane w RFC 854 , sposób obejmuje wysyłanie komendy w pasma, składające się z charakterem IAC , '\255', a następnie przez kilka kolejnych bajtów. Polecenia te mogą wykonywać takie czynności, jak wysyłanie przerwania do pilota, ale zwykle służą do wysyłania opcji .

Szczegółowe spojrzenie na giełdę wysyłającą opcję typu terminala można znaleźć w Microsoft Q231866 .

Opcja rozmiaru okna jest opisana w RFC 1073 . Klient najpierw wysyła gotowość wysłania NAWSopcji. Jeśli serwer odpowie DO NAWS, klient może następnie wysłać NAWSdane opcji, które składają się z dwóch 16-bitowych wartości.

Przykładowa sesja na terminalu kolumnowym z 47 wierszami 80:

telnet> set options
Will show option processing.
telnet> open localhost
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
SENT WILL NAWS
RCVD DO NAWS
SENT IAC SB NAWS 0 80 (80) 0 47 (47)

Protokół ssh jest opisany w RFC 4254 . Składa się ze strumienia wiadomości. Jedną z takich wiadomości jest"pty-req" pseudo-terminal, a jego parametry obejmują wysokość i szerokość terminala.

byte      SSH_MSG_CHANNEL_REQUEST
uint32    recipient channel
string    "pty-req"
boolean   want_reply
string    TERM environment variable value (e.g., vt100)
uint32    terminal width, characters (e.g., 80)
uint32    terminal height, rows (e.g., 24)
uint32    terminal width, pixels (e.g., 640)
uint32    terminal height, pixels (e.g., 480)
string    encoded terminal modes

Klienci telnet i ssh przechwycą SIGWINCHsygnał, więc jeśli zmienisz rozmiar okna terminala podczas sesji, wyśle ​​odpowiedni komunikat do serwera o nowym rozmiarze. Ssh wysyła komunikat zmiany wymiaru okna:

byte      SSH_MSG_CHANNEL_REQUEST
uint32    recipient channel
string    "window-change"
boolean   FALSE
uint32    terminal width, columns
uint32    terminal height, rows
uint32    terminal width, pixels
uint32    terminal height, pixels

Podejrzewam, że to przez sygnał SIGWINCH--- prawdopodobnie dostarczony rurą.

Z wikipedii :

SIGWINCH
    The SIGWINCH signal is sent to a process when its controlling
     terminal changes its size (a window change).

Jeśli zrobię (w zsh):

[romano:~] 1 % TRAPWINCH() {echo hi;}

... i modyfikuję rozmiar terminala:

[romano:~] % stty size
35 99
[romano:~] % hi
[romano:~] % hi
[romano:~] % hi
[romano:~] % stty size
31 80

RFC 4254 Sekcja 6.9 Nazwa wiadomości „zmiana okna” jest wysyłana z nowymi wymiarami. Po stronie klienta może być prawdą, że oryginalny SIGWINCH został złapany, ale wierzę, że jest wysyłany za pośrednictwem tej wiadomości. https://www.ietf.org/rfc/rfc4254.txt