Would you like to add native support for subsystems such as SFTP and etc.? At the moment, the lib does not provide simple "out-of-the-box" implementations of server-side and client-side subsytems. I could take the time to integrate my ready implementation under russh, since I have already taken the time to implement the SFTP protocol on the server side. Are you interested in PR?

Whenever I try to create an SSH server with only public key authentication allowed, I always get a Permission denied (publickey) message from ssh. I was able to reproduce the situation with the following code:

use core::pin::Pin;
use futures::FutureExt;
use russh::{
    server::{self, Auth, Session},
    MethodSet,
};
use russh_keys::key::{KeyPair, PublicKey};
use std::{net::SocketAddr, str::FromStr, sync::Arc};

#[derive(Clone)]
struct Server {}

impl server::Server for Server {
    type Handler = Self;

    fn new_client(&mut self, socket_addr: Option<SocketAddr>) -> Self {
        self.to_owned()
    }
}

impl server::Handler for Server {
    type Error = russh::Error;
    type FutureAuth =
        Pin<Box<dyn core::future::Future<Output = Result<(Self, Auth), Self::Error>> + Send>>;
    type FutureUnit =
        Pin<Box<dyn core::future::Future<Output = Result<(Self, Session), Self::Error>> + Send>>;
    type FutureBool = Pin<
        Box<dyn core::future::Future<Output = Result<(Self, Session, bool), Self::Error>> + Send>,
    >;

    fn finished_auth(self, auth: Auth) -> Self::FutureAuth {
        async move { Ok((self, auth)) }.boxed()
    }

    fn finished_bool(self, b: bool, session: Session) -> Self::FutureBool {
        async move { Ok((self, session, b)) }.boxed()
    }

    fn finished(self, session: Session) -> Self::FutureUnit {
        async move { Ok((self, session)) }.boxed()
    }

    fn auth_publickey(self, user: &str, public_key: &PublicKey) -> Self::FutureAuth {
        async move { self.finished_auth(Auth::Accept).await }.boxed()
    }
}

#[tokio::main]
async fn main() {
    let mut config = server::Config::default();
    config.methods = MethodSet::PUBLICKEY;
    config.keys.push(KeyPair::generate_ed25519().unwrap());

    server::run(
        Arc::new(config),
        &SocketAddr::from_str("0.0.0.0:2222").unwrap(),
        Server {},
    )
    .await
    .unwrap();
}

If I add a println!("AUTH PUBKEY BEING CALLED"); line right below the function declaration at fn auth_publickey(self, user: &str, public_key: &PublicKey), my terminal doesn't show any output, leading me to think the function is never even being called, but I can't figure out why that might be the case.

Consider the following field:

https://github.com/warp-tech/russh/blob/49bf9599637d492f0aa17377b9c66cf953cb0824/russh/src/channels.rs#L113

This field is meant to indicate current window_size on the Channel.

However, I've been able to hit a case where the u32 overflows on add, which doesn't seem correct. Here's the scenario:

1. Push a large amount of data to an OpenSSH server
2. Enter the send_data loop of the channel
3. Eventually the window_size will become 0. When it does, we enter this loop to wait for an adjustment and reset the window_size.
4. This continues until the data has all been pushed.
5. After data returns, call Channel.wait in a loop waiting for ChannelMsg::Data to come through from the server.

The issue I am seeing is that OpenSSH has sent a large amount of ChannelMsg::WindowAdjusted messages during step 4. send_data, does not attempt to process these, it only takes the first one it finds and leaves the rest in the channel. While waiting for ChannelMsg::Data in step 5, the remaining ChannelMsg::WindowAdjusted are read out of the channel first.

Each CHANNEL_WINDOW_ADJUST coming from the server first goes through here:

https://github.com/warp-tech/russh/blob/49bf9599637d492f0aa17377b9c66cf953cb0824/russh/src/client/encrypted.rs#L489-L505

This code takes the existing Channel.recipient_window_size and adds the new adjustment amount to it. This resulting value is then passed into window_adjusted where it is used to build a new ChannelMsg::WindowAdjusted here:

https://github.com/warp-tech/russh/blob/49bf9599637d492f0aa17377b9c66cf953cb0824/russh/src/client/mod.rs#L1450-L1465

Finally, the wait method handles these messages by adding the entire Channel.recipient_window_size to the existing Channel.window_size here:

https://github.com/warp-tech/russh/blob/49bf9599637d492f0aa17377b9c66cf953cb0824/russh/src/channels.rs#L347-L356

Repeatedly adding the Channel.recipient_window_size to the Channel.window_size can overflow the u32 and cause a panic (in debug mode), or an two's complement wrapping (in release mode). I'm wondering if instead of self.window_size += new_size, we should do self.window_size = new_size since we are really passing in the value of Channel.recipient_window_size instead of some amount of byte adjustment from CHANNEL_WINDOW_ADJUST.

Screenshot of https://www.reddit.com/r/rust/comments/u3s3m1/i_wrote_a_smarter_ssh_bastion_in_rust/

Idea behind this issue is to decide on the long term future of russh. There is no rush to do so.

Behavior is different when using exec_request over a "normal" connection

$ ssh localhost -p2222 test

vs

$ ssh localhost -p2222

When adding the test parameter (which will be put into an exec_request) data isn't received per-keystroke anymore, but only once per new-line, and a ctrl+c on the client side doesn't trigger disconnects or channel close or anything.

How or when do I know on the server when a client closed / disconnected the session when they supply an argument using exec_request?

I'm using this library's server portion, and the following code for the Handler trait is producing some weird output:

fn shell_request(self, channel: ChannelId, mut session: Session) -> Self::FutureUnit {
    session.data(channel, "Interactive shell is disabled.\n".to_string().into());
    session.close(channel);
    self.finished(session)
}

For some reason this is showing the following output in my terminal when connecting to the server:

Interactive shell is disabled.
                              Connection to dev.hunterwittenborn.com closed.

I'm not sure how related to the library this is, but any idea what might be causing it?

Hi (again), I've tried to read the docs and the code but still failed in my intent. I'm implementing an honeypot server and I want to send a fake shell prompt (or any other string) to new clients as soon as they start the session, before they start sending commands.

I've tried here since it's one of the few points where the Session object is mutable, but the client never displays it https://github.com/evilsocket/medusa/blob/main/src/protocols/ssh/handler.rs#L214 while it works fine in the data handler and/or after an exect_request.

Thanks

Channels need not be exclusively client-created, in fact few (if any?) channels specify directionality, and refer only to a sender and receiver.

This does an initial, somewhat minimal pass at making servers capable of initiating channels. This is rather rough and I think greater abstraction is warranted here; I pulled out relevant parsing code into parsing.rs, but there is logical duplication between the client and server which I don't have time to disentagle. This also only implements some channel functionality on the server-side, it's not as complete as the client.

The significant breaking change here is that server::run_stream now returns (almost) immediatel with a SessionHandle, similar to the client; this is used to open channels.

Ultimately this is a big set of changes I would understand if there's not great desire to merge this upstream :)

ChannelStream works well for me. Unfortunately I don't have my macbook right now to run tests, but on windows I still noticed errors that I had to fix.

Bumps tokio from 1.17.0 to 1.19.2.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Hello,

I try the example code in async-ssh2-tokio (link), but failed with below error:

Error: Other Error Happen

Caused by: No common key algorithm

The server is ok as I can ssh it by "ssh" command in linux, and if I try the same code to ssh a raspberry pi, it also works. I searched in google, and try to compare the difference :

When check the key_exchange_init message in wireshark:

for my unit: server_host_key_algorithms string: rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256

for raspberry pi: server_host_key_algorithms string: rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519

So it seems there is something different, does anyone know what was wrong? How can I fix it in the client side?

Best Regards, Hermes

Currently, russh doesn't provide a graceful shutdown mechanism. Graceful shutdowns are especially important in cloud environments to allow instances to be shut down without impacting users.

The following should happen on shutdown:

1. Stop listening accepting new connections
2. Notify application code that a shutdown has been triggered
3. Allow application code to notify that shutdown has been complete
4. Wait for the existing connections to close
5. If application code misbehaves and doesn't close the connection within a certain period of time, close the connection

I have the following code for a Client:

pub struct Client {
    handle: Handle<Handler>,
}

pub struct Channel {
    inner: russh::Channel<Msg>,
}

impl Client {
    pub async fn init(remote: &str, user: &str, key: impl AsRef<Path>) -> eyre::Result<Self> {
        let config = Arc::new(ClientConfig {
            connection_timeout: Some(Duration::from_secs(5)),
            ..Default::default()
        });
        let mut handle = client::connect(config, remote, Handler).await?;
        let key = Arc::new(load_secret_key(key, None)?);
        let res = handle.authenticate_publickey(user, key).await?;
        if !res {
            return Err(eyre::eyre!("Server rejected our SSH publickey"));
        }
        Ok(Self { handle })
    }

    pub async fn new_channel(&mut self) -> eyre::Result<Channel> {
        dbg!("a");
        let inner = self.handle.channel_open_session().await?;
        dbg!("b");
        Ok(Channel { inner })
    }
}

When running

    let mut ssh_client = ssh::Client::init(
        &env::var("REMOTE_ADDR")?,
        &env::var("SSH_USER")?,
        &env::var("SSH_KEY")?,
    )
    .await?;
    let mut channel = ssh_client.new_channel().await?;

the "a" gets printed, but the "b" does not. I have implemented the method in the Handler for printing out the channel open confirmation, with the logs containing this:

[snip]
2022-12-19T11:02:19.625093Z DEBUG russh::client::encrypted: userauth_success    
[src/ssh.rs:75] "a" = "a"
2022-12-19T11:02:19.625233Z DEBUG russh::cipher: writing, seqn = 6    
2022-12-19T11:02:19.625251Z DEBUG russh::cipher: padding length 7    
2022-12-19T11:02:19.625259Z DEBUG russh::cipher: packet_length 32    
2022-12-19T11:02:19.649032Z DEBUG russh::cipher: reading, len = [191, 235, 165, 118]    
2022-12-19T11:02:19.649065Z DEBUG russh::cipher: reading, seqn = 7    
2022-12-19T11:02:19.649152Z DEBUG russh::cipher: reading, clear len = 624    
2022-12-19T11:02:19.649164Z DEBUG russh::cipher: read_exact 628    
2022-12-19T11:02:19.649178Z DEBUG russh::cipher: read_exact done    
2022-12-19T11:02:19.649533Z DEBUG russh::cipher: reading, padding_length 4    
2022-12-19T11:02:19.649616Z  WARN russh::client::encrypted: Unhandled global request: Ok("[email protected]") 0    
2022-12-19T11:02:19.649634Z DEBUG russh::cipher: writing, seqn = 7    
2022-12-19T11:02:19.649642Z DEBUG russh::cipher: padding length 14    
2022-12-19T11:02:19.649649Z DEBUG russh::cipher: packet_length 16    
2022-12-19T11:02:19.649841Z DEBUG russh::cipher: reading, len = [131, 217, 96, 50]    
2022-12-19T11:02:19.649864Z DEBUG russh::cipher: reading, seqn = 8    
2022-12-19T11:02:19.649921Z DEBUG russh::cipher: reading, clear len = 136    
2022-12-19T11:02:19.649929Z DEBUG russh::cipher: read_exact 140    
2022-12-19T11:02:19.649938Z DEBUG russh::cipher: read_exact done    
2022-12-19T11:02:19.650096Z DEBUG russh::cipher: reading, padding_length 7    
2022-12-19T11:02:19.650120Z DEBUG russh::cipher: reading, len = [219, 50, 139, 30]    
2022-12-19T11:02:19.650129Z DEBUG russh::cipher: reading, seqn = 9    
2022-12-19T11:02:19.650200Z DEBUG russh::cipher: reading, clear len = 136    
2022-12-19T11:02:19.650211Z DEBUG russh::cipher: read_exact 140    
2022-12-19T11:02:19.650225Z DEBUG russh::cipher: read_exact done    
2022-12-19T11:02:19.650451Z DEBUG russh::cipher: reading, padding_length 7    
2022-12-19T11:02:19.672871Z DEBUG russh::cipher: reading, len = [89, 113, 103, 91]    
2022-12-19T11:02:19.672897Z DEBUG russh::cipher: reading, seqn = 10    
2022-12-19T11:02:19.672984Z DEBUG russh::cipher: reading, clear len = 40    
2022-12-19T11:02:19.672995Z DEBUG russh::cipher: read_exact 44    
2022-12-19T11:02:19.673010Z DEBUG russh::cipher: read_exact done    
2022-12-19T11:02:19.673173Z DEBUG russh::cipher: reading, padding_length 6    
2022-12-19T11:02:19.673207Z DEBUG russh::client::encrypted: channel_open_confirmation    
2022-12-19T11:02:19.673251Z DEBUG ssh_worker::ssh: Got channel open confirmation for channel ChannelId(2)

After this the program seems to freeze. I tried connecting to both a remote Debian server as well as a local linuxserver/openssh-server docker container. Anyone know what might be going wrong here?

Hi,

I'm really liking the new async trait handlers!

I can turn a channel into a AsyncRead + AsyncWrite stream using Channel's into_stream() method. Could you also provide a method to stream a Channel's stderr? Possibly, it could be a AsyncReader for extended data for the channel, special cased for where the extended_code == 1.

I'm using russh-0.35.0-beta.8 Thanks

Allow signals to be sent detached from the channel struct.

This is done using a higher-order function and by cloning the sender so it can be used independently of the Channel.

This is useful to be able to spawn a cancelation handler separately from the main Channel recieve loop.

Signed-off-by: Joe Grund [email protected]

Fixes #50

This introduces an on-by-default rs-crypto flag, which enables the existing Rust-based crypto libraries (including aes and ED25519). However, these implementations can be removed by disabling the flag. If it's disabled, then openssl (when turned on) will stand in for them, in a less performant way.

Note that while OpenSSL 3.x does have some ED25519 support, I have not done the work to make that compatible as well--partly because ED25519 is not yet an approved algorithm for my company to use, and partly to retain compatibility with OpenSSL 1.x

One cloud on the horizon for our usage of this library is the likelihood of needing to be FIPS certifiable. Long story short, this essentially means having all cryptography done by a dynamically linked OpenSSL library--which in turn is FIPS certified. In this case, we would use OpenSSL for the cryptography currently done by crates like aes and pbkdf2.

I will (attempt to) implement this in our fork of the library, but I was wondering if it's something there'd be interest in merging upstream as a feature flag. Understanding that dependency on OpenSSL is not greatly desirable and that this would increase the complexity of the library for something a minority of consumers will ever need 😛