Mengapa perintah ssh tidak mengikuti RFC di URI?


9

RFC:

menyajikan SSH URI sebagai:

ssh://[<user>[;fingerprint=<host-key fingerprint>]@]<host>[:<port>]

Adakah alasan yang diketahui mengapa perintah OpenSSH ssh tidak mengikuti standar ini dengan opsi hostname? Itu tidak menerima port setelah titik dua.

Contoh URI yang saya harapkan untuk bekerja:

$ ssh user@host:2222
ssh: Could not resolve hostname host:2222: Name or service not known

Saya pikir @ MichaelKjörling benar. Tanda titik dua adalah batas untuk tempat nama host berhenti dan jalur dimulai pada host itu. Anda perlu menggunakan -psakelar untuk menyampaikan port alternatif.
slm

6
Itu bukan RFC, itu konsep yang belum diikuti sejak tahun 2006.
Stéphane Chazelas

Saya setuju bahwa rfc3986 akan lebih tepat untuk dikutip.
Tomasz Wasiluk

Jawaban:


5

sshmendahului format URI yang lebih umum ( 1998 ) beberapa tahun (1995 IIRC).


Jadi Anda mengatakan bahwa rancangan RFC 1738 yang diterbitkan pada bulan Desember 1994 tidak dapat memengaruhi pengembangan OpenSSH? OpenSSH pertama kali muncul di OpenBSD 2.6 dan rilis portabel pertama dibuat pada Oktober 1999 setelah Wikipedia . Kecuali harus kompatibel dengan alat ssh.com?
Tomasz Wasiluk

RFC 1738 adalah untuk URL dan dalam ingatan saya tidak begitu umum format dan kemudian digeneralisasi dalam URI. openssh jauh kemudian sebagai ssh, saya tidak ingat telah melakukan transisi sehingga ada kemungkinan mereka kompatibel dengan commandline sebagian besar.
Anthon

14

Saya awalnya memposting ini sebagai komentar, tetapi akan menyempurnakannya sebagai jawaban.

OpenSSH berisi beberapa utilitas, di antara yang paling terkenal adalah sshdan scp. Meskipun sshhanya akan terhubung ke komputer jarak jauh (dan mungkin menjalankan perintah pada komputer jarak jauh itu), bagian lain dari OpenSSH seperti scpmemiliki sintaks yang sedikit berbeda. Berdasarkan semua yang menjadi bagian dari paket OpenSSH, ini kemungkinan berbagi banyak kode.

Dengan scp, Anda menentukan file jarak jauh pada formulir triplet sebagai user@host:remotefilename, di mana remotefilenamemungkin jalur relatif atau absolut.

Jika bagian host diizinkan berada di formulirhost:port , ini akan menciptakan ambiguitas potensial: jdoe@host.example.com:2222merujuk ~jdoe/2222pada host.example.com saat menyambungkan pada port standar, atau apakah itu merujuk pada tidak ada file sama sekali (atau lebih buruk, ~jdoe) pada host.example.com saat menghubungkan melalui port 2222?

Sintaks URI yang Anda sajikan lebih terbatas pada apa yang dapat diungkapkannya (tidak mengizinkan spesifikasi nama file), dan bahkan yang lebih penting, tidak akan pernah ada ambiguitas kecuali nama host sebenarnya mencakup a :(yang saya pikir tidak bahkan mungkin dalam DNS, dan tentu saja tidak umum dilakukan, sedangkan nama file semua-numerik tidak terlalu biasa).

Ketika SSH awalnya dikembangkan , SSH dikembangkan sebagai pengganti drop-in yang lebih aman untuk rangkaian alat RSH / rlogin sebelumnya. Saya tidak tahu apa sintaks baris perintah untuk itu kembali pada awal 1990-an (RFC menggambarkan rlogin adalah RFC 1282 dari Desember 1991 , mendahului dokumen yang Anda kutip sekitar 15 tahun), tetapi sepertinya itu tidak masuk akal. tebak itu menggunakan sintaks yang sangat mirip karena nama pengguna ditransmisikan secara khusus dalam protokol rlogin. Mengutip RFC 1282:

Setelah koneksi dibuat, klien mengirim empat string yang diakhiri null ke server. Yang pertama adalah string kosong (yaitu, hanya terdiri dari satu byte nol tunggal), diikuti oleh tiga string non-null: nama pengguna klien, nama pengguna server , dan jenis dan kecepatan terminal. Secara lebih eksplisit: ...

Username lokal dapat diperoleh melalui berbagai fasilitas sistem, tetapi nama pengguna terpencil harus ditentukan secara eksplisit entah bagaimana . Selain @sering diucapkan "at" dan dengan demikian menjadi pilihan yang cukup alami untuk memulainya, user@hostmemetakan dengan baik sintaksis yang mapan untuk misalnya pengiriman email (bandingkan alamat SMTP user@host, di mana hostmungkin merupakan host aktual atau nama DNS dengan MX record pointing) ke host sebenarnya), jadi itu mungkin pilihan yang mudah daripada membuat sesuatu yang baru.

Juga patut dicatat apa yang ditunjukkan Stephane Chazelas dalam sebuah komentar : dokumen yang Anda maksud bukanlah RFC, itu konsep yang saat ini berusia tujuh tahun yang, dilihat dari pencarian cepat Google untuk mengonfirmasi, tampaknya tidak pernah berhasil. . Itu terjadi sepanjang waktu; sesuatu diusulkan, tetapi tidak mengumpulkan dukungan untuk benar-benar membuatnya menjadi RFC (dan bahkan banyak, banyak RFC adalah non-standar).


1
Saya kira pertanyaan saya seharusnya adalah "Mengapa utilitas OpenSSH tidak mengikuti standar umum URI?". Meskipun saya menghargai wawasan Anda, itu tidak menjawab pertanyaan saya.
Tomasz Wasiluk

Perspektif historis +1 bermanfaat dalam memetakan kekacauan standar lautan
msw

Untuk memperluas komentar "banyak RFC adalah non-standar", ini tidak bisa jauh dari kebenaran. Sifat dasar RFC adalah "Permintaan Komentar"; ini hanyalah informasi. Ini bisa berupa catatan, memo, atau dokumentasi. RFC hanyalah memo yang diterbitkan; RFC hanyalah salah satu dari sekian banyak cara dokumentasi standar diterbitkan, meskipun ini bukan satu-satunya tujuan RFC. Suatu standar dapat didokumentasikan melalui RFC, tetapi RFC tidak selalu merupakan dokumentasi untuk standar tertentu. Pisang adalah buah, tetapi tidak semua buah pisang.
Swivel
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.