Inizialmente l'ho pubblicato come commento, ma lo risolverò un po 'come una risposta.
OpenSSH contiene diverse utility, tra le più importanti delle quali sono sshe scp. Mentre sshsi connetterà solo a un computer remoto (ed eventualmente eseguirà un comando su quel computer remoto), altre parti di OpenSSH come ad esempio scphanno una sintassi leggermente diversa. In virtù del fatto che fanno tutti parte della suite OpenSSH, probabilmente condividono molto codice.
Con scp, si specifica un file remoto su un modulo triplet come user@host:remotefilename, dove remotefilenamepuò essere un percorso relativo o assoluto.
Se la porzione host fosse nel modulohost:port , ciò creerebbe una potenziale ambiguità: si jdoe@host.example.com:2222riferisce a ~jdoe/2222host.example.com quando ci si collega sulla porta standard o non fa alcun riferimento a nessun file (o peggio ~jdoe) su host.example.com durante il collegamento tramite la porta 2222?
La sintassi dell'URI che presenti è più limitata in ciò che può esprimere (non consente una specifica del nome file) e, cosa ancora più importante, non può mai esserci ambiguità a meno che il nome host effettivo includa un :(che non credo è persino possibile in DNS, e certamente non è comunemente fatto, mentre i nomi di file tutto numerici non sono poi così insoliti).
Quando SSH è stato originariamente sviluppato , è stato sviluppato come un sostituto drop-in più sicuro per la precedente suite di strumenti RSH / rlogin. Non so quale fosse la sintassi della riga di comando all'inizio degli anni '90 (l'RFC che descrive il loglog è l' RFC 1282 del dicembre 1991 , che precede il documento citato di circa 15 anni), ma non sembra irragionevole suppongo che abbia usato una sintassi molto simile perché il nome utente è stato trasmesso appositamente nel protocollo rlogin. Citando RFC 1282:
Una volta stabilita la connessione, il client invia al server quattro stringhe con terminazione null. La prima è una stringa vuota (cioè consiste solo di un singolo byte zero), seguita da tre stringhe non nulle: il nome utente del client, il nome utente del server , il tipo e la velocità del terminale. Più esplicitamente: ...
Il nome utente locale può essere ottenuto attraverso varie funzionalità del sistema, ma il nome utente remoto deve essere specificato in modo esplicito in qualche modo . Oltre ad @essere spesso pronunciato "at" e quindi essere una scelta abbastanza naturale per cominciare, si user@hostassocia bene alla sintassi consolidata per esempio la trasmissione di e-mail (confrontare un indirizzo SMTP di user@host, dove hostpuò essere un host reale o un nome DNS con un record MX che punta per un vero host), quindi è stata probabilmente una scelta facile piuttosto che inventare qualcosa di nuovo.
Vale anche la pena notare ciò che Stephane Chazelas ha sottolineato in un commento : il documento a cui ti riferisci non è un RFC, è una bozza attualmente di sette anni che, a giudicare da una rapida ricerca su Google per confermare, sembra non essere mai decollato . Questo succede sempre; viene proposto qualcosa, ma non raccoglie il supporto per trasformarlo effettivamente in un RFC (e anche molti, molti RFC non sono standard).
-pswitch per convogliare una porta alternativa.